I would agree to both of these.

I also think it would be preferable to restore (with corrections if necessary) all the distinct zones per ISO country that have varied since 1970. Russia and Canada have numerous timezones, just as the USA has, and it would simplify access, as well as providing more historical data per country.

Overall my preference is to make historical data available for as many cities as possible / per country, in one place; or for at least all zones per country that have differed since 1970. If they link is to generic 'noname' zones which crosses political boundaries, then I could also be happy with that, as long as no historical data is lost.

In the long run, app developers will also want historical data for separate zones that merged before 1970, and they could exist in a secondary table, managed by tz, or even managed by someone else as a separate project.

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   |

|---------------------------------------------------------------------|