I should add that no research scientist expects all historical data to be perfect before publishing. History always gets murkier the further you go back. All historical data is in fact best-guess, published so it can be improved upon We should be providing a forum for this.. See below..Sent from my Galaxy -------- Original message --------From: dpatte <dpatte@relativedata.com> Date: 2021-09-22 18:32 (GMT-05:00) To: Guy Harris <gharris@sonic.net> Cc: Watson Ladd <watson@cloudflare.com>, tz <tz@iana.org>, Eliot Lear <lear@lear.ch> Subject: Re: [tz] Preparing to fork tzdb I don't believe anyone has suggested that zones should be limited to 'only one zone per country'. I certainly never sugested that. In fact quite the opposite. But I believe there should be AT LEAST one zone per iso country, and it was the removal of the Montreal historical data a few years back that got me started.If it's THE tz database, it should be able to provide not only since-70 history, but be expandable to all tz history, potentially back to the 1800s when most cities implemented local mean time as local standards.I recognize many users of this db dont need pre1970 history, and perhaps they could filter for only recent data. But many apps need UT (gmt) before 1970 as I mentioned. Think astronomy apps, for example.Up until recently some of this data was available in the main tz file. We need that back, with the ability to expand and improve it. This should be possible without expanding the post1970 table.Sent from my Galaxy-------- Original message --------From: Guy Harris <gharris@sonic.net> Date: 2021-09-21 21:02 (GMT-05:00) To: dpatte <dpatte@relativedata.com> Cc: Watson Ladd <watson@cloudflare.com>, tz <tz@iana.org>, Eliot Lear <lear@lear.ch> Subject: Re: [tz] Preparing to fork tzdb On Sep 21, 2021, at 4:51 PM, dpatte via tz <tz@iana.org> wrote:> Date: 2021-09-21 18:49 (GMT-05:00)> To: dpatte <dpatte@relativedata.com>> Cc: Eliot Lear <lear@lear.ch>, "Clive D.W. Feather" <clive@davros.org>, tz <tz@iana.org>> Subject: Re: [tz] Preparing to fork tzdb> >> On Tue, Sep 21, 2021 at 3:42 PM dpatte <dpatte@relativedata.com> wrote:>> >>> The strategy used since tz was created has caused many political arguments and decisions in this group instead of deferring the decisions to the ISO that has this mandate.>> >> ISO countries doesn't solve some of the thorny political issues,>> because ISO codes don't take a position on boundary disputes or naming>> disputes. E.g. Crimea. When the invasion happened, the civil time in>> the region occupied changed. That means a new zone entry needed to be>> created. I don't know how defering to ISO resolves the naming of that>> one.>> >> The other example would be Palestine. Regardless of what ISO decides,>> the time in Palestine is what it is, and is different from Israel in>> funny ways, and the territories that have gone back and forth have>> gone back and forth and thus need new entries.> > Incorrect..> > Iso 3166> > Ramallah is recognized in the State of Palestine.And Hebron, presumably - it's the city used for West Bank Palestine.> Sevastopol is recognized as a city as being in Ukraine.But it's not a city used for a tzdb - Simferopol is.And Kyiv is also a city in Ukraine, but, as far as I know, it keeps different time from Simferopol, and the tzdb recognizes that.However, "deferring to ISO" doesn't mean "providing one *and only one* tzdb region per ISO country"; such a policy would not work very well for the three largest countries listed in the northamerica file, for example.If, indeed, Crimea and the rest of Ukraine do not, in practice, keep the same time, then, hopefully, "deferring to ISO" also wouldn't mean "giving Crimea the same offset and rules as the rest of Ukraine".