<div dir="ltr"><br>A partly-baked idea:  would it make sense to allow something like a link in a Zone record?<br><br>Let's say that, if the first character in the GMTOFF column is not a decimal digit or a '-', then GMTOFF is the name of another Zone.  The only other column in such a record would be [UNTIL].<br><br><div><span style="font-family:arial,sans-serif">As an example, let's say that America/Shiprock becomes a Zone, and that the Navajo people followed Arizona time until that state opted out of DST.  That Zone might look something like (I'm just making this up):</span></div><div><span style="font-family:monospace"></span></div><span style="font-family:monospace"><br># Zone  NAME            GMTOFF   RULES  FORMAT  [UNTIL]<br>Zone America/Shiprock   -6:59:56 -      LMT     1883 Nov 18 12:00:04<br>                        America/Phoenix         1967<br>                        America/Denver<br><br></span><div><span style="font-family:arial,sans-serif">That would be easy to parse.  The "interesting" bit would be figuring out which row in the linked Zone we should start with.  It would be the row following the one whose [UNTIL] is the greatest lower bound of the date of interest.</span></div><span style="font-family:arial,sans-serif"><br></span><div><span style="font-family:arial,sans-serif">Downstream systems that use the source files directly would need access to files with the older format for a while to give them time to change their parsers.  (Maybe the first column in a new Zone record could be something other than "Zone".)<br></span></div><span style="font-family:monospace"><span style="font-family:arial,sans-serif"><br>--Bill Seymour</span><br></span><br><br><br>On Sun, Jun 6, 2021 at 10:03 AM Tom Lane via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br>><br>> Stephen Colebourne via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> writes:<br>> > [ assorted proposals ]<br>><br>> One other issue that I think deserves more attention than it has<br>> gotten lately is that tzdb has become a de facto standard and users<br>> rely on its stability.  I would like to see some sort of principle<br>> adopted that minimizes changes in historical data.  In particular,<br>> I think it's past time to prohibit data changes adopted for<br>> essentially-administrative reasons (as opposed to new findings of<br>> historical fact).  I'd put the recent reorganization under the<br>> heading of things that would be forbidden by this principle, and also<br>> the changes a few years ago that removed "made up" zone abbreviations.<br>> Whatever the justification for those abbreviations originally, some<br>> people had come to depend on them, and little was to be gained by<br>> removing them.<br>><br>> Looking at Stephen's list with this in mind, one thing I'd vote<br>> against is redefining the LMT offsets.  Yeah, I suggested that<br>> myself a few days ago, but that was in the context of what seemed<br>> to be a fait accompli that would largely destroy tzdb's backward<br>> compatibility anyway.  If we're going to reverse that choice and<br>> try to preserve the existing pre-1970 data, then preserving the<br>> existing LMT data goes along with that.<br>><br>> The idea of having at least one zone per ISO-3166-1 country does<br>> seem like a good one, though.  Aside from possibly deflecting<br>> politically-based complaints, this seems basically like future<br>> proofing: even if two countries have shared clocks since 1970,<br>> they could diverge at any time.  Being prepared with an appropriate<br>> zone name should minimize the pain to users.  Also notice that<br>> splitting an existing zone creates no compatibility problems, since<br>> no one is obligated to switch to the new zone name immediately.<br>><br>>                         regards, tom lane</div>