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

[Hans-Joerg Happel]

On 19.02.19 20:00, Stephen Colebourne wrote:
> On Tue, 19 Feb 2019 at 16:35, Paul Eggert <eggert at cs.ucla.edu> wrote:
>> 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).
> This will create more problems, not less. Time zones are by nature the
> product of politics, so issues around countries/territories simply
> can't be avoided. The rules already link to ISO 3166-1 code, thus the
> key part of the problem is already sidestepped.
>
> Hanoi is an edge case, because if the current rules were applied as of
> 1970, Hanoi would have to be an active zone.
>
>>> setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb
>>> identifier would, to some degree, effectively tie that data to Thai
>>> legislation.
> Vietnamese systems looking to future dates should be set to
> Asia/Ho_Chi_Minh, shouldn't they?

I tend to agree with you on this. However, your rationale for this is
the result of a >50 mail discussion and not easily to grasp for any tzdb
consumer based on the way tzdb is build right now.

Second, what about the case of a Linux laptop located in Hanoi
configured to use "Asia/Ho_Chi_Minh". Some sort of calculation might
still go wrong then. Clearly a made up example, but isn't time zone math
also about unintended consequences?

Best,
Hans-Joerg

>
> Stephen



-- 
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/20190219/f06ca936/attachment.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/20190219/f06ca936/pEpkey.asc>