Preparing to Fork Tzdb
mm.icann.org
mm.icann.org
Methinks that the burden involved with maintaining a fork (and the benefit of standing on the shoulders of those who do) seems to be missing from a lot of the conversation.
This is less about being cheered along while you're on top and more about when your alone in the muck with no one else grabbing the shovel.
That said, you bring up some very good points.
There is a distinction, though, between tz mailing-list politics (the focus of much of the recent
discussion) and real-world politics (things like, "is Kosovo a country?"). My main worry is the
latter not the former, in that I think it's worth making minor technical changes to tzdb now to
help forestall potentially major real-world political problems down the road, problems
that could be worse than being sued by astrologers. Admittedly not everyone sees things this way.
Rather than get wrapped around the political axle of whether Taiwan counts as a country for purposes of inclusion in the timezone db, it sounds like he wants to just set up a system where tzdb says "here's a time zone that's identified by its biggest city." That way if Taiwan is listed, it's only because it happened to be the biggest city in its timezone, not because the tzdb is making any political statement about its political status.
That's understandable from a certain point of view, but I think it's doomed to failure for a couple reasons:
1) the tzdb never did this in the past, so it's a huge change to the default behavior. Changing the world's timezone names is an enormous change, that will break an f-ton of stuff, so downstream folks are understandably unhappy about it. The moment something important breaks because a system couldn't find "US/Eastern" is the moment this either gets reverted or forked.
2) You may not want to play the political game, but it wants to play with you. City/territory names aren't neutral, either, and are just as political (Derry/Londonderry), so relying on city names doesn't actually solve the problem, it just makes it less likely.
I suspect they're going to have to stick with countries, and let IANA make the determination of what's a country, so they don't have to have gigantic political fights, they can defer to IANA policy.
[1]: https://mm.icann.org/pipermail/tz/2021-June/030177.html
The controversial solution to this is that all places with equal timezones since 1970 have been merged to share a single zone with the pre-1970 history of the largest place in that zone (which might not be valid for the whole zone). There are backward-compatibility links provided so that the old zone names still work, and there was a pre-existing build option to include all known (but incomplete) pre-1970 data, which splits the zones again.
Opponents of that change argue that instead of consolidating currently-alike zones, every currently-existing country should get their own zone with the pre-1970 history of the largest place in that zone (which, again, might not be valid for the whole zone). To do this correctly would of course require someone to volunteer the pre-1970 data for zones that would be split, which notably no one seems to have done yet.
What's most remarkable to me as an outsider is about how incredible niche the usecase where this makes a difference is: you have to be interested in pre-1970 timestamps, but build tzdb without enabling the pre-1970 historic data.
But yes, Paul seems to be clear that it will be prohibited to use the older time zone database for diversity and inclusion reasons. So it does seem to be driven by that to a degree.
This is utter and complete nonsense. He said the old database was incompatible with diversity and equity values, but he never once said anyone would be prohibited from using it.
It has lots of issues.
IMHO the main issue is that 99.99% of its users only become aware of it through setting timezones. It is not designed for setting timezones, and the user experience is frankly terrible, the identifiers are unsuitable, and there is no standard way to present them to non-technical end users.
The maintainers have their head in the sand about its use claiming that they don't provide the 'useful name of timezone' service or the 'useful subset of modern timezones people actually use' service. Instead, they only provide the 'festidious historic list of timezones as researched from sources verging on obscurity' service ("just making sure that the data is correct").
It seems that a large portion of the email list is fixated on that service ("people who know about time and (perhaps) care about little else..." as summarized by one member) and apparently consider the partial shift of some data elsewhere to be sacrilege. Recently it seems the maintainer has had a different idea.
The whole project should probably be reconsidered from scratch by a well meaning body, however it's a thankless task and nobody is going to do a technically solid and apolitical job for free... hence status-quagmire-quo. Popular time is inherently a political beast and a human problem.
However, all fundamental use cases require naming.
Therefore, it makes sense to have in scope.
I dare say if this project were reconsidered today, it would be very different in form and would have at a minimum a clear scope definition and half the stuff there would be elsewhere.
Paul has explained that no fork could be used by any organization that values diversity etc until it (copies?) the changes being made to tz?
" All this work would be need to be done before any such fork could be used by an organization that is committed to equity, diversity and inclusion."
That's major. Basically, the existing tzdb is no longer permitted to be used by any organization that values diversity.
https://mm.icann.org/pipermail/tz/2021-September/030413.html
I was trying to understand what was going on and this was it looks like the key motivator, and importantly Paul has explained that forks CANNOT be used by ANY project that has any claim to diversity / nondiscrimination / etc.