November 2018 - tz - lists.iana.org

Re: [tz] Was there a 1971-12-31 23:59:60?
by Levine, Judah Dr. (Fed) Nov. 11, 2018

Nov. 11, 2018

Hello, The current integer leap second system did not exist before 1972. There were a number of fractional-second adjustments and there were also frequency adjustments starting in the 1950s, when the length of the cesium second was defined. The final time adjustment at the start of 1972 was intended to incorporate the integral of the previous frequency steps, since the frequency of UTC was set equal to the SI second at that time. It is quite challenging to compute time intervals in the pre-1972 era. Different timing laboratories had slightly different values for this final time step. The goal was to bring all of the real-time realizations of UTC to the same time. Judah Levine On: 09 November 2018 22:29, "Steve Allen" <sla(a)ucolick.org<mailto:sla@ucolick.org>> wrote: On Fri 2018-11-09T22:04:35-0700 Paul Gilmartin via tz hath writ: > Subject: [tz] Was there a 1971-12-31 23:59:60? No. There was a step of 0.107758 seconds in UTC(BIH) at 1972-01-01. This was the final sub-second step in coordinated broadcast time signals. for the step that was applied to UTC(USNO) see Time Service Announcement series 14 number 8 (1971-10-08) at https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.ucolick.… -- Steve Allen <sla(a)ucolick.org<mailto:sla@ucolick.org>> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 &nb

2 1

Julian calendar
by Arthur David Olson Nov. 10, 2018

Nov. 10, 2018

Alas, while the current tz package can get the day-skipping part of the Julian-to-Gregorian calendar transition right, it gets pre-transition weekdays worng. (Getting them right would require special casing for big offsets from standard time in localtime.c) @dashdashado Script started on Sat, Nov 10, 2018 6:47:15 PM $ cat fake Zone America/Somewhere -268:56:02 - LMT 1752 Sep 3 -4:56:02 - LMT $ ./zic fake $ ./zdump -v America/Somewhere America/Somewhere -9223372036854775808 = NULL America/Somewhere -9223372036854689408 = NULL America/Somewhere Thu Sep 14 04:56:01 1752 UT = Sat Sep 2 23:59:59 1752 LMT isdst=0 gmtoff=-968162 America/Somewhere Thu Sep 14 04:56:02 1752 UT = Thu Sep 14 00:00:00 1752 LMT isdst=0 gmtoff=-17762 America/Somewhere 9223372036854689407 = NULL America/Somewhere 9223372036854775807 = NULL $ exit exit Script done on Sat, Nov 10, 2018 6:47:36 PM

1 0

Was there a 1971-12-31 23:59:60?
by Paul Gilmartin Nov. 10, 2018

Nov. 10, 2018

Hello, Judah Levine, I get unexpected results on Linux with TZ=right/Universal. I downloaded https://data.iana.org/time-zones/releases/tzdata2018g.tar.gz to try to find an explanation. There, I find, in: leap-seconds.list ... # # Updated through IERS Bulletin C56 # File expires on: 28 June 2019 # #@ 3770668800 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 2303683200 12 # 1 Jan 1973 2335219200 13 # 1 Jan 1974 2366755200 14 # 1 Jan 1975 ... I tend to believe this, but in: leapseconds ... # There were no leap seconds before 1972, because the official mechanism # accounting for the discrepancy between atomic time and the earth's rotation # did not exist. # The correction (+ or -) is made at the given time, so lines # will typically look like: # Leap YEAR MON DAY 23:59:60 + R/S # or # Leap YEAR MON DAY 23:59:59 - R/S # If the leap second is Rolling (R) the given time is local time (unused here). Leap 1972 Jun 30 23:59:60 + S Leap 1972 Dec 31 23:59:60 + S Leap 1973 Dec 31 23:59:60 + S Leap 1974 Dec 31 23:59:60 + S ... Well, it's consistent with itself. 1971-12-31 23:59:60 is *before* 1972. But "leap-seconds.list" shows one more leap second that "leapseconds". I'm confused. Thanks, gil

3 2

Re: [tz] zdump bug?
by Paul Eggert Nov. 8, 2018

Nov. 8, 2018

On 10/28/18 9:23 PM, Paul Eggert wrote: > 'zdump New_York' is treated differently from 'zdump ./New_York'. It > might make sense for the code to try harder to treat only ".." > components differently. I installed the attached first patch to try to do that. The second attached patch silences a warning when running "make CFLAGS='$(GCC_DEBUG_FLAGS)' GCC_INSTRUMENT=" on my platform (I updated GCC recently).

3 5

Fwd:DST in Isral 1980 and 1984
by Astrodienst Team Nov. 7, 2018

Nov. 7, 2018

I received this document, which claims DST from 2 August 1980 - 13 Sept 1980 and 5 May 1984 - 25 August 1984. These two periods are not contained in the current TZ database, which has Rule Zion 1974 only - Jul 7 0:00 1:00 D Rule Zion 1974 only - Oct 13 0:00 0 S Rule Zion 1975 only - Apr 20 0:00 1:00 D Rule Zion 1975 only - Aug 31 0:00 0 S Rule Zion 1985 only - Apr 14 0:00 1:00 D Rule Zion 1985 only - Sep 15 0:00 0 S Rule Zion 1986 only - May 18 0:00 1:00 D Rule Zion 1986 only - Sep 7 0:00 0 S -------- Forwarded Message -------- Subject: Hello to astro system Date: Tue, 18 Sep 2018 03:18:57 +0300 From: Israel Tzaig <israheal(a)gmail.com> To: order(a)astro.ch <order(a)astro.ch> My name is Israel Sagi and I wanted to update you about daylight saving time in Israel. In 1980 there was a summer time from 3.8 to 13.9. This clock is not updated on your maps. Attached is a page from the Ministry of Interior for daylight saving time in Israel Thank you and hope you will use the information here. For a double check, I went to the archives of Yedioth Ahronoth (the most popular newspaper in Israel) in 1980 to make sure that there was a daylight saving time. I would be happy to send you a photo of the relevant articles (in Hebrew of course) נשלח מהאפליקציה 'דואר <https://go.microsoft.com/fwlink/?LinkId=550986>' עבור Windows 10

3 4

Epic fail for DST fallback in hospital health records
by Paul Eggert Nov. 6, 2018

Nov. 6, 2018

Sydney Lupkin reports in today's Kaiser Health News that Epic Systems, a leading system used for hospital health records, cannot handle DST fallbacks such as Sunday's fallback in the US. Lupkin writes: 'Carol Hawthorne-Johnson, an ICU nurse in California, said her hospital doesn’t shut down the Epic system during the fall time change. But she’s come to expect that the vitals she enters into the system from 1 a.m. to 2 a.m. will be deleted when the clock falls back to 1 a.m. One hour’s worth of electronic record-keeping “is gone,” she said.' Apparently competing systems have similar problems. Lupkin writes that many hospitals plan for Cerner (another major system) to be down after a DST fallback as well. Dr. Steven Stack, past president of the American Medical Association, said these DST glitches are "unacceptable", considering that Apple and Google seem to have dealt with seasonal time changes long ago. Although Lupkin didn't say so, credit should be given to the design for the Unix operating system that is the basis for these successes of Apple and Google, as Unix standardized on UTC in the early 1970s; apparently Epic and Cerner (both founded 1979) did not get the message. The moral of this story seems to be: arrange for your medical emergencies to occur some time other than early Sunday in the US. Source: Lupkin S. Like Clockwork: How Daylight Saving Time Stumps Hospital Record Keeping. Kaiser Health News. 2018-11-03. https://khn.org/news/like-clockwork-how-daylight-saving-time-stumps-hospita…

9 17

tzdata2018g.tar.gz failing to install in Java 8
by Carter, Tom Nov. 6, 2018

Nov. 6, 2018

Iana team: I am getting the following when trying to install tzdata2018g.tar.gz using the latest tzupdater.jar (2.2.0) for Java 8. Failed: java.lang.Exception: Failed while parsing file '/tmp/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 '/tmp/tz.tmp_5/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) ... 5 more Please advise when will this be fixed? Thanks, Tom L Carter Principal Architect: CS/BW, American Airlines Work#: (817) 963-7640 Cell: (972) 849-1416 Coordinates: 4N-5A-53@HDQ2 Meeting Room<https://americanairlines.webex.com/join/Tom.Carter> NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient(s). If you are not an intended recipient, please do not read, distribute, or take action in reliance upon this message. If you have received this in error, please notify me immediately by return email and promptly delete this message and its attachments from your computer.

7 10

[tz-announce] 2018g release of tz code and data available
by Joel da Rosa Nov. 5, 2018

Nov. 5, 2018

Hello! Fail on parser asia TZ (Japan Rule) persist: Using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as source for tzdata bundle. Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) My environment: Linux Ubuntu 16.04 java version "1.8.0_191" Java(TM) SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) -- Atenciosamente, Joel da Rosa

2 1

Re: [tz] [tz-announce] 2018f release of tz code and data available
by Paul Eggert Nov. 2, 2018

Nov. 2, 2018

On 10/18/18 8:14 AM, Christos Zoulas wrote: > My folks are reporting that java does not like it: > > ERROR: Failed: java.lang.Exception: Failed while parsing file > '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - SepSat>=8 25:00 0 S' > ERROR: java.lang.Exception: Failed while parsing file > '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' > Thanks for the heads-up; please try the attached patch. Is there some way your folks can try the development version on GitHub every now and then? That "25:00" has been in the development version since last month and was explicitly called out when the patch was circulated on the mailing list <https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd have been nice to catch the glitch before 2018f came out.

14 31

Re: [tz] Time zone confusion in Morocco
by Hicham Boushaba Nov. 2, 2018

Nov. 2, 2018

We Moroccans didn't know about the change also before Friday, our government didn't take the time to neither study nor discuss the matter with us. And the real issue, is that Android devices (maybe iOS devices, I'm not sure) update the tzdb only via a system upgrade/patch, and we know that Android OEMs rarely update their devices, so Moroccans will stay impacted for a long time, and non-tech people don't have the necessary skills to change the timezone manually.

9 12