- tz - lists.iana.org

Bad 32 bit data in 2018f
by Daniel Fischer Oct. 24, 2018

Oct. 24, 2018

Hi, I'm getting bad data in the 32 bit section of some of the compiled files in zoneinfo-leaps. The affected time zones are zones that only transition before 1901, usually from LMT to some UTC offset: Indian/Christmas Indian/Cocos Atlantic/South_Georgia Pacific/Port_Moresby Pacific/Chuuk Pacific/Yap Pacific/Wallis Pacific/Funafuti Pacific/Palau Pacific/Ponape Pacific/Wake Pacific/Pohnpei Pacific/Truk Pacific/Tarawa The files in zoneinfo-leaps contain no transitions, and only the offset used before the transition. This causes applications that only read the 32 bit section to use LMT for these zones. The 64 bit section, and both sections in the zoneinfo version of these files, contain >=2 transitions and offsets (e.g. one real transition and one in 2038). For example, zdump with a break added after /old file/ in localtime.c: $ ./zdump $PWD/TZ/usr/share/zoneinfo*/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo/Atlantic/South_Georgia Tue Oct 23 12:31:33 2018 -02 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Tue Oct 23 12:04:58 2018 LMT $ ./zdump -V $PWD/TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:00 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:01 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 [..] .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sun Jan 1 00:00:27 2017 UT = Sat Dec 31 21:33:52 2016 LMT isdst=0 gmtoff=-8768 I found that before commit 83c119f4d ("Remove Big Bang hack"), the one offset present in the leaps version was the correct one. The structural difference is older; it just didn't affect my application because the offset was the one currently in use. The cause appears to be this sequence of events starting at zic.c /Work around QTBUG-53071/: 1) y2038_boundary-1 transition is added (== INT32_MAX) 2) leap seconds are added to all times, pushing the 2038 transition above INT32_MAX 3) affected zones again only have transition times outside the 32 bit range => timecnt32 is 0 4) because timecnt32 is 0, timei32 is also 0, and the INT32_MIN transition isn't output either 5) because of omittype[defaulttype] = false, the oldest offset is always output regardless of the above The workaround could probably be moved to after the leap seconds are added, especially if it's supposed to apply to the 32 bit leaps files. This will also fix this bug, because the code that determines the 32 bit limits assumes there's at least one time after 1901, and the workaround provides one. (This is why the non-leaps version is correct.) I'm unfortunately not familiar enough with the tz database to suggest a complete fix. Danny -- Daniel Fischer ORACLE Deutschland B.V. & Co. KG, Riesstr. 25, 80992 München - HRA MUC 95603 Komplementaer: ORACLE DE Verw.B.V., Hertogswetering 163/167, 3543 AS Utrecht Geschaeftsfuehrer: Alexander van der Ven, Jan Schultheiss, Val Maher NL

1 0

South Korea timezone history
by Phake Nick Oct. 24, 2018

Oct. 24, 2018

On Korean Wikipedia article for DST https://ko.wikipedia.org/wiki/%EC%9D%BC%EA%B4%91_%EC%A0%88%EC%95%BD_%EC%8B%… , I saw the following lines (with machine translation): >In Korea, the standard meridian of the time was 127° 30' in Tokyo during the period of 1955 to 1960, so it was 30 minutes earlier than it is today. This information is different from what's currently described in tz database and should be investigated. Also, given the example of DST transaction in Japan, it might also worth investigating what did the "00:00[start]-00:00[end]" in Korean DST transaction mean at the time.

1 1

[PROPOSED] * tz-link.html: Update Windows details and links
by Matt Johnson Oct. 23, 2018

Oct. 23, 2018

diff --git a/tz-link.html b/tz-link.html index b5870d3..8593ba6 100644 --- a/tz-link.html +++ b/tz-link.html @@ -524,11 +524,10 @@ clock (intclock)</a> is a clock that displays multiple time zones on under the <abbr>GPL</abbr>.</li> <li>Microsoft Windows 8.1 and later has <code><abbr>tz</abbr></code> data and <abbr>CLDR</abbr> -data (mentioned <a href="#CLDR">below</a>) used by the -<a href="https://en.wikipedia.org/wiki/Windows_Runtime">Windows Runtime</a> / -<a href="https://en.wikipedia.org/wiki/Universal_Windows_Platform">Universal Windows Platform</a> classes -<a href="https://docs.microsoft.com/uwp/api/Windows.Globalization.DateTimeFormatting…"><code>DateTimeFormatter</code></a> and -<a href="https://docs.microsoft.com/uwp/api/windows.globalization.calendar"><code>Calendar</code></a>. +data (mentioned <a href="#CLDR">below</a>) used by +<a href="https://en.wikipedia.org/wiki/Windows_Runtime">Windows Runtime</a> +classes such as <a +href="https://msdn.microsoft.com/en-us/library/windows/apps/windows.globalization…"><code>DateTimeFormatter</code></a>. <a id="System.TimeZoneInfo" href="https://blogs.msdn.microsoft.com/bclteam/2007/06/07/exploring-windows-time-…">Exploring Windows Time Zones with <code>System.TimeZoneInfo</code></a> describes

2 2

Re: [tz] [PROPOSED] Be consistent about WWII abbreviations in Hawaii
by Paul Eggert Oct. 23, 2018

Oct. 23, 2018

On 10/23/18 12:07 PM, Michael H Deckers wrote: > You might want to add HWT and HPT to the list in theory.html as well. Thanks, good catch. Also the NEWS file. I installed the attached.

2 2

DST time zone Amercia/Sao_Paulo
by Júnior Didoné Oct. 23, 2018

Oct. 23, 2018

Greetings, I would like to inform you that DST is *active* for America / Sao_Paulo and Brazil/East Time Zones, since yesterday. However, the *correct* date for activation is *November 4, 2018*, the Brazilian government changed it in February 2018. This is causing errors in Oracle Databases in Amazon Web Services. Please, correct as soon as possible. Thank you, Júnior Didoné

3 2

2018f tzdb released with bug
by Laurenti, Leandro Oct. 23, 2018

Oct. 23, 2018

A/C Mr. Paul Eggert Hi, After several years, the DST start time was changed in Brazil. Until the last year, it was set to start in the 3rd weekend of October. In this year, it will start on November 4th. So, we were instructing our customers to run the tzupdater tool , from oracle, that relies on the "tzdata-latest.tar.gz" file from IANA. However, when the customers are trying to update java, they are getting the following error: https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8212684?filter=allope… Failed: java.lang.Exception: Failed while parsing file 'C:\Users\ME928~1.SYR\AppData\Local\Temp\tz.tmp_5\asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file 'C:\Users\ME928~1.SYR\AppData\Local\Temp\tz.tmp_5\asia' on line 1655 'Rule Japan 1948 1951 - S Sat>=8 25:00 0 S' So it seems to be a problem with 2018f version of the tzdb file... It seems the 2018e version is working fine. Not sure if someone from Brazil or any other country already have contacted you... Since this is a very critical problem, we hope this to be fixed asap. Thank you in advance. Best Regards, Leandro Laurenti Support Engineer CA Technologies | Av. Dr. Chucri Zaidan, 1240 26º e 27º andares, Golden Tower | Sao Paulo, SP 04711-130 Office: +80353 | Leandro.Laurenti(a)ca.com <mailto:Leandro.Laurenti@ca.com>[CA]<http://www.ca.com/us/default.aspx>[Twitter]<http://twitter.com/CAInc>[Slideshare]<http://www.slideshare.net/cainc>[Facebook]<https://www.facebook.com/CATechnologies>[YouTube]<http://www.youtube.com/user/catechnologies>[LinkedIn]<http://www.linkedin.com/company/1372?goback=.cps_1244823420724_1>[Google+]<https://plus.google.com/+CATechnologies>[Google+]<http://www.ca.com/us/rss.aspx?intcmp=footernav>

2 6

[PROPOSED] * tz-link.html: Mention TimeZoneConverter and ICU for tz<->windows mappings
by Matt Johnson Oct. 23, 2018

Oct. 23, 2018

diff --git a/tz-link.html b/tz-link.html index b5870d3..f959f93 100644 --- a/tz-link.html +++ b/tz-link.html @@ -541,6 +541,8 @@ Tzid table</a> or <a href="https://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml"><abbr>XML</abbr> file</a> of the <abbr>CLDR</abbr> data maps proprietary zone IDs to <code><abbr>tz</abbr></code> names. +These mappings can be performed programmatically via the <a href="https://github.com/mj1856/TimeZoneConverter">TimeZoneConverter</a> .NET library, +or the ICU Java and C++ libraries mentioned <a href="#ICU">above</a>. <li><a href="https://www.oracle.com/java/index.html">Oracle Java</a> contains a copy of a subset of a recent

1 0

America/Sao_Paulo file.
by Vitor Vieira Andrade Oct. 23, 2018

Oct. 23, 2018

Hi Guis, I've downloaded the tzdata and compiled the Sao_Paulo rulefile. After run the zdump command, the output shows : The daylight saving time should change at Sun 4 Nov, how do i re-compile it on the correct day. Regards, ibm-brasil-100 VITOR VIEIRA ANDRADE IT Specialist - Unix/Linux. E-mail: vitorv(a)br.ibm.com IBM Rua Tutoia 1157 Sao Paulo, SP 04007-900 Brazil

2 1

[PROPOSED] Be consistent about WWII abbreviations in Hawaii
by Paul Eggert Oct. 23, 2018

Oct. 23, 2018

* northamerica (Pacific/Honolulu): Use abbreviations HWT and HPT for consistency with other US abbreviations during World War II. --- northamerica | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/northamerica b/northamerica index 88c0f6f..fb0103f 100644 --- a/northamerica +++ b/northamerica @@ -708,9 +708,7 @@ Zone America/Adak 12:13:22 - LMT 1867 Oct 19 12:44:35 Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00 -10:30 - HST 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 21 12:00 - -10:30 - HST 1942 Feb 9 2:00 - -10:30 1:00 HDT 1945 Sep 30 2:00 - -10:30 - HST 1947 Jun 8 2:00 + -10:30 US H%sT 1947 Jun 8 2:00 -10:00 - HST # Now we turn to US areas that have diverged from the consensus since 1970. -- 2.17.2

1 0

2018e Morocco
by Kiley Walbom Oct. 20, 2018

Oct. 20, 2018

Paul, We are in the process of revamping our extraction programs and noticed an anomaly in Morocco The current rules look like this: v2018e Africa lines 893, 916, and 917 Rule Morocco 2013 max - Oct lastSun 3:00 0 - Rule Morocco 2036 only - Oct 19 3:00 0 - Rule Morocco 2037 only - Oct 4 3:00 0 - Our new program "thinks" there is an overlap in the end dates. After looking at the rules we believe the end date for line 893 should look like this: Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - If the European Commission proposal becomes official, your proposal will fix this issue. Thank you for your time. Kiley

2 1