diff --git a/ChangeLog b/ChangeLog index 55f85a83..6e61f827 100644 --- a/ChangeLog +++ b/ChangeLog @@ -22565,3 +22565,6 @@ 2021-10-28 Fred Gleason * Refactored the 'RDTimeEngine::StartEvent()' method to account for Daylight Saving Time transitions properly. +2021-10-28 Fred Gleason + * Added a 'Daylight Saving Time' section to the 'Automating Tasks + with RDCatch' chapter of the Operations Guide. diff --git a/docs/opsguide/rdcatch.xml b/docs/opsguide/rdcatch.xml index 072ad660..6a38d9c7 100644 --- a/docs/opsguide/rdcatch.xml +++ b/docs/opsguide/rdcatch.xml @@ -392,7 +392,103 @@ follow, but these are less important for understanding the operation of RDCatch. + + + Daylight Saving Time Considerations + + Many governmental jurisdictions have promulgated regulations + dictating that local clocks be adjusted at certain times of + the year --e.g. during summertime or certain religious events. + Commonly known as "Daylight Saving Time", + "Summer Time" or "Ramadan Time", + special care must be taken + when configuring events that occur near or during a transition + from "standard" time to "daylight saving time" + and vice-versa. There are two basic types of such transitions; a + "spring forward" transition, during which the local clock + is advanced some period of time (typically an hour) and a + "fall back" transition, during which the local clock is + set back some period of time (again, typically an hour). + + + Spring Forward Transitions + + When "springing forward", the local clock will simply + skip past certain time values. For example, imagine that we have + a transition where, at 02:00:00 exactly (2:00:00 AM), the clock + will be advanced 1 hour. A digital clock counting through this + transition would show values like: + + + [...] + 01:59:57 + 01:59:58 + 01:59:59 + 03:00:00 + 03:00:01 + 03:00:02 + [...] + + + In this example, the entire 2 AM hour simply + doesn't exist. Hence, any RDCatch events + that reference such events will not be + executed. + + + This applies not only to configured <start-time> values, + but also to <end-time> ones as well. + If any + configured times in an event fall into a "skipped" + time period, then the entire event will be skipped. + + + + Fall Back Transitions + + "Fall-back" transitions have the exact opposite behavior. + Specifically, the time period over which the transition occurs + is duplicated. For example, imagine + that we have a transition where, at 02:00:00 exactly (2:00:00 AM), + the clock will be set back 1 hour. A digital clock counting + through this transition would show values like: + + + [...] + 01:59:57 + 01:59:58 + 01:59:59 + 01:00:00 + 01:00:01 + 01:00:02 + [...] + + + The end of the second 1 AM hour then proceeds + normally: + + + [...] + 01:59:57 + 01:59:58 + 01:59:59 + 02:00:00 + 02:00:01 + 02:00:02 + [...] + + + When dealing with a transition of this sort, RDCatch will treat + times that occur within the transition as belonging to the + first pass; with the all times in the + second pass being ignored. + + + + + + The Button Area