16 votes

Discussion of forking the IANA time zone database (tzdb) over a disagreement about how to handle pre-1970 time zones

2 comments

  1. [2]
    spit-evil-olive-tips
    Link
    HN discussion some additional mailing list threads from June: [PROPOSED] Merge timezones that are alike since 1970 Breach of tzdb charter: Merging timezones is not within the charter Undoing the...

    HN discussion

    some additional mailing list threads from June:

    this is a really messy controversy and even after reading a bunch of these mailing list threads I'm not sure I understand it completely...but as far as I can tell, the root of the disagreement was based on a "cleanup" type change.

    the example used in a lot of the threads is that Germany, Sweden, and Norway all share the same timezone, and have since 1970. so rather than maintain those 3 separate files, they get merged into 1.

    except...they did have different time zones, prior to 1970. so for the small fraction of users who have timezone-aware pre-1970 historical data from these regions, upgrading tzdb amounts to silent data corruption. representatives from both Postgres and PHP have said their projects would likely switch to the fork for this reason.

    complicating matters is that tzdb seems to use a sort of BDFL style of governance, where one person has final say in what changes to ship. that "Coordinator" is a CS professor at UCLA, Paul Eggert, who is the one pushing the change to merge time zones. there is a proposal following IANA procedure to replace him as coordinator that does not seem to be getting much traction.

    Eggert claims that the goal is to promote equity, diversity and inclusion...to the point of saying that any fork should not be used by an organization "committed to equity, diversity and inclusion". the idea here seems to be that some countries (Angola and Niger are his examples) are already merged in the database despite having different pre-1970 histories. and his solution seems to be...to squash Germany/Sweden/Norway's history together, so that it's equal in terms of historical inaccuracy with Angola & Niger, I guess?

    further complicating things is that the time zone merge in question was already committed to the development branch of tzdb, so it'll go out in their next release. and their hand may be forced here, because Samoa announced with about 2 weeks notice that they're not switching to Daylight Savings Time this year. proposals to revert the controversial change temporarily so that they can release just the update for Samoa while continuing to discuss the merge also seem to have gone nowhere.

    10 votes
    1. Thra11
      Link Parent
      So it looks like data before 1970 isn't entirely supported and is potentially outside the scope of tzdb[1]: The problem is that while people should have been aware of this, and not relied on tzdb...

      So it looks like data before 1970 isn't entirely supported and is potentially outside the scope of tzdb[1]:

      Data before 1970 aims to be correct for the city identifying the region, but is not necessarily correct for the entire region. This is because new regions are created only as required to distinguish clocks since 1970.

      The problem is that while people should have been aware of this, and not relied on tzdb for accurate representation of historical (pre 1970) timezones, there is presumably a subset of historical data for which tzdb appears to work ok, despite offering no guarantees that it should, and if something appears to work, people will use it.

      So we seem to have a change which is technically correct as far as the stated aims of the project are concerned, but which in practical terms may break things for some users. Of course... relevant xkcd.

      7 votes