[tz] tzdb timezone names/identifiers and links (was: Add new timezone for Hanoi Capital, Vietnam)
happel at audriga.com
Mon Feb 18 20:09:53 UTC 2019
as a follow-up to the "Hanoi" thread, I've some questions regarding tzdb
policies. As it is a slightly separate / more general point, I'll single
that thread out from the initial "Hanoi" discussion.
In particular, I'd like to understand the background of the following
item (taken from https://data.iana.org/time-zones/theory.html#naming):
>There should typically be at least one name for each ISO 3166-1
>assigned two-letter code for an inhabited country or territory.
I initially thought this would be the reason for the "Links" of
"Asia/Phnom_Penh" and "Asia/Vientiane" to "Asia/Bangkok".
However, latest discussion in the "Hanoi" thread rather attributed these
two aliases to backwards compatibility after prior data was moved to the
I'd assume the quoted "ISO 3166-1"-based policy could make sense for two
a) Congruence of ids and decision-making bodies (i.e.,
In contrast to data stored using "Asia/Bangkok", systems/data using the
"Asia/Phnom_Penh" name/link/alias/id would not need to
change/re-configure in case the government of Cambodia decides to
deviate from "Asia/Bangkok" at some time
Even if tzdb names might not be intended as "names", they do surface
from time to time, as with configuring time zones on a machine , or
by applications just passing through tzdb names. I can somehow
understand that this is not fully satisfactory in the Vietnam/Hanoi case
right now (see below). While it is neither the intention nor the concern
of tzdb to deal with this, one can argue that in practice, there is
still clearly a practical impact of tzdb names/ids.
So any information on the rationale for the above-quoted rule is
Also, I see there are recommendations for implementers regarding
localization (e.g., reference to Unicode CLDR), but I could not find
recommendations concerning the usage of tzdb names/ids/links/aliases -
which, in my understanding, will be the String persisted by most
applications in the end?
If so, setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb
identifier would, to some degree, effectively tie that data to Thai
legislation. In case Vietnam would deviate from "Asia/Bangkok" in the
future (by either Thai or Vietnamese decision), legacy data might need
to be change to an "Asia/Hanoi" identifier. I'd be interested in
pointers if this aspect was ever discussed here or is considered
relevant at all.
Thanks and best,
ps.: as for the Vietnam case, note that the "displayName()" property in
Java shows "Indochina" for most zones under discussion 
Also Unicode CLDR translations look tricky in this case
points out the two options of
|sudo cp /usr/share/zoneinfo/Asia/Bangkok /etc/localtime|
..yielding the following dialogue:
Please select a country whose clocks agree with yours.
1) Afghanistan 18) Israel 35) Palestine
15) Indonesia 32) Nepal 49) Vietnam
16) Iran 33) Oman 50) Yemen
17) Iraq 34) Pakistan
Please select one of the following time zone regions.
1) Indochina (most areas)
2) Vietnam (south)
...which looks better, but is also not ideal from a user point-of-view...
 Java TimeZone.getDisplayName() output for EN/DE/FR locale (Oracle
Asia/Bangkok / Indochina Time
Asia/Bangkok / Indochina Zeit
Asia/Bangkok / Heure d'Indochine
Asia/Ho_Chi_Minh / Indochina Time
Asia/Ho_Chi_Minh / Indochina Zeit
Asia/Ho_Chi_Minh / Heure d'Indochine
Asia/Phnom_Penh / Indochina Time
Asia/Phnom_Penh / Indochina Zeit
Asia/Phnom_Penh / Heure d'Indochine
Asia/Saigon / Indochina Time
Asia/Saigon / Indochina Zeit
Asia/Saigon / Heure d'Indochine
Asia/Vientiane / Indochina Time
Asia/Vientiane / Indochina Zeit
Asia/Vientiane / Heure d'Indochine
VST / Indochina Time
VST / Indochina Zeit
VST / Heure d'Indochine
Durlacher Allee 47
76131 Karlsruhe, Germany
Tel: +49 (0) 721 17029 316
Fax: +49 (0) 721 17029 3179
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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2460 bytes
Desc: not available
More information about the tz