In most cases, you'll want to advance that time by the saving amount (usually 1 hour), so on that day it will run at 3:00 AM, but will be back to running at 2:00 AM in the next instance. For example, in US Pacific Time, a daily task scheduled to run at 2:00 AM local time will not exist on March 9th, 2014. Have a strategy in place (either fixed or configurable), of what to do for occurrences that fall at the time of a daylight saving time transition:įor the 'spring forward' transition, there's a gap of missing local time when the occurrence might not exist. (This part is highly specific to the requirements of the application.) In some cases, you may want to also project the next several (or many) instances, such as the next 5 occurrences, or all occurrences for the next year. You'll almost always do this for the next immediate occurrence, such that you can use the UTC clock to determine the real instant in time to run. Project the local time to a UTC date and time for each occurrence that you want the event to fire. Don't assume that the server's local time zone is the same time zone that matters to the end user. If I'm in the US Pacific time zone, I can't schedule for 4:00 PM UTC, because after the transition it would have to switch to 3:00 PM UTC to keep the same 8:00 AM local time.ĭefine the time zone that the 'local' time represents. For example, if you set a daily alarm clock to wake you up at 8:00 AM every day, you don't want to wake up an hour early or an hour late after a daylight saving time transition. I'll summarize from a non-programming perspective:ĭefine your recurrence patterns by local time - not UTC.

I've written about it before from a programming perspective on Stack Overflow here and here.

Proper scheduling of future tasks by local time, taking into account time zones and daylight saving time, is a very complex subject.

Time zone scheduler