I am hoping to make this question and the answers to it the definitive guide to dealing with daylight saving time, in particular for dealing with the actual change overs.
If you have anything to add, please do
Many systems are dependent on keeping accurate time, the problem is with changes to time due to daylight savings – moving the clock forward or backwards.
For instance, one has business rules in an order taking system that depend on the time of the order – if the clock changes, the rules might not be as clear. How should the time of the order be persisted? There are of course an endless number of scenarios – this one is simply an illustrative one.
- How have you dealt with the daylight saving issue?
- What assumptions are part of your solution? (looking for context here)
As important, if not more so:
- What did you try that did not work?
- Why did it not work?
I would be interested in programming, OS, data persistence and other pertinent aspects of the issue.
General answers are great, but I would also like to see details especially if they are only available on one platform.
I’m not sure what I can add to the answers above, but here are a few points from me:
Types of times
There are four different times you should consider:
- Event time: eg, the time when an international sporting event happens, or a coronation/death/etc. This is dependent on the timezone of the event and not of the viewer.
- Television time: eg, a particular TV show is broadcast at 9pm local time all around the world. Important when thinking about publishing the results (of say American Idol) on your website
- Relative time: eg: This question has an open bounty closing in 21 hours. This is easy to display
- Recurring time: eg: A TV show is on every Monday at 9pm, even when DST changes.
There is also Historic/alternate time. These are annoying because they may not map back to standard time. Eg: Julian dates, dates according to a Lunar calendar on Saturn, The Klingon calendar.
Storing start/end timestamps in UTC works well. For 1, you need an event timezone name + offset stored along with the event. For 2, you need a local time identifier stored with each region and a local timezone name + offset stored for every viewer (it’s possible to derive this from the IP if you’re in a crunch). For 3, store in UTC seconds and no need for timezones. 4 is a special case of 1 or 2 depending on whether it’s a global or a local event, but you also need to store a created at timestamp so you can tell if a timezone definition changed before or after this event was created. This is necessary if you need to show historic data.
- Always store time in UTC
- Convert to local time on display (local being defined by the user looking at the data)
- When storing a timezone, you need the name, timestamp and the offset. This is required because governments sometimes change the meanings of their timezones (eg: the US govt changed DST dates), and your application needs to handle things gracefully… eg: The exact timestamp when episodes of LOST showed both before and after DST rules changed.
Offsets and names
An example of the above would be:
The soccer world cup finals game
happened in South Africa (UTC+2–SAST)
on July 11, 2010 at 19:00 UTC.
With this information, we can historically determine the exact time when the 2010 WCS finals took place even if the South African timezone definition changes, and be able to display that to viewers in their local timezone at the time when they query the database.
You also need to keep your OS, database and application tzdata files in sync, both with each other, and with the rest of the world, and test extensively when you upgrade. It’s not unheard of that a third party app that you depend on did not handle a TZ change correctly.
Make sure hardware clocks are set to UTC, and if you’re running servers around the world, make sure their OSes are configured to use UTC as well. This becomes apparent when you need to copy hourly rotated apache log files from servers in multiple timezones. Sorting them by filename only works if all files are named with the same timezone. It also means that you don’t have to do date math in your head when you ssh from one box to another and need to compare timestamps.
Also, run ntpd on all boxes.
Date.getTime() call. These are fine when used as opaque identifiers, or when doing date math during a single session on the same client, but don’t try to cross-reference these values with something you have on the server. Your clients don’t run NTP, and may not necessarily have a working battery for their BIOS clock.
Finally, governments will sometimes do very weird things:
Standard time in the Netherlands was
exactly 19 minutes and 32.13 seconds
ahead of UTC by law from 1909-05-01
through 1937-06-30. This time zone
cannot be represented exactly using
the HH:MM format.
Ok, I think I’m done.
This is an important and surprisingly tough issue. The truth is that there is no completely satisfying standard for persisting time. For example, the SQL standard and the ISO format (ISO 8601) are clearly not enough.
From the conceptual point of view, one usually deals with two types of time-date data, and it’s convenient to distinguish them (the above standards do not) : “physical time” and “civil time“.
A “physical” instant of time is a point in the continuous universal timeline that physics deal with (ignoring relativity, of course). This concept can be adequately coded-persisted in UTC, for example (if you can ignore leap seconds).
A “civil” time is a datetime specification that follows civil norms: a point of time here is fully specified by a set of datetime fields (Y,M,D,H,MM,S,FS) plus a TZ (timezone specification) (also a “calendar”, actually; but lets assume we restrict the discussion to Gregorian calendar). A timezone and a calendar jointly allow (in principle) to map from one representation to another. But civil and physical time instants are fundamentally different types of magnitudes, and they should be kept conceptually separated and treated differently (an analogy: arrays of bytes and character strings).
The issue is confusing because we speak of these types events interchangeably, and because the civil times are subject to political changes. The problem (and the need to distinguish these concepts) becomes more evident for events in the future. Example (taken from my discussion here.
John records in his calendar a reminder for some event at datetime
2019-Jul-27, 10:30:00, TZ=
Chile/Santiago, (which has offset GMT-4,
hence it corresponds to UTC
2019-Jul-27 14:30:00). But some day
in the future, the country decides to change the TZ offset to GMT-5.
Now, when the day comes… should that reminder trigger at
2019-Jul-27 10:30:00 Chile/Santiago =
UTC time 2019-Jul-27 15:30:00 ?
2019-Jul-27 9:30:00 Chile/Santiago =
UTC time 2019-Jul-27 14:30:00 ?
There is no correct answer, unless one knows what John conceptually meant
when he told the calendar “Please ring me at
Did he mean a “civil date-time” (“when the clocks in my city tell
10:30”)? In that case, A) is the correct answer.
Or did he mean a “physical instant of time”, a point in the continuus
line of time of our universe, say, “when the next solar eclipse
happens”. In that case, answer B) is the correct one.
A few Date/Time APIs get this distinction right: among them, Jodatime, which is the foundation of the next (third!) Java DateTime API (JSR 310).