- tz - lists.iana.org

FW: [Bug time/23976] trunk/timezone/zdump.c:811: missing call to va_end ?
by David Binderman Dec. 14, 2018

Dec. 14, 2018

Hello there, Forwarded bug report ________________________________________ https://sourceware.org/bugzilla/show_bug.cgi?id=23976 --- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- This code is imported from external sources and not modified locally in glibc. Please report your concern to tz(a)iana.org, not here. -- You are receiving this mail because: You reported the bug.

3 3

Error in the Time Zone Database
by serhii.demediuk＠cyberpolice.gov.ua Dec. 7, 2018

Dec. 7, 2018

Cyberpolice Department of National Police of Ukraine presents its compliments and wish to inform your organization regarding the following recent change. Information posted at https://www.iana.org/time-zones suggests that the latest release of the time zone database (version from 10/26/2018), states that Crimea (Ukrainian Autonomous Republic of Crimea) belongs to the time zone "MSK" and is marked with the country code "RU". This information was found in the archive, which contains the full description of the data, codes and applications, and is located at https://data.iana.org/time-zones/releases/tzdb-2018g.tar.lz. Information about the code of Crimea was found in the file "zone.tab" within the specified archive. We consider it necessary to draw your attention to the fact that Crimea is a temporarily occupied part of Ukraine. This fact is generally acknowledged by the international community, which is confirmed by a number of international legal document, including UN General Assembly resolution. Thus, by referring Crimea with the country code "RU", your organization actually accepts and supports the aggressive actions of the Russian Federation who’s armed forces annexed this part of Ukraine. Such recognition may be considered as a criminal offense by the Ukrainian criminal law and we will be obliged to start formal criminal proceedings as it is stipulated in article 110 of the Criminal Code of Ukraine "Infringement of territorial integrity of Ukraine". As you probably know, the aggression of the Russian Federation against Ukraine is still ongoing and any ambiguous decision by countries or international organizations is used by the authorities of the aggressor country to justify their actions. We would like to add that there are Ukrainian citizens still living in Crimea and adhere to the legislation of Ukraine. For their beliefs, such citizens are persecuted by the authorities of Russian Federation. International support for Ukrainian citizens in their aspiration to renew the territorial integrity of Ukraine is extremely important, and in this case your organization can play a positive role. We understand the apolitical status of your organization and respect the existing rules for determining of the actual time zone, but considering the international legal status of Crimea, which is part of Ukraine, we propose to correct this mistake and to change the current version of the time zone database in order to determine that the country code of Crimea is «UA». Best regards, Head of the Cyberpolice Department of the National Police of Ukraine Serhii Demediuk tel.: +380443743738 e-mail: serhii.demediuk(a)cyberpolice.gov.ua Ukraine, Kyiv

3 3

posix for asia/tehran is wrong
by Mark Nov. 30, 2018

Nov. 30, 2018

I've been adding DST time zone to espurna (https://github.com/xoseperez/espurna/pull/1295) All dst entries but asia/tehran, use Mm.n.d format to specify dst dates. The Tehran use 'Jn': "Asia/Tehran","<+0330>-3:30<+0430>,J80/0,J264/0" When I implement this 'J' format, I came out a day short. From https://en.wikipedia.org/wiki/Iran_Standard_Time: The Iranian DST starts on March 22 and ends on September 22 each year with the exception of leapyears in which the DST starts and ends one day prior. Year DST Start Date and Time DST End Date and Time *2014* Sat, Mar 22, 0:00 AM Mon, Sep 22, 0:00 AM *2015* Sun, Mar 22, 0:00 AM Tue, Sep 22, 0:00 AM *2016* Mon, Mar 21, 0:00 AM Wed, Sep 21, 0:00 AM *2017* Wed, Mar 22, 0:00 AM Fri, Sep 22, 0:00 AM *2018* Thu, Mar 22, 0:00 AM Sat, Sep 22, 0:00 AM This mean Tehran should be "Asia/Tehran","<+0330>-3:30<+0430>,80/0,264/0". The 'n' format, which counts 29 Feb, and starts count from 0, so would not come up a day short on non-leap years.

4 5

[PROPOSED] * northamerica: Herbert Copeland stops time.
by Paul Eggert Nov. 30, 2018

Nov. 30, 2018

--- northamerica | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/northamerica b/northamerica index e590a30..17597e2 100644 --- a/northamerica +++ b/northamerica @@ -792,6 +792,22 @@ Zone America/Boise -7:44:49 - LMT 1883 Nov 18 12:15:11 # For a map of Indiana's time zone regions, see: # https://en.wikipedia.org/wiki/Time_in_Indiana # +# From Paul Eggert (2018-11-30): +# A brief but entertaining history of time in Indiana describes a 1949 debate +# in the Indiana House where city legislators (who favored "fast time") +# tussled with farm legislators (who didn't) over a bill to outlaw DST: +# "Lacking enough votes, the city faction tries to filibuster until time runs +# out on the session at midnight, but rural champion Rep. Herbert Copeland, +# R-Madison, leans over the gallery railing and forces the official clock +# back to 9 p.m., breaking it in the process. The clock sticks on 9 as the +# debate rages on into the night. The filibuster finally dies out and the +# bill passes, while outside the chamber, clocks read 3:30 a.m. In the end, +# it doesn't matter which side won. The law has no enforcement powers and +# is simply ignored by fast-time communities." +# How Indiana went from 'God's time' to split zones and daylight-saving. +# Indianapolis Star. 2018-11-27 14:58 -05. +# https://www.indystar.com/story/news/politics/2018/11/27/indianapolis-indian… +# # From Paul Eggert (2007-08-17): # Since 1970, most of Indiana has been like America/Indiana/Indianapolis, # with the following exceptions: -- 2.17.1

1 0

Timezone history for some Pacific Islands.
by Phake Nick Nov. 30, 2018

Nov. 30, 2018

>From a Japanese wiki site https://wiki.suikawiki.org/n/南洋群島の標準時 there are some time change history about Pacific Islands that are not included in the tz database. Mainly, the history of time used in those islands during, before and after Japanese administration, and also DST used in Guam during 1960s and 1970s. For "Southern Islands" (modern region of Mariana + Palau + Federation of Micronesia + Marshall Islands): * A 1906 Japanese magazine shown the Caroline Islands and Mariana Islands who was occupied by Germany at the time as GMT+10, together with the like of German New Guinea. However there is a marking saying it have not been implemented (yet). No further information after that were found. * Japan invaded those islands in 1914, and records shows that they were instructed to use JST at the time * 1915 January telecommunication record on the Jaluit Atoll shows they use the meridian of 170E as standard time (GMT+11:20), which is similar to the longitude of the atoll. * 1915 February record say the 170E standard time is to be used until February 9 noon, and after February 9 noon they are to use JST. * However these are time used within the Japanese Military at the time and probably does not reflect the time used by local resident at the time (that is if they keep their own time back then) * In January 1919 the occupying force issued a command that split the area into three different timezone with meridian of 135E, 150E, 165E (JST+0, +1, +2), and the command was to become effective from February 1 of the same year. Despite the target of the command is still only for the occupying force itself, further publication have described the time as the standard time for the occupied area and thus it can probably be seen as such. ** Area that use meridian of 135E: Palau and Yap civil administration area (Southern Islands Western Standard Time) ** Area that use meridian of 150E: Truk(Chuuk) and Saipan civil administration area (Southern Islands Central Standard Time) ** Area that use meridian of 165E: Ponape(Pohnpei) and Jaluit civil administration area. (Southern Islands Eastern Standard Time) ** In the next few years Japanese occupation of those islands have been formalized via League of Nation Mandate (South Pacific Mandate) and formal governance structure have been established, these district [become subprefectures] and timezone classification have been inherited as standard time of the area. ** Saipan subprefecture include Mariana islands (exclude Guam which was occupied by America at the time), Palau and Yap subprefecture rule the Western Caroline Islands with 137E longitude as border, Truk and Ponape subprefecture rule the Eastern Caroline Islands with 154E as border, Ponape subprefecture also rule part of Marshall Islands to the west of 164E starting from (1918?) and Jalnuit subprefecture rule the rest of the Marshall Islands. * And then in year 1937, an announcement was made to change the time in the area into 2 timezones: ** Area that use meridian of 135E: area administered by Palau, Yap and Saipan subprefecture (Southern Islands Western Standard Time) ** Area that use meridian of 150E: area administered by Truk(Chuuk), Ponape(Pohnpei) and Jaluit subprefecture (Southern Islands Eastern Standard Time) * Another announcement issued in 1941 say that on April 1 that year, standard time of the Southern Islands would be changed to use the meridian of 135E (GMT+9), and thus abolishing timezone different within the area. * Then Pacific theater of WWII started and Japan slowly lose control on the island. The webpage I linked above contain no information during this period of time. Guam Island was briefly annexed by Japan during this period of time [year 1941-1944], however there are no detailed information about what time it use during that period. It would probably be reasonable to assume Guam use GMT+9 during that period of time like the surrounding area. * After the end of WWII, in 1946 February, a document written by the (former?) Japanese military personnel describe there are 3 hours time different between Caroline islands time/Wake island time and the Chungking time, which would mean the time being used there at the time was GMT+10. * After that, the area become Trust Territories of the Pacific Islands under American administration from year 1947. The site listed some American/International books/maps/publications about time used in those area during this period of time but they doesn't seems to be reliable information so it would be the best if someone know where can more reliable information can be found. * The site also pointed out that currently tzdata say Pacific/Kwajalein switched from GMT+11 to GMT-12 in 1969 October without explanation, however an 1993 article from NYT say it synchorized its day with US mainland about 40 years ago and thus the switch should occur at around 1950s instead. * Also, the NYT article linked in that website say the jump from GMT-12 to GMT+12 in year 1993 skipped Saturday that day, however the comment in tz database from that year say it skipped Friday. That seems to be an inconsistency that should be investigated, and the comment should probably be annotated accordingly if the comment was not accurate ANd then additional note for Bonin Islands: While not part of the Southern Islands, in the period of time during 1952-1968, Bonin Islands were placed under American administration. It would probably be worth investigating whether they're following the Japanese time or the Mariana time or some other time standard at the time. And then for Guam: * Currently tz database say Guam stopped using local mean time at 1901 but a 1902 earthquake report on Guam seems to be using LMT in the report when compares to the time the earthquake recorded on the Philippines (the site note that it take times for earthquake wave to transmit and thus the time different between records in different place would not be identical to the time different) ** The site say Shanks used 1901 end date for LMT time for a number of places around the world, probably using them as placeholder. Maybe those 1901 end date should be nuked from tz database? * A Japanese magazine in 1906 say Guam's time is "1.5 hours earlier than Japan" and "use 145 degree E meridian" which are contradictory to each other as 145E meridian mean GMT+9:40 and that is not 1.5 hours earlier than Japan. * And then there are some different records about Guam used GMT+9:30 at the time but each of those documents seems to give different transition time for when they give up :30 time different and move to GMT+10. But it most likely occurred before 1927 as a map published by US Navy that year shows Guam as using GMT+10, which appears to be credible as Guam was under US Military administration at the time. * As mentioned above, Guam was invaded by Japan during year 1941-1944. It's unclear about did they shifted the clock to match the surrounding islands during this period of time. * Then in year 1959 there's a daylight saving time act passed for Guam. There is a table on the site that include list an link to time and order for implementation and cancellation of DST at Guam but the implementation time seems to be all over the place according to the list. The last time the DST was implemented in Guam according to the table seems to be 1977 although I am not sure about the completeness of the table. If so then maybe a new zone for CNI would need to be created as it's after 1970 and the DST should be applicable to Guam only?

3 3

Question about the UNTIL fields
by Marcos Passos Nov. 29, 2018

Nov. 29, 2018

Hello everyone, I'm working on a TZDB parser for a PHP project and reading the zic8.txt I came across with the following information: The month, day, and time of day have the same format as the IN, ON, and AT > fields of a rule However, I could not find any Zone line in the latest version of the TZDB containing relative dates, such as "lastSun" or "sun>=5", but only absolute dates. Is this a mistake in the documentation or are relative dates actually supported on those lines but have never been used? - Marcos

3 6

Stop
by The OneCloud Nov. 29, 2018

Nov. 29, 2018

Stop

2 1

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

Nov. 26, 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. 17, 2018

Nov. 17, 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

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. 10, 2018

Nov. 10, 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. 9, 2018

Nov. 9, 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