When utilizing the output timestamp relative to trigger time functionality within PI AF 2018, customer has experienced an issue where values written 12 hours before (*-12h) (ideally at 12PM/12AM, thanks to a 12 hour period) the output time will write at an undesired time (11PM or 1AM) during the DST transition.
Customer's desired improvement would be that either relative time (d,h,m,s, etc.) be made DST aware, or for there to be an additional setting configurable to allow DST awareness for relative time units.
For additional background, this issue affects whenever we calculate production shift performance (in our case, shifts are 12 hours). We have periodic analyses which trigger at midnight and noon. We want to write the shift performance to the start time of the shift, so we use an output timestamp override of *-12h. At DST changes, our analysis output gets written to 11 pm or 1 am, as opposed to 12 am as would be expected.
The 'day' offset will always be the same time of the day (which is what you desire) where the 'hour' offset will be the specified number of hours. The problem is you want a fraction of a day which is not supported because the length of a day is not constant. But I think you could use '-1d+12h' to produce your desired result for the 12AM time and '+1d-12h' for the 12PM time.
Please the BOD() and NOON() builtin functions for this particular use case. Bod('*') will give you beginning of day, which would be 12AM. Similarly Noon('*') will give you noon of the current day. As an example, for 2018, the DST transition was on 3/11/2018 in the US. As such, if you use a 12h offset, the DST will affect the output. However, using Bod('3/11/2018') and Noon('3/11/2018') would return the desired results.
Hi David and Steve, thank you for your input. The current functionality, as described, works fine for keeping daily outputs at a fixed output time (adjusted for DST). However, if you wish to have an analysis output every shift (commonly every 8 or 12 hours), there is no simple way to accomplish this, other than (a) using two or three separate analyses, with the appropriate Bod or Noon functions, or (b) having a set of analyses that correctly outputs the shift start and end times, adjusted for DST, which you can use as variables in your analyses. Please refer to Tech Support Case #911100 for a demonstration of how the expected behavior David mentions (-1d-12h) does not return noon/midnight on DST changes.
Please feel free to contact me to discuss further, since I strongly believe there is a disconnect between the intended behavior and actual behavior.
Hi, sorry for the delayed response. I want to re-emphasize that the PI System uses UTC as the basis for time. This of course helps us minimize issues related to DST and as a result the relative time expression for the PI System is very specific in that it's referenced to UTC and not "wall clock" time. As an example, if you were to assume "*" equates now, then "*-8h" means starting from now, count 8 hours backwards in time based on UTC and not "wall clock". What you're describing is counting hours (or more generally counting time) based on the "wall clock".
(BTW, in the PI System, "*" actually does not mean NOW, but rather it means the snapshot value.)
