Planning work in a logical time (not completed using daylight saving time)

Question

This is not a message about the technology as such, but rather a message about the corresponding algorithm. I want my users to be able to schedule an event in my application at a specific time (which they will see in their time zone on my site) every week.

Say a user in New York plans that the event will happen at 8pm EST. I would like the event to occur for this user at 8 pm EST every week throughout the year, regardless of daylight saving time.

Currently, I save the time value in UTC in my database, but UTC does not change depending on the time of year. It seems that some time zones have the concept of saving on summer time, and some do not, which means that if I were to perform any processing of time processing on the fly (before any requests that are looking for a date to schedule an event or show the scheduled time on the site). I will need to see if the user time zone supports daylight saving time, and if the target timestamp is within the summertime.

How do people usually solve this problem? In other words, how should I store the logical time in my database, display it correctly, use it to schedule tasks, regardless of daylight saving time, for all user time zones in the easiest way?

Answer 1

I’ll make one assumption, you mean "... in Eastern time every week throughout the year." When you say EST, you specifically refer to Eastern Standard Time. When DST is applied, it is known as Eastern Daylight Time (EDT).

In addition, abbreviations are not a good way to define time zones. How could I know that you meant EST in the United States (UTC-5), not EST in Australia (UTC + 10)? The abbreviations are mixed. You can see a pretty complete list here .

The first thing to do is decide how you want to determine the user's time zone. There are two databases:

Microsoft timezone database

PROs

• Built into the Windows operating system.
• Updates are automatically deployed using Windows Update.
• Easy to use from Win32 or .Net Framework.

VS

• Supported by Microsoft instead of an authority or standards community.
• Zones tend to be very broad rather than sophisticated.
• Failed to change historical time zones.
• Interaction with non-Microsoft servers can be painful.
• Updated less frequently.

IANA / Olson Time Zone Database

PROs

• It is widely implemented on Linux, Mac, Java, PHP and many other platforms.
• Libraries are available for JavaScript and Windows / .Net .
• Refined, specific time zones named in the city example.
• Contains historical data for changing time zones.
• Reference in many RFCs and other standards.
• Community supported, recently supported by IANA.
• Frequent updates, several times a year.

VS

• Usually not supported automatically, although some implementations may do this.
• There are so many zones, it can be difficult to present a simple drop-down list for your users. A good user interface requires map-based timezone collectors such as this one .

Now that you’ve decided which time zone your user is in, let’s get the gist of your initial question. How should you respond to a recurring event that is at the same local time, regardless of DST changes?

You have two different problems, perseverance and fulfillment.

To save (and transport, display, etc.) you need to save the combined local time zone and time. For example, 8:00 pm in the America/New_York IANA zone. If possible in your structure, save this time without a date component. Do not convert it to UTC or try to configure it for DST. You simply capture the intentions of users as they expressed it to you.

To do this, you need to start your repetitive work at a specific scheduled time. The server your work is running on may be in a completely different time zone. You need a series of UTC DateTime time values, so you can set the task scheduler to run at certain times in an instant. You can also use the value local-time-plus-utc-offset for this, such as DateTimeOffset in .Net. This will have the advantage of 8:00 PM for each value, even if the offset has switched between -4 and -5. See DateTime vs DateTimeOffset .

To reconcile these two concepts, you will need code that will evaluate the local time and calculate the execution timestamp. You could simply set up the next scheduled task as each task starts, or you can do this periodically and the project event time for some future X number of events. It is for you. If you need to put the future dates of events on the calendar, then you certainly need the latter approach.

Answer 2

Perhaps you can use any of the timezone public APIs. For instance. https://developers.google.com/maps/documentation/timezone/ .

Answer 3

I would switch to UTC as soon as possible and from UTC, because when countries finish DST at the end of summer, they return the clock, and there are two hours a day when the same time - so DST times cannot unambiguously describe all the times.