Why is the daylight saving time cutover time 1 millisecond too soon in some time zones?

If you dig into the Windows time zone database, you'll see that some time zones list the moment when the time zone transitions into or out of daylight saving time as 23:59:59.999 instead of midnight. Why a millisecond too soon?

My colleague Matt Johnson spends a lot of time working with time zones and explains many of the strange and wacky artifacts of time zones in this StackOverflow answer.

In it, I learned these fascinating facts:

  • If the official time zone change occurs at midnight, Windows intentionally misreports the change as occurring at 23:59:59.999 to work around code which "incorrectly used <= instead of < to evaluate the transition", which means that they would unwittingly bounce the date back and forth, resulting in much havoc.
  • Governments will from time to time announce time zone changes on very short notice,¹ leaving computer programmers scrambling to get the time zone data updated in time, or applying workarounds (like "Use this other time zone for now") until the real fix can be deployed.
  • I was aware that Brazil and Israel change their time zone rules every year, but I wasn't aware that Morocco changes its clocks four times a year, and this Antarctic research station changes its clocks three times a year.

Read Matt's StackOverflow answer for all the juicy details. Note in particular his conclusion:

That all said, if you are able to avoid using Windows time zone data in your application, I recommend doing so. Prefer IANA data sources, or those derived from them. There are many routes to working with IANA time zone data. Newer Windows APIs like Windows.Globalization.Calendar and Windows.Globalization.Date­Time­Formatting.Date­Time­Formatter in WinRT/UWP do indeed use IANA time zones, and that is clearly the path forward. In the standard C++ space, I highly recommend using Howard Hinnant's date/tz libraries, or those provided by the ICU project. There are several other viable choices as well.

If you want to keep your finger on the pulse of Microsoft's responses to time zone changes around the world, you should check out the Daylight Saving Time and Time Zone Hot Topics page and the Microsoft Daylight Saving Time and Time Zone Blog.

Bonus reading: How Microsofts 'Time Lords' Keep the Clocks Ticking.

Bonus watching: How to Have the Best Dates Ever! by Matt Johnson.

¹ In one notable case, a government announced a change to the date the country would change to daylight saving time, and then less than two weeks before the change was scheduled to take effect, the legislature passed a law abolishing daylight saving time outright, upon which the legislature and the government got into a shouting match over who was right, and then confusing the matter even further, another government representative mentioned a third cutover date, later reaffirmed by the state news agency, and then four days before the third cutover date, the state news agency announced that the change passed by the legislature is the one that would be implemented after all. Temporary workaround: Disable daylight saving time adjustments until the time zone information can be updated.

Comments (23)

  1. kantos says:

    The more I read about this, the more I think we should just go to Zulu time for everybody. No more time zones, no more DST. Just absolute times.

    1. Yukkuri says:

      Good luck getting everyone to do that.

    2. Roger says:

      I tried that in a prior product for log messages only seen by administrators. It helped that I lived in the UK which is on or next to zulu time all year. It didn’t take very long before users in a certain country that has not adopted the metric system insisted on local time. On a current iOT product I work on that only uses UTC internally but can write to USB sticks we already have users complaining. Filesystems like FAT32 are in local time but don’t tell you what the timezone is. Supporting timezones will be done and needs us to include the 3.5MB of timezone rules into the device too.

      In short, good luck and you’ll have more success getting the metric system adopted.

      1. Kevin says:

        And then you have the folks who don’t like typing “America/Denver” and want to type “MST,” nevermind that that could just as easily be Malaysia Standard Time. There are numerous other 3-letter naming collisions, because unlike (for example) airport codes, there is no central organization in charge of handing out these symbols.

      2. Richard says:

        Possible workaround – if a FAT32 timestamp is on 1st Jan 1970 Windows will not display it.

  2. nathan_works says:

    Will Florida now have it’s own entry in the time zone drop down ? (or would it be added to another location that is the right +GMT offset and doesn’t do DST)

    1. Kevin says:

      Actually, if this goes through, Florida will need two entries. The western panhandle (basically the part under Alabama) is on Central time, not Eastern. The legislature had originally proposed switching the panhandle to Eastern to bring all of Florida into the same timezone, and then switching to permanent DST, but push back from the panhandle got that part dropped. For some reason, people living in Florida and working in Alabama (for example Pensacola/Mobile) didn’t like the idea of there being a 2 hour difference between their home and place of work. Go figure.

  3. Ken Hagan says:

    No need to insist on Zulu time, unless you are in the embedded space and cannot predict what time zone your gizmo will be in the next time it is booted up and no way of finding out and no way of updating the TZ database even if you could. However …

    Governments that change the rules more than once per decade or give less than a year’s notice should just be told to take a hike. Countries don’t move. The sun continues to follow the same path. There is no reason to be messing about with this stuff, even on internet-connected platforms where it is technically possible to play the ridiculous game of musical chairs.

    1. Richard says:

      Good luck with that.

      Timezones are entirely political, and always have been.
      Spain is one hour ahead of the UK, despite having the same longitude as the UK.
      All of China is all on Beijing time, despite straddling five hours of solar time.

      Go figure.

  4. Clockwork-Muse says:

    > If the official time zone change occurs at midnight, Windows intentionally misreports the change as occurring at 23:59:59.999 to work around code which “incorrectly used <= instead of < to evaluate the transition", which means that they would unwittingly bounce the date back and forth, resulting in much havoc.

    Which is why I tend to point people toward toward What do BETWEEN and the devil have in common in an SQL context (the post deals with SQL Server specifically, however essentially all RDBMSs have similar issues, mostly around being able to specify timestamp resolution).

    The reason for the issue is that most people haven’t realized a simple fact about date/timestamp values:
    They’re part of a positive, natural range, and (perhaps more important), there’s never any such thing as an “end” point in time, but rather only “start” points for a change in state.
    For an example of the latter point, consider credit card expiration dates. Most are written as MM/YY, with an example of 07/18 meaning the credit card can be used until midnight of July 31st, 2018 – what it properly should say, however, is that the card will be in the expired state August 1st, 2018, which is much easier to store, query, and reason about. Doing it with an exclusive upper bound also avoids almost all leap-year issues (any business rules don’t need to worry about the vagaries of the calculation, only being required to say “March 1st”).

    I just wish .NET had a good first-party date/time library (third-party NodaTime works, though). `DateTime` mostly torpedoed itself by adding `Kind` (and enforcing the strange dichotomy of Local vs UTC that so many programmers mistakenly gravitate towards). At least we’re finally looking at getting better Zoned support.

    1. Dave Bacher says:

      https://www.hanselminutes.com/485/the-problem-with-datetime-nodatime-with-matt-johnson – the take away is largely Microsoft moves slower than a single person working on GitHub can. ;-)

  5. So, how are these time zone updates delivered? With a monthly update on Patch Tuesday or with service packs and … [whatever term you use to refer to “Windows 10 Fall Creators Update”]?

    Of course, if I had to guess, I’d say with the latter, because it comes twice a year and daylight saving occurs once a year. Also, Microsoft’s support policy requires upgrading to the latest build, right?

    1. Erik F says:

      They seem to come out on Patch Tuesdays as required: see the post dates of the entries in the Microsoft Daylight Saving Time & Time Zone Blog. Not every country switches between daylight savings and standard time, and for those that do, they don’t all switch on the same day!

      1. Wow. Just wow. That’s complicated, amazingly well-done and comprehensive.

        It is hard to imagine this coming from a company that is also going to name the next Windows 10 upgrade “Spring Creators Update”.

        Also, since Microsoft is going into automation with AI business, this certain sector seems an excellent candidate for receiving AI help… but wait. Maybe it already is.

    2. Alex Cohn says:

      Before this switched to the current more reasonable process, these trivial fixes depended on rather dangerous OS updates. I don’t understand why this must be handled in some oblique data structure in HKLM. What danger can there be if the end user be given the power to set “today at 2 AM the clock should switch to DST, UTC + 1.5, and stay that way until 2 AM Oct 22” ?

      1. It involves being on the other side of the adamantine door.

        1. Alex Cohn says:

          Why permissions to define a custom DST should be different from being able to choose the TZ?

          1. Richard says:

            Because the vast majority of people only want to say “I am in this city/state/country”. They don’t know the rules for it and – more importantly – don’t care.

            It’s important for some applications to be able to say what local and UTC time it was when a thing happened, and convert that into any arbitrary timezone back then. This is only possible with the historical timezone data.

            Editing the rules breaks that – it could make the difference between a contract being fulfilled or penalty clauses invoked – eg missed flights, etc

            Howevere, embedded systems that never connect to the Internet often do offer user-configurable rules because their TZ database is harder to update.

          2. Actually, the correct question is: Why such a thing is not placed inside a private database, instead of the public Registry? If it were me, I’d only expose that database using a specialized Windows API. And that API would only have one main function: UpdateTimezoneEx().

            I used to say the same thing about codecs and their merit scores, as well as file associations details. They should all be put in a private database whose only interface is specialized Windows APIs. I think Microsoft just didn’t realize an arms race would ensue for codecs and apps trying to overthrow their competitor’s merits and file associations, as well as malware try to abuse them.

  6. I have stopped using local/regional time in my programs.

    Now I only use UTC, instead I convert to local time at display time. Or if if possible display UTC directly.

    Input is likewise converted from local to UTC, after conversion it is converted one more time to make sure a daylight savings or timezone change did not occur in the mean time.

    Ideally UTC should be switched to use TAI though so we won’t have to deal with leapseconds either.

    1. Brian says:

      TAI, really? So, people are going to look in your database and spend days trying to figure out why all the time stamps are off by 37 seconds?
      UTC timestamps introduce a complication. If you need historical data, you need to have very good historical time zone information. Even in the US and Canada, the daylight saving time rules have changed several times in my lifetime (jeez, for a while, Newfoundland changed 4 times per year – for “double daylight saving time” in mid summer (though that was before the onset of computers everywhere)). If someone wants historical shift production reports for the last 5 years, and everything is UTC, you better have a very good description of when the Daylight time Standard time transitions occurred.
      You really need to decide how to record time based on the problem domain. In some cases, UTC-only makes a lot of sense, in some cases a pure local time solution may be correct. However, I don’t believe I’ve ever worked on a system where TAI or GPS-time made any sense (not that there are some).
      What frustrates me is that, in most frameworks (the .NET one in particular), Dates are expressed as DateTimes. Sometimes, all I care about is the Date and I don’t care about the time. Tracking Dates with DateTimes means I know need to care about timezones and Daylight Standard time transitions. I’ve spent a lot of time in the past few years arguing that certain things should be stored as SQL Dates rather than SQL DateTimes (/timestamps).

  7. Iain says:

    More fascinating timezone history: https://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzoneinfotz-database/

    As Raymond says “Prefer IANA data sources”, this is deep research they do on your behalf. (Since the article linked above, Olson died and IANA took over stewardship)

Skip to main content