- tz - lists.iana.org

Korean DST 1940s-1960s and other aspects of Korean Standard Time and other aspects of tz database
by Phake Nick Nov. 17, 2018

Nov. 17, 2018

1. According to official announcement from Korean government, the DST end date in South Korea should be 1955-09-08 without specifying time http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1956-09-29 without specifying time http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1957-09-21 24 o'clock http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1958-09-20 24 o'clock http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1959-09-19 24 o'clock http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1960-09-17 24 o'clock http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… Contradicting the current tz database record that shows their end date as 00:00 of the next days. The effect should be same in almost all cases, but to be literally reflect the rule in tz database probably an update might be desirable. [Information via Suikawiki] 2. Regarding history of Korean time, there is a Korean wiki site https://namu.wiki/w/대한민국%20표준시 that say when Korea was using GMT+8:30 as standard time, the international aviation/marine/meteorological industry in the country refused to follow and continues to use GMT+9:00 for interoperability. Did the phenomenon actually occured back then and is there any further details about it? 3. Back in 2014 when Korean time history in tz database was discussed, the reliability of The International Atlas by Shanks was also being discussed. I checked the book on amazon.com and there's a review saying that the International Atlas say they've make up some information to fill holes in their research and use them to advance copyright claims to temporarily force tzinfo offline. I am not sure what happened back then in the year of 2011 when the comment was posted, but if that's true then tz database should probably be more actively removing anything related to Shanks from the database as those information are not fact and thus subject to copyright claims and thus cannot be released as public domain according to the license of tz database? Not to mention the accuracy of those data.

2 1

[PATCH] * tz-link.html: Mention Time4A.
by Paul Eggert Nov. 17, 2018

Nov. 17, 2018

--- tz-link.html | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tz-link.html b/tz-link.html index 956af52..3a3c96b 100644 --- a/tz-link.html +++ b/tz-link.html @@ -372,10 +372,12 @@ and time <abbr>API</abbr></a> contains a class Java 8 <code>java.time</code>, which its users should migrate to once they can assume Java 8 or later. It is available under the <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License</a>.</li> -<li><a href="https://github.com/MenoData/Time4J/">Time4J – -Advanced date, time and interval library for Java</a> contains a class -<code>net.time4j.tool.TimezoneRepositoryCompiler</code> that compiles -<code><abbr>tz</abbr></code> source into a binary format. Time4J is +<li><a href="https://github.com/MenoData/Time4A">Time4A: Advanced date and +time library for Android</a> and +<a href="https://github.com/MenoData/Time4J/">Time4J: Advanced date, +time and interval library for Java</a> compile +<code><abbr>tz</abbr></code> source into a binary format. +Time4A is available under the Apache License and Time4J is available under the <a href="https://www.gnu.org/copyleft/lesser.html"><abbr>GNU</abbr> Lesser General Public License (<abbr title="Lesser General Public -- 2.17.1

1 0

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

Nov. 13, 2018

Applying a time stamp to an event in an end-user application with nanosecond accuracy or precision is very difficult because of the problems of measuring the transmission delay from the source to the end-user and the latency in the end-user application. These problems are generally at least as large as knowing the accuracy of the source with respect to UTC or UTC(lab). Although all of these things can be characterized statistically, that is not of much use for a single event which cannot benefit from averaging. Note that post-processing may not be of much help in determining the jitter in the processing latency. The data in Circular T are what they are because of the administrative and processing delays in computing UTC. The UTC(lab) is now and will probably always be an extrapolation, which is limited by the flicker and random-walk processes of the laboratory time scale. Although the publication of UTCr has decreased the processing delay, it is a provisional scale and is not of much use at the nanosecond level. Judah Levine Time and Frequency Division NIST Boulder On: 10 November 2018 22:24, "Steve Allen" <sla(a)ucolick.org<mailto:sla@ucolick.org>> wrote: On Sat 2018-11-10T19:54:11+0000 Levine, Judah Dr. (Fed) hath writ: > It is quite challenging to compute time intervals in the pre-1972 > era. That depends on the required precision. It is still challenging to compute intervals to nanoseconds. That requires grabbing all the relevant issues of BIPM Circular T and similar publications of the particular source of time if they are not members of the BIPM atomic clock club. One hundred years ago it was challenging to compute intervals to centiseconds, and that was the reason for the creation of BIH. When Anna Stoyko retired from the BIH in 1965 she published one final analysis of all the BIH data from 1922 to 1963. She produced plots showing how the time services of observatories had improved. Those plots are reproduced here https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.ucolick.… In order to gather these data the BIH had been monitoring the arrival times of radio broadcast time signals since 1922. The volumes of Bulletin Horaire have the numbers that show many ways that various national observatories and time services messed up (and messed around with) the time they were providing. The data in the issues of Bulletin Horaire are the nightmare of the tzdb because taken to the absurd limit they would require that tzdb encode the millisecond-scale differences between the legal civil times of every nation whose transmitters were monitored by BIH. > 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. Well, much closer than before, but if they were the same then the subsequent issues of BIH Bulletin Horaire and now BIPM Circular T would be much terser publications. -- 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 Lng -122.06015 Santa Cruz, CA 95064 https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.ucolick.o… Hgt +250 m

1 0

CalConnect Public Time Zone Workshop on February 5 in Zurich, Switzerland
by Dave.Thewlis＠calconnect.org Nov. 12, 2018

Nov. 12, 2018

Please note that this is NOT an IETF event. CalConnect <http://www.calconnect.org/> will host a Public Time Zone Workshop on Tuesday afternoon, February 5th, during its conference at Google in Zürich, Switzerland <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019>. The Time Zone Workshop will be Tuesday February 5th from 13:30 to 17:30 at the Google facility <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019#location>. This workshop will be focussed on the potential impact of EU Summer Time changes and how the changes might be mitigated; please see our news release <http://www.calconnect.org/news/2018/10/30/calconnect-calls-eu-reconsider-ti…>. The workshop is open to the public but you must register in advance. There is no fee to attend the workshop. Attendees are invited to stay for a Welcome Reception following the workshop. More information will be provided as planning continues. The workshop is intended for anyone who needs to plan and prepare for this and other TZ/DST changes, in particular representatives from governments, industries affected by tz changes (travel, financial, health, device manufacturers, etc.), organizations deploying tz data, and organizations maintaining and updating tz data. Please register for this event at https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets… <https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets…>. We invite anyone who is interested in or concerned by the pending changes and how time zone change information might better be distributed and implemented to attend. Dave Thewli -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org <http://www.calconnect.org/> | Dave.Thewlis(a)calconnect.org <mailto:Dave.Thewlis@calconnect.org>

2 1

Re: [tz] Epic fail for DST fallback in hospital health records
by Hal Murray Nov. 12, 2018

Nov. 12, 2018

eggert(a)cs.ucla.edu said: > Gawande A. Why doctors hate their computers. The New Yorker. 2018-11-12. > https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-comput… Thanks for the heads up. In case anybody doesn't recognize the name, the A is Atul. He's a surgeon, and a very good writer. His first two books are collections of his New Yorker articles. My reading on this whole mess is that the medical community doesn't take testing software seriously. It may be as simple as senior executives with budget problems aren't willing to pay for testing because they don't understand that you have to do lots of it if you expect your systems to work reliably. For background, I highly recommend Gawande's Checklist Manifesto. He led a WHO project to get airplane style checklists used in hospital operating rooms. Not much about software, lots about checklists and the pilot/cockpit culture. For info about medical software, I recommend Robert Wachter's Digital Doctor. It's the study of a screwup at UCSF hospital that almost killed a kid. Lots of info about software and UIs and testing. https://www.goodreads.com/book/show/23131174-the-digital-doctor -- These are my opinions. I hate spam.

6 9

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