Using aggregation base time offset to adjust for time zone

When specifying an aggregate, two important and related settings are the base time and the interval. This article will focus on the base time setting, and how it has it's own optional offset.

Base time and interval are specified when configuring an aggregate in the UI, for example the parameter selection dialog of a chart:

And they are also specified in process code when declaring an aggregated input node:

These examples both show an interval of 1D and a base time of D. This is an example of OPC relative time syntax, and translates to an aggregation interval of 1 day, with the base time being the start of the day (i.e. at midnight).

However, the "start of the day" is actually the start of the UTC day (because all timestamps are internally stored with the UTC time zone). This won't be the same as the start of your day, unless you live in London, Timbuktu, or some other place that shares the UTC time zone. As a result, the aggregated values will have timestamps that occur at the equivalent of UTC midnight in the local time zone. For example, in the Sydney/Australia time zone (which is UTC +10:00), the aggregated values will have timestamps like this:

If we wanted the aggregated timestamps to occur at midnight in the Sydney/Australia time zone, then the base time will need to be offset to allow for the fact that this time zone is 10 hours ahead of UTC. Therefore, we will modify the base time to subtract those 10 hours by setting it to D-10H:

Note the aggregated timestamps now all appear at midnight. A different local time zone would require a different offset, for example in New York, Eastern Daylight Time is 4 hours behind UTC, so the base time would be D+4H.

If we wanted to see the daily average temperature at a different base time, for example at 9:00am every day, then the base time would need another adjustment. We would first make the calculation to offset the difference between UTC and local time zone, then add 9 hours. So for Australia/Sydney that would work out as -1 hour:

But in New York, the calculation would be D+13H.

In summary; base time offsets can initially require some careful calculation, and time zones in general are a subject which can cause confusion. Luckily, experimenting with different offsets and seeing the results is very easy with a UI interface such as the parameter selection dialog in the previous examples. Just enter a base time and click the apply button!