Daylight Saving Time change schedule trigger for a marginal time

Question

I'm coding a scheduling app and I'm curious how to handle the following marginal situation concerning the Daylight Saving Time (DST) change:

Say, we're in the time zone where the DST:

• Starts on 2014-Mar-9 at 2:00:00 AM (clock is adjusted forward)
• Ends on 2014-Nov-2 at 2:00:00 AM (clock is adjusted backward)

Suppose, an end-user scheduled my app for 2014-Nov-2, 2:00:00 AM.

Let's assume that the local date/time now is 2014-Nov-2, 1:59:99 AM.

When should my app fire the schedule -- in 1 second, or in 1 hour and 1 second?

Is there a standard that defines how to deal with this situation?

Answer 1

According to wikipedia the rules for daylight saving time are:

...in spring the clock jumps forward from the last moment of 01:59 standard time to 03:00 DST and that day has 23 hours, whereas in autumn the clock jumps backward from the last moment of 01:59 DST to 01:00 standard time, repeating that hour, and that day has 25 hours.[37] A digital display of local time does not read 02:00 exactly at the shift to summertime, but instead jumps from 01:59:59.9 forward to 03:00:00.0.

So while the time and date is different around the world the rules are similar(ignoring Australia's Lord Howe Island which uses a half-hour shift). The hour that jumps backwards or forwards is not touched but the hour that is jumped to.

So in my opinion you should trigger the schedule in one hour and one second.

If you would trigger it in one second and the user wants to stop the schedule at 3 o'clock it would run for two hours instead of one which appears to be incorrect (2-3 = 1 hour).

Answer 2

I agree about all of the comments that "what you should do" is highly dependent on what your users expect, but I will give my opinion anyway.

If you are scheduling a single event, you should be able to test the date and time the user provided to see if it's either invalid (in the spring DST transition), or ambiguous (in the fall DST transition). In the invalid case, prompt something like "sorry, that time is invalid". In the ambiguous case, prompt something like "did you mean 1:30 PDT (UTC-7) or 1:30 PST (UTC-8)?" and handle the selection accordingly.

But I'll approach your question from the use case of a recurring event, such as a daily alarm clock that fires every day at the same time. What would I expect as the user of an alarm clock?

• If I schedule a daily time at 2:00 AM, but in the spring transition the clock goes from 1:59:59 to 3:00:00, I'd expect the alarm to go off right at 3:00:00. I certainly wouldn't want it to go off at 4:00:00 - that would be an extra hour. I also wouldn't want the alarm to not fire at all just because 2:00 didn't technically occur.

• If I schedule a daily time at 1:00 AM, but in the fall transition the clock goes from 1:59:59 back to 1:00:00 - as a user of this alarm, I would expect it to go off on the first occurrence (the daylight time) only. Occurring twice would just be annoying.

  But here we see how this illustrates needing to know your users expectations. What if I could tell my alarm clock to let me have that extra hour back? "Please Mr. Alarm Clock, I'd like to use my extra DST hour to sleep in late. Wake me up at the second occurrence of 1:00." - Now I haven't personally seen any alarm clocks that work this way, but I think you get my point.

Now maybe you're not working with alarm clocks. Maybe this is a timed wire-transfer or some other time-sensitive item. You should work through the expected logic and see what makes sense for you.

Be aware that DST rules vary drastically by time zone. The world does not do DST all at the same time. Much of it doesn't do it at all.

For additional clarity on DST behavior, see the charts in the DST tag wiki.