- tz - lists.iana.org

query regarding issue will updating open JDK timezone info with tzdata2018g
by Dhanusha, Pb (Nokia - IN/Bangalore) Nov. 27, 2018

Nov. 27, 2018

Hi, We are facing issues while updating open JDK timezone with tzdata2018g with the below error. #/usr/bin/java -jar /root/tzupdater.jar -l file:/root/tzdata2018g.tar.gz 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:212) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:226) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:780) 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 Could you please help us with this. Regards, Dhanusha

4 4

Help - Morocco timezone wrong since 28 Oct 2018
by Heidi Hendry Nov. 25, 2018

Nov. 25, 2018

Hi, Based on this version of the TZ values: http://twiki.org/cgi-bin/xtra/tzdate?tz=Africa/Casablanca the Africa/Casablanca timezone is wrong. Morocco abruptly changed the timezone (see this BBC article: https://www.bbc.com/news/world-africa-45995634 ) and Android phones and other UX distributions appear to be wrong every since. Africa/Casablanca is +1 GMT now, and there is NO daylight savings any more. Please, please could you fix this in TZ so that it distributes out for other updates? Regards Heidi Hendry

2 1

Correcting daylight-savings time for central Missouri prior to 1967
by Jane Eisenstein Nov. 24, 2018

Nov. 24, 2018

I was born and raised in central Missouri and know most of Missouri did not observe daylight-savings time prior to 1967. Areas close to Kansas City or St. Louis did observe daylight-savings time prior to 1967. I’ve also attached supporting scans of Missouri daylight-savings time information from the 1991 revision of Time Changes in the U.S.A. by Doris Chase Doane. The timezones database appears to assume all Missouri observed daylight savings whenever Chicago, Illinois did. I would like to correct this mistake, but am not clear how to go about doing so. Can the daylight-savings time be set at the state level, then overridden for particular communities? Best regards, Jane Eisenstein

9 25

Nauru Time history
by Phake Nick Nov. 19, 2018

Nov. 19, 2018

* Currently, the tz database say Nauru use LMT until 1921, and then switched to GMT+11:30 for the next two decades. * However, a number of timezone map published in America/Japan back then showed its timezone as GMT+11 per https://wiki.suikawiki.org/n/ナウルの標準時 * And it would also be nice if the 1921 transition date could be sourced. * The tz database currently show Nauru use GMT+9 within the time of 1942 Mar 15 and 1944 Aug 15, however the correspondence is not exact as Nauru was still under Japanese rule until year 1945. And I don't think it's likely for such switch to occur during WWII so it's probably an error. * Currently tz database shows the +11:30 -> +12 transition date as 1979 May, however the "Nauru Standard Time Act 1978 Time Change" http://ronlaw.gov.nr/nauru_lpms/files/gazettes/4b23a17d2030150404db7a5fa587… based on "Nauru Standard Time Act 1978 Time Change" http://www.paclii.org/nr/legis/num_act/nsta1978207/ defined that "Nauru Alternative Time" (GMT+12) should be in effect from 1979 Feb. Thus it appears that the current tz database transition time might be incorrect.

3 2

Hong Kong time 1941
by Phake Nick Nov. 18, 2018

Nov. 18, 2018

Today I went to check microfilm records stored at Hong Kong Public Library and found following situation that are inconsistent with tz database record. * Around April 1 1941, there're no news about DST on various newspapers that I checked. Time given for sunrise/sunset around the period are also continuous (as in they're minutes within each others on those days, indicating there are no change to time standard around 1941 April 1. * I have subsequently checked Hong Kong Observatory's site and the site now list the 1941 DST start date for Hong Kong as June 15. (url is same as the one in tz file but content is different from when the 2009 comment was made) I have not tried validating the info from those newspapers as I wasn't aware of the table's current content until I stopped using the library. * And then, on September 30 1941, according to Ta Kung Pao (Hong Kong edition), it was stated that fallback would occur on the next day (the 1st)'s "03:00 am (Hong Kong Time 04:00 am)" and the clock will fall back for a half hour. (03:00 probably refer to the time commonly used in mainland China at the time given the paper's background), after it was spring forward for an hour months ago. I cannot find out record of English newspaper from that day, but the sunrise/sunset time given by South China Morning Post for October 1st was indeed moved by half an hour compares to before. * After that, in December, the battle to capture Hong Kong started and the library doesn't seems to have any record stored about press during that period of time. Some media resumed publication soon after that within the same month, but there were not much information about time there. Later they started including a radio program guide when they restored radio service, explicitly mentioning it use Tokyo standard time, and later added a note saying it's half an hour ahead of the old Hong Kong standard time, and it also seems to indicate that Hong Kong was not using GMT+8 when it was captured by Japan. * Image of related sections on newspaper: 1941 September 30, Ta Kung Pao (Hing Kong) , "Winter Time starr tomorrow": https://i.imgur.com/6waY51Z.jpg (Chinese) 1941 September 29, South China Morning Post, Information on sunrise/sunset time and other things for September 30 and October 1: https://i.imgur.com/kCiUR78.jpg 1942 February 5, The Hong Kong News, Radio Program Guide: https://i.imgur.com/eVvDMzS.jpg

7 19

Higgins Time and TZ DB c.1886
by Brian Inglis Nov. 18, 2018

Nov. 18, 2018

Links to an interesting article and artifact referenced in comments on: https://www.jwz.org/blog/2018/08/higgins-time/ Arabian Flying Is Confusing article - Port Angeles Evening News, March 10, 1965, p. 4: https://newspaperarchive.com/port-angeles-evening-news-mar-10-1965-p-4/ Kendal & Dent's Time Chart of the World c.1886 - Evanion Catalogue - BL: https://www.bl.uk/catalogues/evanion/FullImage.aspx?EvanID=024-000002349&Im… -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.

2 2

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