Hacker News new | past | comments | ask | show | jobs | submit login
Preparing to Fork Tzdb (icann.org)
51 points by vitplister 75 days ago | hide | past | favorite | 12 comments

Reading through the thread it's painful to watch Paul Eggert keep stepping up to the plate to build consensus, steward the community, and try to make sure no one is left behind (https://mm.icann.org/pipermail/tz/2021-June/030197.html, https://mm.icann.org/pipermail/tz/2021-September/030388.html, https://mm.icann.org/pipermail/tz/2021-September/030399.html, https://mm.icann.org/pipermail/tz/2021-September/030413.html, https://mm.icann.org/pipermail/tz/2021-September/030422.html, https://mm.icann.org/pipermail/tz/2021-September/030423.html just as a snippet).

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.

I dunno... when you have the developer of Joda-Time, the lead developer of PostgreSQL, and a big name from PHP all talking how a fork is required and how all of these attempts to play whack-a-mole on issues--what I guess you are calling "building consensus"?--are just making the matter worse, it seems difficult to claim that no one understands the burden of maintaining a fork... certainly, to pull one person in particular here that I highly respect: I would personally put a lot of trust into Tom Lane to be making a very well informed (and reasonable) decision here.

It's easy to hear the sirens song of confirmation bias and crash on the rocks. Just because one knocked it out of the park on PostgreSQL doesn't mean that lightning will strike twice.

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.

It sounds to me like this whole thing is based on Paul Eggert trying to preemptively avoid the political question of "what is a country?". He says in one of the threads [1]:

  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.
...the elephant no one seems to be talking about as the canonical example of the question is Taiwan.

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

Another motivation behind the change seems to be to treat all countries equally. Previously, some countries (such as Norway and Sweden) with equal timezones since 1970, but differing timezones before 1970 got their own zone, while other countries in the same situation (such as Angola and Niger) shared a zone.

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.

Some of the alternative proposals were (I think) to do time zones based on time zone authorities / to do timezones per country etc. So instead of merging countries that share the same timezones you would add entries? I will say it was hard to follow.

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.

> Paul seems to be clear that it will be prohibited to use the older time zone database for diversity and inclusion reasons.

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.

Where is this coming from? Is there actual technical merit or is someone (read China) complaning?

TZDB would be a great case study in open source.

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.

The localized 'useful name of timezone' is part of the Unicode CLDR, which lets you map to the IANA and Windows timezone identifiers. Avoiding scope creep is a good thing, especially when there are other groups better positioned to do the work.

I agree about scope, but they've already thrown that out the window by including biggest-'city'-in-the-zone approximations and other such cruft.

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.

Interestin -

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.


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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact