4 ms·
As I understand it, there's two possible breakages. The first is https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ breakages, of the sort described in the a
by geofft 5y ago
As I understand it, there's two possible breakages. The first is https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ breakages, of the sort described in the article - currently, it is possible to distinguish Europe/Oslo and Europe/Berlin, even though they behave the same post-1970. In the planned release it will not be; they will be aliases for each other. This is semver-incompatible in the strictest sense (in much the same way that, say, changing the toString of some object or the formatting of some CLI tool could theoretically break downstream code).
The second is that, if you're actually processing dates before 1970 and you actually care about historic time zones, your code will break unless you go out of your way to load the "backzone" data file.
Probably there is not very much code that is actively processing pre-1970 timestamps (most applications are handling current or relatively recent data) and handling them in localized format instead of having turned them to UTC already and actually doing computations on them (instead of just treating them as strings for display purposes) and working with any of the affected time zones.
- mjw1007 5y agoPeople who have turned pre-1970 local timestamps to UTC already are in some danger of seeing breakage: if they try to turn them back into the local time from the same timezone, they won't get back what they originally entered.
- beerandt 5y agoBut a database with historical changes over time would resolve that. Isn't that part of the argument? "Location x in Timezone P was y definition until z date, when it merged to a definition that coincides with Timezone Q"
- mjw1007 5y agoAs I understand it, that is what you would have had in tz 2021a, but not in the just-released 2021b (unless you enable backzone, but if some distributors start doing that then it's effectively a fork).
- geofft 5y agoI think the API promise is that even if there are known discrepancies pre-1970, the standard database already might not be including that, and so people with pre-1970 timestamps already should have been using backzone.
- beerandt 5y agoShouldn't each time zone, or definition within, have a time domain given for when the definition is valid? Even within a single timezone, dst dates have changed, sometimes differently for different places within the same timezone. DST start/stop dates have changed multiple times in the last couple of decades, so even if pre-1970 isn't a common use, it seems the method for dealing with it would already be required.
- geofft 5y agoYes, and the tz database handles this. (In fact the most immediate trigger for the 2021b release is that Samoa decided to get rid of daylight savings, but obviously did not retroactively change any times in the past... which points to an obvious constraint on that definition, you can specify the starting time where the definition is valid, but you cannot specify the ending time unless you can predict the future behavior of all governments worldwide. There have been tzdata releases with about a day to spare.) In the past, most cities set their noon to actual solar noon, and when rail travel and communications made them pick a time relative to GMT, for a time they specified solar noon in GMT. For instance, America/New_York in the late 1800s gets you GMT-4:56, because that's what was actually used. The rule for the tz database is that if two legislative time zones have the same definition from 1970 onwards, they might only represent them as a single time zone in the database. For instance, there's no America/Miami distinct from America/New_York, even though solar noon is a couple minutes different. As it happens, Oslo and Berlin are the same from 1970 onwards, but the tz database currently has distinct Europe/Oslo and Europe/Berlin definitions. The proposal is to get rid of that distinction. What if Oslo or Berlin vote to change their time zones, though? What if Norway pulls out of the EU in a "Nexit" referendum and then changes their DST to suit their economy? Wouldn't it be worth keeping the distinct Oslo and Berlin time zones? Well, the same thing could happen to Miami, and there's no America/Miami at all right now. There's no sense defining every possible location in the world as a time zone to future-proof against that. It would have to be defined in a future version of the database.
- 0leg00 5y agoInteresting fact: Norway is not a member state of the EU.