<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <p>I did a short check on the ISO 3166-1-rule compliance of the
      current release.</p>
    <p>It seems that most cases, in which zone1970.tab lists multiple
      countries on the left hand side (tied to one timezone id), there
      do exist corresponding "Link" entries. <br>
    </p>
    <p>The "VN" in "TH,KH,LA,VN" is the only case I found so far, in
      which there is no "Link" backing this with a separate identifier
      (I know the HCM/Hanoi case is special; this is just an
      observation).</p>
    <p>Example:</p>
    <pre>[zone1970.tab]
CZ,SK   +5005+01426     Europe/Prague</pre>
    <pre>[europe]
# Slovakia
Link Europe/Prague Europe/Bratislava

</pre>
    <p>Is anybody aware of how upstream software based on tzdb is
      typically dealing with "Links"? It seems, Java does list time zone
      ids stemming from "links", while "tzselect" on my Ubuntu machine
      does not seem to use them - at least not in the interactive
      configuration [1]<br>
    </p>
    <p>(Side note: the "Link" syntax does not seem to be explained yet
      in <a class="moz-txt-link-freetext" href="https://data.iana.org/time-zones/tz-how-to.html">https://data.iana.org/time-zones/tz-how-to.html</a>)<br>
    </p>
    <p><br>
    </p>
    <p>Further observations:<br>
    </p>
    <p>The "zone.tab" file actually uses the "Link" aliases, while
      "zone1970.tab" does not:<br>
    </p>
    <pre>[zone.tab]
CZ      +5005+01426     Europe/Prague
SK      +4809+01707     Europe/Bratislava

vs. 

[zone1970.tab]
CZ,SK   +5005+01426     Europe/Prague</pre>
    <p>...so one will yield different results depending on which .tab
      file an application uses.<br>
    </p>
    <p><br>
    </p>
    <p>Also, "zone.tab" only offers "Asia/Ho_Chi_Minh" for VN (missing
      out "Asia/Bangkok", which I guess according to tzdb guidelines
      should be there?):</p>
    <pre>VN       +1045+10640     Asia/Ho_Chi_Minh</pre>
    <p>(not sure if the latter was already covered in the Hanoi thread)</p>
    <p>Best,<br>
      Hans-Joerg<br>
    </p>
    <p><br>
    </p>
    <p>[1] tzselect output on Ubuntu after choosing the respective
      country:<br>
      <br>
      The following information has been given:<br>
          Slovenia<br>
      Therefore TZ='Europe/Belgrade' will be used.<br>
    </p>
    <p>The following information has been given:<br>
          Oman<br>
      Therefore TZ='Asia/Dubai' will be used.<br>
    </p>
    <p>The following information has been given:<br>
          Cambodia<br>
          Indochina (most areas)<br>
      Therefore TZ='Asia/Bangkok' will be used.<br>
      <br>
    </p>
    <div class="moz-cite-prefix">On 20.02.19 17:40, Hans-Joerg Happel
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:413ab0e4-0227-be00-4b99-dce0f1c30e90@audriga.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p><br>
      </p>
      <p>This is basically what I was about when asking for the "scope"
        of tzdb, and might end up in a similar discussion concerning
        timezone ids just like the Wikipedia's inclusionism/exclusionism
        debate.</p>
      <p>Standpoints:</p>
      <p>a) (Exclusionist) Timezone ids should be kept at a minimum
        level required to model tz rules appropriately<br>
        b) (Inclusionist) There should be at least one timezone id for
        each ISO 3166-1 TLC<br>
        ...and as the "Hanoi" case would not be covered by (b) the even
        extended inclusionist approach would rather be something like: <br>
        c) (Inclusionist+) There should be at least one timezone id for
        each "timezone" (in the sense of tzdb's consistent-since-1970
        definition) for each ISO 3166-1 TLC</p>
      I see the point of simply sticking to (a). However, not all all
      users of tzdb will grasp this, and so there will always be
      considerable "misuse" of timezone ids and discussions such as the
      recent "Hanoi" thread.
      <p>However it looks like there is no real solution to this, as
        either choice has its subtleties. So sticking to the status quo
        might be the best to do for now.</p>
      <p>While I think I understand the perspective of people who are
        arguing to focus on core tzdb maintenance, I'd however encourage
        tzdb "users" (which I guess are also represented on this list)
        to speak up regarding challenges they observe.</p>
      <p>I think such discussion might be worthwhile 1) to raise
        sensitivity for tzdb usage challenges in this community and 2)
        to better understand pain points in the usage of time zones /
        time zone identifiers in general.<br>
      </p>
      <p>For instance, has anybody ever seen an approach such as advised
        in the note suggested by Paul [1], or are we actually all
        sticking to just storing  tzdb identifiers?</p>
      <p>Thanks and best,<br>
        Hans-Joerg</p>
      [1] <br>
      <pre class="moz-quote-pre" wrap="">Timezone boundaries are not part of the stable interface.
For example, even though the <samp>Asia/Bangkok</samp> timezone
currently includes Chang Mai, Hanoi, and Phnom Penh, this is not part
of the stable interface and the timezone can split at any time.
If a calendar application records a future event in some location other
than Bangkok by putting "<samp>Asia/Bangkok</samp>" in the event's record,
the application should be robust in the presence of timezone splits
between now and the future time.</pre>
      <div class="moz-cite-prefix">On 20.02.19 13:37, Stephen Colebourne
        wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CACzrW9AoK4EeTbG1CqT49Y3KZ4NFKuo53FRi-Og2OV+4XN2XWw@mail.gmail.com">
        <pre class="moz-quote-pre" wrap="">I strongly oppose this patch. At least one zone per ISO 3166-1 is a
vital part of this project and an entirely sensible rule. It is what
users expect the project to provide.

TZDB identifiers are used incredibly widely, and are seen on many
public-facing systems. I understand that is not seen as desirable by
some here, but it is the truth. When a country splits, it is usually
for painful reasons. The idea that the half of the country should be
forced to use the old identifier simply isn't tenable.

Stephen


On Tue, 19 Feb 2019 at 23:17, Paul Eggert <a class="moz-txt-link-rfc2396E" href="mailto:eggert@cs.ucla.edu" moz-do-not-send="true"><eggert@cs.ucla.edu></a> wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">On 2/19/19 2:31 PM, Tim Parenti wrote:
</pre>
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">So, since it's pretty clear that the "There should typically be at
least one name for each ISO 3166-1 officially assigned two-letter code
for an inhabited country or territory" guideline has been, if not
abandoned entirely, at least significantly de-prioritized, perhaps
theory.html needs an update indicating that, yes, this /used/ to be
considered more important, but is not any longer (perhaps going a bit
into the rationale), and that we don't intend to create new zones
anymore if that's the only justification.
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">Sounds good to me; proposed patch attached.

</pre>
        </blockquote>
      </blockquote>
      <br>
      <pre class="">-- 
audriga GmbH
Durlacher Allee 47
76131 Karlsruhe, Germany
Tel: +49 (0) 721 17029 316
Fax: +49 (0) 721 17029 3179

<a class="m_-745030944823917949m_-7737262847214818316moz-txt-link-abbreviated" href="http://www.twitter.com/audriga" rel="noreferrer" target="_blank" moz-do-not-send="true">www.twitter.com/audriga</a>
<a class="m_-745030944823917949m_-7737262847214818316moz-txt-link-abbreviated" href="http://www.audriga.com/" rel="noreferrer" target="_blank" moz-do-not-send="true">www.audriga.com</a>

Handelsregister: Amtsgericht Mannheim - HRB 713034
Sitz der Gesellschaft: Karlsruhe
Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel
USt-ID: DE 279724142</pre>
    </blockquote>
  </body>
</html>