<div dir="ltr"><div dir="ltr">On Thu, Sep 23, 2021 at 8:30 AM Clive D.W. Feather via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Therefore any argument that they should be two or three zones instead needs<br>
to be based on some *other* objective requirement. Which, I suspect, needs<br>
to be *added* to the present policies rather than just handwaved. Such<br>
requirements could be:<br>
* Never abolish a zone once it's got into the default setup.<br></blockquote><div><br></div><div>I could live with this. My chief concerns are (a) we should not arbitrarily make data that are believed to be reliable more difficult to access; (b) we should not surprise users by suddenly making them see different names for their home time zones. (For a Norwegian suddenly to have 'Berlin' instead of 'Oslo' appear is not acceptable.) Could we establish the rule, "don't abolish zones once released, even if they are subsequently discovered to be duplicative"?</div><div><br></div><div>I understand the desire to get rid of data that are known to be incorrect or at least unreliable. I have no objection, for instance, to removing pre-1970 data from Montréal if it appears that Shanks compiled incorrect information. While that might change the interpretation of historical dates to be a proleptic version of whatever the situation was in 1970, that at least keeps things compatible, and is no different in effect from a correction to the historical information.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* At least one zone per 3166 "country".<br></blockquote><div><br></div><div>I don't see this as necessary, but it's Mostly Harmless. Links are cheap. It still would run afoul of similar problems to the one we are facing, because it's entirely possible that a zone with deleted data will turn out to be in a country with multiple zones.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* At least one zone per "authority".<br></blockquote><div><br></div><div>This one is almost certainly unworkable, since it puts whoever maintains tzdb in the position of determining who is a competent authority. We have known cases where a region with an ethnic, religious or political minority maintains a different time zone in defiance of a central authority, or where there is a time zone maintained by a government whose legitimacy is disputed.  Moreover, there is a definite problem with multiplication of authorities (see below).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Use separate zones if we have reliable data going back to 1945 (or pick<br>
some other year).<br></blockquote><div><br></div><div>From a US-centric perspective, the choice of 1970 was not exactly an accident. If you go back much farther, you run into tremendous Balkanization of local authorities.  I can recall one archivist that I knew regaling me with the story of the time in the late 1960's that he had to endure no fewer than seven time zone changes in the course of a 45-minute bus journey, because individual towns and counties in West Virginia and Ohio had decreed different dates for the Daylight Saving Time transition. The date could readily be pushed back to 1967. Prior to that, what we would have would be valid only for individual municipalities; :America/New_York would not have the same rules as a hypothetical :America/West_Virginia/Charleston. (Charleston in turn would not have the same rules as Wheeling, Moundsville or Morgantown. It was an unbelievable mess back then. </div></div><br clear="all"><div><br></div>-- <br><div dir="ltr">73 de ke9tv/2, Kevin</div></div>