[tz] tzdb timezone names/identifiers and links (was: Add new timezone for Hanoi Capital, Vietnam)

Wed Feb 20 17:21:18 UTC 2019

I did a short check on the ISO 3166-1-rule compliance of the current
release.

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.

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).

Example:

[zone1970.tab]
CZ,SK	+5005+01426	Europe/Prague

[europe]
# Slovakia
Link Europe/Prague Europe/Bratislava

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]

(Side note: the "Link" syntax does not seem to be explained yet in
https://data.iana.org/time-zones/tz-how-to.html)

Further observations:

The "zone.tab" file actually uses the "Link" aliases, while
"zone1970.tab" does not:

[zone.tab]
CZ	+5005+01426	Europe/Prague
SK	+4809+01707	Europe/Bratislava

vs. 

[zone1970.tab]
CZ,SK	+5005+01426	Europe/Prague

...so one will yield different results depending on which .tab file an
application uses.

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?):

VN	+1045+10640	Asia/Ho_Chi_Minh

(not sure if the latter was already covered in the Hanoi thread)

Best,
Hans-Joerg

[1] tzselect output on Ubuntu after choosing the respective country:

The following information has been given:
    Slovenia
Therefore TZ='Europe/Belgrade' will be used.

The following information has been given:
    Oman
Therefore TZ='Asia/Dubai' will be used.

The following information has been given:
    Cambodia
    Indochina (most areas)
Therefore TZ='Asia/Bangkok' will be used.

On 20.02.19 17:40, Hans-Joerg Happel wrote:
>
>
> 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.
>
> Standpoints:
>
> a) (Exclusionist) Timezone ids should be kept at a minimum level
> required to model tz rules appropriately
> b) (Inclusionist) There should be at least one timezone id for each
> ISO 3166-1 TLC
> ...and as the "Hanoi" case would not be covered by (b) the even
> extended inclusionist approach would rather be something like:
> 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
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> Thanks and best,
> Hans-Joerg
>
> [1]
> 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.
> On 20.02.19 13:37, Stephen Colebourne wrote:
>> 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 <eggert at cs.ucla.edu> wrote:
>>> On 2/19/19 2:31 PM, Tim Parenti wrote:
>>>> 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.
>>> Sounds good to me; proposed patch attached.
>>>
>
> -- 
> audriga GmbH
> Durlacher Allee 47
> 76131 Karlsruhe, Germany
> Tel: +49 (0) 721 17029 316
> Fax: +49 (0) 721 17029 3179
>
> www.twitter.com/audriga <http://www.twitter.com/audriga>
> www.audriga.com <http://www.audriga.com/>
>
> Handelsregister: Amtsgericht Mannheim - HRB 713034
> Sitz der Gesellschaft: Karlsruhe
> Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel
> USt-ID: DE 279724142
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190220/6b20c955/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2460 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20190220/6b20c955/pEpkey-0001.asc>