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.
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.
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.
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.
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."
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.
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.
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.
Then again, that article might be outdated...
