Here i am with a nice question on our beloved Daylight Savings Time (DST). In these dark days of northern hemisphere autumn, i always wished we saved more...
A simple AFelement, with a single attribute referring to the SINUSOID PI Point. Using the InterpolatedRange table i request data for every day between T-1y and T. Spanning a full year, we will at least have a DST change. For this year, the DST changes occurred at March 31, 2013 and October 27, 2013.
As expected, the data starts at November 20, 2012 00:00:00, and steps one day forward every row.
But at April 1, 2013, i do not get the expected 00:00:00 as time, but 01:00:00. That is not a timestep of one day, but a timestep of 24 hours (because on March 31, the clock jumped forward from 02:00:00 to 03:00:00).
I seem to remember that this is the difference between 24h timesteps, and 1d timesteps: 24h timesteps always step 24 hours, even if a specific 'clock day' has 23 or 25 days. If you need to step clock days, and not 24 clock hours, 1d should do the trick.
As the timestep is evaluated from the starttime to the endtime, the times are also different when the starttime is within the DST period. If for today, i use T-60d, i see a value on October 27, 00:00:00, October 27, 23:00:00, October 28, 23:00:00. The reversing (use T-60d for EndTime, T fot StartTime) is unfortunately not allowed by OLEDBEnt.
To complicate things a bit more, i run this query using PI SQL Commander on a machine in the UTC timezone, but with DST enabled for the UK region rules. OLEDB nterpise interprets all timestamps as local, and returns al timestamps as local times according to the manual.
What am i seeing now?
Do i see UTC timestamps, that are 1 day apart, but are translated to the current local timezone (at T no DST, thus looking back to a time before DST a timshift could be applied?)
Or do i see an issue in how 1d is interpreted?
Or do i just misunderstand? (also plausible...)
Any thoughts welcome!