March 2019 - tz - lists.iana.org

Pennsylvania State Rep seeking to end DST
by Matthew Donadio March 6, 2019

March 6, 2019

Not sure if this will go anywhere, but a Pennsylvania State Rep is seeking a co-sponsor to end DST in the state: https://www.legis.state.pa.us/cfdocs/legis/CSM/showMemoPublic.cfm?chamber=H… >From a quick read of the memo, it looks like he has done his homework on what it would actually take from beginning to end to get this done. --Matthew Donadio (matt(a)mxd120.com)

1 0

[IANA #1136519] America / Sao_Paulo in the Time Zone Database
by Amanda Baber via RT March 5, 2019

March 5, 2019

Hi, We've been asked to submit this message to the mailing list on a requester's behalf: === Contact Name: ricardotiellet Contact Email: rhiccarddo(a)hotmail.com Please, this case needs to be fixed: Wrong> America / Sao_Paulo Right> America / Brasilia If there is a need for disambiguation, just add a suffix: _DF = Federal District or Federal Capital so use: America / Brasilia_DF if there is any compatibility problem with graphical accentuation, Use Brasilia without an acute accent on the first i (í) https://en.wikipedia.org/wiki/Bras%C3%ADlia https://en.wikipedia.org/wiki/Brasilia Please contact me if you need. Thanks a lot. === He indicated to us that he may not check the mailing list for replies. Best regards, Amanda Baber Lead IANA Services Specialist

4 4

tzdb timezone names/identifiers and links (was: Add new timezone for Hanoi Capital, Vietnam)
by Hans-Joerg Happel March 1, 2019

March 1, 2019

Dear all, 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 <https://en.wikipedia.org/wiki/ISO_3166-1> officially >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 backzone file. I'd assume the quoted "ISO 3166-1"-based policy could make sense for two reasons: a) Congruence of ids and decision-making bodies (i.e., countries/governments): 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 b) Politically: 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 [1], 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 appreciated. 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, Hans-Joerg ps.: as for the Vietnam case, note that the "displayName()" property in Java shows "Indochina" for most zones under discussion [2] Also Unicode CLDR translations look tricky in this case (http://st.unicode.org/cldr-apps/survey?_=en&x=r_zones) [1] E.g. https://askubuntu.com/questions/323131/setting-timezone-from-terminal/323163 points out the two options of |sudo cp /usr/share/zoneinfo/Asia/Bangkok /etc/localtime| (explicit!) or |tzselect | ..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 #? 49 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... [2] Java TimeZone.getDisplayName() output for EN/DE/FR locale (Oracle JDK 1.8.0_191): 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 -- 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

22 105