<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Dear Paul,</p>
<p>thanks for the elaboration - further comments inline<br>
</p>
<div class="moz-cite-prefix">On 19.02.19 17:34, Paul Eggert wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2c9a6528-aa33-4db1-3b9c-fcfa5008f960@cs.ucla.edu">Hans-Joerg
Happel wrote:
<br>
<blockquote type="cite">So any information on the rationale for
the above-quoted rule is
<br>
appreciated.
<br>
</blockquote>
<br>
When I introduced locations as tzdb identifiers long ago, I
naively put in one Zone or Link per country. Some users got
accustomed to the idea that Zone and/or Link status was akin to
political recognition of countries or their boundaries (is Kosovo
a country? is Jerusalem part of Palestine? that sort of thing) and
so I eventually realized my mistake: the identifiers are now
supposed to be single locations, decoupled from countries or
national regions.
<br>
<br>
At one point I attempted to simplify the database by coalescing
regions that crossed country boundaries, since there's no longer
any need to conflate the two. Unfortunately this flustered some
users who thought this meant disrepect to particular countries
(which was not the intent). After some back and forth we ended up
with the current wording, which I'm not happy with, as the current
rules are still too political and we still end up with "There
should be an entry for Hanoi/Beijing/etc.!" discussions.
<br>
<br>
If this continues to be a sore spot, I'm inclined to adjust the
rules so that there need not at least one Link or Zone per
country. This should help simplify future maintenance if, say, the
US splits into multiple countries (and stuff like that does
happen).
<br>
</blockquote>
<p>I'd see two different kinds of "maintenance" here:</p>
<p>* Maintenance of tzdb (which you are referring to)<br>
* Maintenance of systems/data by people using tzdb (directly or
indirectly)</p>
<p>So in your example - if say, Washington (the federal state) would
become a separate country, you argue to keep maintenance of tzdb
low by sticking to "America/Los_Angeles", whereas one could argue
for a link from "America/Seattle" (or the like) according to the
current ISO 3166-1 rule in [1].<br>
</p>
<p>On the other hand, if Washington users could make use of such an
"America/Seattle" alias, that could reduce maintenance effort in
the event of of the new country of Washington deciding to deviate
from "America/Los_Angeles" rules (which, as you say is stuff that
will happen one or the other way).<br>
</p>
<p>To be clear: I perfectly understand that the first kind of
"maintenance" is the main concern of the tzdb community. <br>
</p>
<p>However, I am trying to make a point that tzdb design decisions
may have further kind of impact (second aspect of maintenance),
and I wonder to what degree these concerns are shared.</p>
<p>Another point I made was that in my experience some applications
"misuse" tzdb identifiers as actual time zone names shown to
users. While I agree it would be better to solve this on a more
general level such as geo-location<=>timezone mappings (and
I know efforts in that direction exist) I'd still argue that one
won't get around that "misuse" practice anytime soon. It's a
matter of philosophy if that counts as an argument for the ISO
3166-1 rule case.</p>
<p>Disclosure: I am involved in CalConnect's efforts to advise
governments and practitioners on how to tackle time zone issues.
Therefore I am trying to get a better understanding of how things
work and appreciate your feedback, even if it might slightly go
beyond the scope of pure tzdb maintenance.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:2c9a6528-aa33-4db1-3b9c-fcfa5008f960@cs.ucla.edu">
<blockquote type="cite">I see there are recommendations for
implementers regarding
<br>
localization (e.g., reference to Unicode CLDR), but I could not
find
<br>
recommendations concerning the usage of tzdb
names/ids/links/aliases -
<br>
which, in my understanding, will be the String persisted by most
<br>
applications in the end?
<br>
</blockquote>
<br>
Although the "Names of timezones" section in
<a class="moz-txt-link-rfc2396E" href="https://data.iana.org/time-zones/theory.html"><https://data.iana.org/time-zones/theory.html></a> talks about
this, it sounds like you think something is missing. I'm not sure
what sort of recommendations you're thinking about, though.
Perhaps you could suggest a specific wording change to that
section?
<br>
</blockquote>
<p>I'd perhaps first suggest to talk about "Identifiers of
timezones" instead of "Names of timezones". The distinction may
sound picky, but I've the impression some discussions (such as the
"Hanoi" one) circle around the misunderstanding of "Asia/Bangkok"
being some sort of semi-official "name" while it is supposed to be
(as you pointed out above),</p>
<p>A second suggestion would be a short note that it is these
identifiers which would be typically stored in database / system
configuration / appointment in order to denote the time zone of a
"thing" and that software will typically pick up the additional
rule data in tzdb in order to compute meaningful things based on
these identifiers. This is sort of implicit to the given text, but
might be pointed out more explicitly.<br>
</p>
<p>Note that my perspective here is rather from an end user /
developer point of view and I acknowledge that this is not the
main audience of tzdb content. However I'd argue that end users /
developers might find some clarification on this useful when
considering their use of identifiers which ultimately stem from
and are maintained by tzdb.</p>
<p>I don't know the change policy of theory.html, but if there's
some agreement that I have a point here, I'd be happy to propose
more particular wording changes.</p>
<blockquote type="cite"
cite="mid:2c9a6528-aa33-4db1-3b9c-fcfa5008f960@cs.ucla.edu">
<br>
<blockquote type="cite">setting "Vietnamese" data or systems to an
"Asia/Bangkok" tzdb
<br>
identifier would, to some degree, effectively tie that data to
Thai
<br>
legislation.
<br>
</blockquote>
<br>
No, it ties that data to our best guess of what northern Vietnam
etc. will do. It does not tie the data to any legislation, just as
setting "Moroccan" data or systems to "Africa/Casablanca" ties
that data to our best guess of what Morocco will do, regardless of
existing legislation. In both cases our guesses may well be wrong
and if so users will need to deal with the wrong guesses, which is
just part of life when predicting the future. If we started
letting political considerations affect how we record our guesses,
that would lead to more controversy and more database churn and
I'd rather not go that direction.
<br>
</blockquote>
<p>My assumption (also in the US/Washington case above) is, that it
is (in most cases) countries which do cast decisions about time
zone rules.</p>
<p>Therefore, both Vietnam and Thailand seem to be free to change
time zone rules at any time soon.</p>
<p>Assuming two databases, one with "Vietnamese data" on an office
server in Hanoi, one with "Thai data" on an office server in
Bangkok, both databases would currently use "Asia/Bangkok" as an
identifier.</p>
<p>So in case the Thai government decides to change time zone rules
for Thailand (and Vietnam would not follow), if I am not wrong,
this would most probably require tzdb to introduce an "Asia/Hanoi"
identifier to accommodate for this new situation.</p>
<p>However, people maintaining the server with "Vietnamese data"
might then need to convert that data from using "Asia/Bangkok" to
"Asia/Hanoi" (my example may sound a little simple or arbitrary,
but I also want to understand if you share the idea that this may
be a point).</p>
<p>So given that example I'd argue that a Thai government could
indeed influence Vietnamese data. Coming back to the "Hanoi"
thread, I also think this might be a valid concern of Vietnamese
people while being "forced" to use an "Asia/Bangkok" identifier.</p>
<p>However, I also see your point about additional controversy. On
the other hand I think the existing technique of "Links" seems to
be a relatively simple way of resolving some of the points I made
above, and that the current "Asia/Phnom_Penh" has its value with
respect to this. <br>
</p>
<p>Best,<br>
Hans-Joerg</p>
<p>[1] <a class="moz-txt-link-freetext" href="https://data.iana.org/time-zones/theory.html#naming">https://data.iana.org/time-zones/theory.html#naming</a><br>
</p>
<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">www.twitter.com/audriga</a>
<a class="m_-745030944823917949m_-7737262847214818316moz-txt-link-abbreviated" href="http://www.audriga.com/" rel="noreferrer" target="_blank">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>
</body>
</html>