Big problems at the timezone database
blog.joda.org
blog.joda.org
There has been two major ways to use the Timezone Database other than using the bundled tzcode. One is to use the compiled TZif file (intended to be used by tzcode, but also standardized in RFC 8536). Another is to use the textual format that is compiled to TZif via zic. The latter option was never intentional but used by a significant number of downstream projects including Joda-Time. And every time the textual format slightly changes, Colebourne complains about the breakage despite that breakage was induced by Joda-Time itself. And it has also caused a significant maintenance burden to the tzdb: most notably rearguard/vanguard splits [1].
This time Colebourne is complaining not because pre-1970 timestamps will be altered---they have changed a lot in the past---but because Joda-Time was falsely assuming that the zone never turns into an alias. Therefore Colebourne should have requested more concrete and reasonable guarantees for the tzdb. Instead he is claiming Joda-Time is representative of downstream projects and the tzdb should follow what Joda-Time is assuming. This annoying attitude is evident when you also look at Mark Davis (who is in charge of CLDR); while Davis agrees that the patch should be reverted (reasonably so) he is much more careful about his wording.
Technically speaking it has been true since 2014 that any time zones that looked alike before 2014 can be merged. The only difference is that, multiple such time zones across multiple countries were not merged yet at that time. That's what Eggert refers to the equity or fairness principle, but personally I came to think that he is actually giving marginal and tangential reasons to implicitly express the disdain about Colebourne.
There are a lot of contexts in which I need to know the TZ. Logs are a really common one (though they should be in UTC). Calendars are the most common.
I've seen a few calendar systems that default to the invite sender's TZ. I needed to know TZ to appropriately schedule my calendar.
I didn't meant that. I'm dissecting the problem into two cases here: for end users it is always possible to replace the tzid with labels (possibly tailored) so tzid doesn't have to be exposed at all, and for developers it is required to abolish textual tzids. The latter would require the cooperation and concensus from tzdb's (and contributors') part.
For recurring events, you absolutely need to know the TZ. You have teams in the Bay Area and London (common for many tech companies). You are in SF and have a recurring meeting with London on Monday mornings. The meeting today (Sep 27) is at 10AM, or 6PM London time. At what time will the meeting be on Nov 1?
Texan here. When I was a kid, I would get salty when the computer said I was in "Chicago time". I thought we deserved our own time zone.
Then again, that article might be outdated...
Ah, the 'F' word.
This becomes the fig leaf for vast injustice in the name of justice.
So while I do agree that backwards compatibility is important, and I hope the technical changes are resolved in a way that seems to match the consensus of everyone else on the list besides the TZ Coordinator... if one were constructing a time zone database from first principles these days, I'm not sure what the argument would be to prefer Reykjavik as the synechdoche for the time zone to Abidjan, besides "It's in Europe."
Bonus points if it's an online poll where the game becomes hacking as much votes as possible without getting caught.
There are two ways to make the tzdb more consistent: either merging time zones that are alike since 1970, or splitting time zones as much as possible. The latter was the pre-2014 approach and much harder to maintain (after all, should we split time zones just for newly discovered pre-1970 time zone differences?), so the tzdb has gradually switched to the former for a decade. This patch is just a continuation of this ongoing switch.
Alternatively, it might be possible to keep the latter approach but limit the scope so that the maintenance remains doable. For example the tzdb can forgo textual time zone identifiers and declare that downstream projects are responsible for the mapping to the external world (and thus politics). However that would make the tzdb much less useful. The current policy does seem to maximize the value of the database without much trouble (that is, limited to a minor drama) and any change to the policy requires a serious consideration about that. In comparison the forking proposal by Colebourne is at best naive.
Having to chose a single town on each timezone is just bound to be problematic whatever the criteria are, and it would also mean endless arguments about changing timezone names when the chosen town doesn't meet these criteria anymore.
In a way it would help a lot to expand geographic knowledge, especially if the europe and US were all mapped to somewhere in the south hemisphere.
Plus countries change timezones. I can set it to "+8:00" and in two years my country changes its timezone and now the stored information (and thus my time) is incorrect. We also need to know on which date the change takes effect, because showing the wrong time for tomorrow or next week would otherwise show the wrong time.
I actually store timezones as "<country>.<zone>". e.g. NL.Europe/Amsterdam. This is because users select the country first in the UI (rather than a zone), and this way it will always be clear which country the user selected. It would be confusing at best, and potentially offensive, to show a different country later.
That is exactly the wrongest thing to do, because your version makes it impossible to plan future local events.
It would essentially be a completely useless intermediate layer between something very similar to the current timezones and the "absolute" times below.
Yes you are.
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.
"Location x in Timezone P was y definition until z date, when it merged to a definition that coincides with Timezone Q"
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.
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.
If we want to get into a complicated mess, let's talk about daylight savings time and regional exceptions, but I'm not really sure how we're going to make everything "fair" one way or another. Next we'll be arguing about states vs countries, population vs power, god knows what else... it's all just not in the interest of good time keeping.
Time zones are a necessary evil, ideally our code doesn't suffer from our petty human concerns.
I don't understand this position. The sole purpose of our code is to serve "petty" human concerns.
Time zones are certainly not petty human concerns; the notion that we sleep when it's dark and we're active when it's light is fundamental to our nature - as is the fact that we want to coordinate our activity with those around us. Time zones are probably the most effective outworking of this. Some alternatives are conceivable (for instance, we could record times in UTC) but they would effectively introduce the same problems (for instance, if business hours are set to run from 23:00-07:00 in some location, and then as trade patterns change it's agreed to reset them to 22:00-06:00, we need some way to know that we need to reschedule events scheduled for 06:30 in that location but not events scheduled for 06:30 in a different location) along with new ones (for instance, most people would be pretty upset at having the date change in the middle of the day, just because it's convenient in Europe).
Timezones are fundamental to any code that cares about human events in the future or the past.