[tz] What data should TZDB offer?

[Tom Lane]

Stephen Colebourne via tz <tz at iana.org> writes:
> [ assorted proposals ]

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.

Looking at Stephen's list with this in mind, one thing I'd vote
against is redefining the LMT offsets.  Yeah, I suggested that
myself a few days ago, but that was in the context of what seemed
to be a fait accompli that would largely destroy tzdb's backward
compatibility anyway.  If we're going to reverse that choice and
try to preserve the existing pre-1970 data, then preserving the
existing LMT data goes along with that.

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.

			regards, tom lane