The 2018c Timezone Database Update

back

    I subscribe to a couple of mildly interesting and low-volume email lists. One such list is the tz-announce list hosted by ICANN. It’s the list for people who care way too much about timezones.

The other day I got an email that the 2018c release of the database was available. There are a couple of interesting changes in it, which I thought would be fun to look at and consider the implications.

    São Tomé and Príncipe switched from +00 to +01 on 2018-01-01 at 01:00.

    So, in this range of hours, an hour will be missing in the middle of it.

    Starting in 2018 southern Brazil will begin DST on November’s first Sunday instead of October’s third Sunday.

    Oh man. Daylight Saving Time. I really don’t get why this is still a thing.

    Japanese DST transitions (1948-1951) were Sundays at 00:00, not Saturdays or Sundays at 02:00.

    These first three changes are to the past and future, which brings up some really interesting stuff when it comes to storing timestamps. Any time you change the past (or the future), you deal with the possibility of invalidating already-saved information.

    Let’s consider the Brazil change as an example. Brazil is notorious among chronologists for performing its Daylight Saving Time jumps at midnight, which means that on the “spring forward” jumps, midnight doesn’t exist. And, like all DST jumps, the leap back produces an hour that occurs twice.

    In this case, Brazil will be “springing forward” (because even though it’s November, that’s Spring in southern Brazil). Therefore, midnight isn’t going to exist.

    Now, what happens if you run a scheduling service and you had scheduled something to happen at midnight on November 4th, 2018? Suddenly, that time doesn’t exist anymore. When you scheduled that information, “November 4th 2018 @ 00:00:00 AM” was a totally legitimate date. Now it’s not.

    Similarly, if I happened to be storing a date relating to a midnight in Japan after the end of World War 2, there’s a chance that that date is now invalid.

    Time zones are already crazy complicated. Changing past and future time zone transitions just compounds the effect.

    A discrepancy of 4s in timestamps before 1931 in South Sudan has been corrected.  The ‘backzone’ and ‘zone.tab’ files did not agree with the ‘africa’ and ‘zone1970.tab’ files.

    I guess a bug was fixed in the file? And it was 4 seconds off? Ack.

    The abbreviation invented for Bolivia Summer Time (1931-2) is now BST instead of BOST, to be more consistent with the convention used for Latvian Summer Time (1918-9) and for British Summer Time.

    I hope you don’t store dates using the abbreviated timezone name. If you do, and you happened to be storing a date in Bolivia Summer Time from between 1931 and 1932 (all 3 of you), then this just broke.

So there you have it. Not very many changes, but definitely things of consequence. If you’re interested, I recommend subscribing to tz-announce. There’s only a few emails a year and it’s always interesting to see political and historical actions affecting technology.

Related️️ Posts️