On Jun 6, 2021, at 11:02, Tom Lane via tz <tz@iana.org> wrote:
One other issue that I think deserves more attention than it has gotten lately is that tzdb has become a de facto standard and users rely on its stability. I would like to see some sort of principle adopted that minimizes changes in historical data. In particular, I think it's past time to prohibit data changes adopted for essentially-administrative reasons (as opposed to new findings of historical fact). I'd put the recent reorganization under the heading of things that would be forbidden by this principle, and also the changes a few years ago that removed "made up" zone abbreviations. Whatever the justification for those abbreviations originally, some people had come to depend on them, and little was to be gained by removing them.
[…]
The idea of having at least one zone per ISO-3166-1 country does seem like a good one, though. Aside from possibly deflecting politically-based complaints, this seems basically like future proofing: even if two countries have shared clocks since 1970, they could diverge at any time. Being prepared with an appropriate zone name should minimize the pain to users. Also notice that splitting an existing zone creates no compatibility problems, since no one is obligated to switch to the new zone name immediately.
These two points in particular are synergistic; stability of historical data is just a Good Thing, but no one here wants to see the TZDB maintainer receiving ‘vitriolic’ e-mail, nor getting sued [again]. Hence, politically ‘future-proofing' the DB seems a prudent move. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------|