- tz - lists.iana.org

Re: [tz] question regarding Europe/Brussels in 1914
by Stijn “Adhemar” Vandamme Aug. 28, 2019

Aug. 28, 2019

A reliable source for the history of the timezone offset in Brussels is the Royal Observatory of Belgium. Dutch: <https://www.astro.oma.be/GENERAL/INFO/nli001a.html> French: <https://www.astro.oma.be/GENERAL/INFO/fri001a.html> The text at the beginning translates: > *The time in Belgium* > > Until 1 May 1892 the local (mean) time was used, usually the one of a > large town nearby. > > The law of 28 April 1892 (in effect from 1 May 1892) determined the legal > time in Belgium to be GMT, later UT, now standardized to coordinated > universal time (UTC). The table indicates which correction is required > for the period following the indicated date. The text before the bottom table translates: > In the period 1914-1918 the following arrangement was in force *in > occupied territory*. In the other areas only UTC was used (correction > +0h). The exact moment of the hour change depended on the advance or > withdrawal of the occupation army. The bottom table mentions 8 November 1914 as the start of the imposed use of the +1h offset in occupied territory (including Brussels), without specifying the exact time of that start. The start of summer time in 1916 is mentioned as 30 April 1916 23h UTC which is 1 May 1916 0h (UTC+1) becoming 1h (UTC+2) local time. — Adhemar

2 1

Europe/Brussels on 1892-05-01
by Michael H Deckers Aug. 28, 2019

Aug. 28, 2019

The exposition in the web page [https://www.bestor.be/wiki/index.php/Voyager_dans_le_temps._L%E2%80%99intro…] gives several contemporary sources from which one can conclude that the switch in Europe/Brussels on 1892-05-01 was from 00:17:30 to 00:00:00, and not from 12:00:00 to 11:42:30 as is currently contained in tzdb. It is true that mean time at the Royal Observatory was determined to be UT + 17 min + 29 s at the time, and that the observatory delivered Brussels time every morning at 06:00, but this does not mean that Brussels time was UT + 17 min + 29 s because the observatory had recently moved to Uccle (see [Ernest Pasquier: "L’unification des heures", page 306] as referenced in the web page above). The text in tzdb LMT before 1892 was 0:17:30, according to the official journal of Belgium: Moniteur Belge, Samedi 30 Avril 1892, N.121. is probably incorrect as regards the "according to". The text of the 1892 law is reprinted in [Laurent Delatte: "C'était dans Ciel et Terre il y a cent ans". Ciel et Terre vol 108 p 113..116. 1992.], online at [http://articles.adsabs.harvard.edu/cgi-bin/article_queryform?bibcode=1992C%…] on page 115, and it does not contain any offsets from UT. And it hardly could contain offsets because every larger town in Belgium had its own railway time, and civil time outside the stations often differed, as described by the articles by Ernest Pasquier referenced in the web page. Anyway, the actual time step taken was 17 min + 30 s, and time jumped from 00:17:30 to 00:00:00. This is described in the circular issued by the administration of railways and quoted in [Gazette de Charleroi of 1892-04-30, "Réglez vos pendules" page 1..2], and linked to in the BEstor web page. Michael Deckers.

2 1

Norfolk Island, Daylight Saving Time (DST) 6/10/19-05/04/20 [SEC=UNCLASSIFIED]
by Kyle Czech Aug. 28, 2019

Aug. 28, 2019

Please be advised that there will be a time zone change for Norfolk Island as of October 6, 2019. The Ordinance for the time zone change was passed in December last year https://www.legislation.gov.au/Details/F2018L01702 and will come into effect October 6, 2019. Please note the below in regards to change of time observed: daylight saving period means: (a) a period starting at 2 am on the first Sunday in October in each year and ending at 2 am on the first Sunday in the following April; or (b) if the Minister declares a different period under section 4A of this Ordinance-that period. daylight saving time means the time prescribed by section 7 of this Ordinance. standard time means the time prescribed by section 6 of this Ordinance. Further information is available here: https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-a… If you have any questions please let me know. Thank you, Kyle Kyle Czech [http://portals/entr/business-services/communications-and-media/publishing-a…, Local Government and Assets Norfolk Island and Mainland Territories Branch, Territories Division Department of Infrastructure, Transport, Cities and Regional Development t 0011 6723 23315 w www.infrastructure.gov.au<http://www.infrastructure.gov.au/> --------------------------------------------------------------------- Disclaimer This message has been issued by the Department of Infrastructure, Regional Development and Cities. The information transmitted is for the use of the intended recipient only and may contain confidential and/or legally privileged material. Any review, re-transmission, disclosure, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may result in severe penalties. If you have received this e-mail in error, please notify the Department on (02) 6274-7111 and delete all copies of this transmission together with any attachments. ---------------------------------------------------------------------

5 10

Re: [tz] tz Digest, Vol 95, Issue 8
by Kıvanç Yazan Aug. 28, 2019

Aug. 28, 2019

Hi! Here's some "resmi gazete" links for those years. http://www.resmigazete.gov.tr/arsiv/14539.pdf (page 24) 1973-06-03 01:00 -> 02:00 1973-11-04 02:00 -> 01:00 http://www.resmigazete.gov.tr/arsiv/14829.pdf (page 1) 1974-03-31 02:00 -> 03:00 1974-11-03 02:00 -> 01:00 http://www.resmigazete.gov.tr/arsiv/15161.pdf (page 1) 1975-03-22 02:00 -> 03:00 1975-11-02 02:00 -> 01:00 http://www.resmigazete.gov.tr/arsiv/15535_1.pdf (page 1) 1976-03-21 02:00 -> 03:00 1976-10-31 02:00 -> 01:00 http://www.resmigazete.gov.tr/arsiv/15778.pdf (page 5) 1977-04-03 02:00 -> 03:00 1977-10-16 02:00 -> 01:00 1978-04-02 02:00 -> 03:00 (not applied, see below) 1978-10-15 02:00 -> 01:00 (not applied, see below) 1979-04-01 02:00 -> 03:00 (not applied, see below) 1979-10-14 02:00 -> 01:00 (not applied, see below) http://www.resmigazete.gov.tr/arsiv/16245.pdf (page 17) This cancels the previous decision, and repeats it only for 1978. 1978-04-02 02:00 -> 03:00 1978-10-15 02:00 -> 01:00 (not applied due to standard TZ change below) http://www.resmigazete.gov.tr/arsiv/16331.pdf (page 3) This decision changes the default longitude for Turkish time zone from 30 degrees East to 45 degrees East. This means a standard TZ change, from +2 to +3. This is published & applied on 1978-06-29. At that time, Turkey was already on summer time (already on 45E). Hence, this new law just meant an "continuous summer time". Note that this was reversed in a few years. http://www.resmigazete.gov.tr/arsiv/18119_1.pdf (page 1) 1983-07-31 02:00 -> 03:00 (note that this jumps TZ to +4) 1983-10-02 02:00 -> 01:00 (back to +3) http://www.resmigazete.gov.tr/arsiv/18561.pdf (page 1 and 34) At this time, Turkey is still on +3 with no spring-forward on early 1984. This decision is published on 10/31/1984. Page 1 declares the decision of reverting the "default longitude change". So the standard time should go back to +3 (30E). And page 34 explains when that will happen: 1984-11-01 02:00 -> 01:00 You can think of this as "end of continuous summer time, change of standard time zone". http://www.resmigazete.gov.tr/arsiv/18713.pdf (page 1) 1985-04-20 01:00 -> 02:00 1985-09-28 02:00 -> 01:00 >From 1986 on, you can see my previous comments here: https://github.com/eggert/tz/blob/master/europe#L3671 Thanks, Kivanc Yazan

5 7

TZData file error
by Leonardo Menezes Aug. 26, 2019

Aug. 26, 2019

Hello, I am trying to update the time but is being displayed an error in the file (attachment). The file used was tzdata2019b Could you help me please? Thank you, *Leonardo Menezes* (13) 98211-5615

4 3

oral history contribution to the time zone history of Cambodia
by Alois Treindl Aug. 26, 2019

Aug. 26, 2019

TZ has this information in file backzone # From Paul Eggert (2014-10-11): # See Asia/Ho_Chi_Minh for the source for most of this data. Also, guess # (1) Cambodia reverted to UT +07 on 1945-09-02, when Vietnam did, and # (2) they also reverted to +07 on 1953-11-09, the date of independence. # These guesses are probably wrong but they're better than guessing no # transitions there. Zone Asia/Phnom_Penh 6:59:40 - LMT 1906 Jul 1 7:06:30 - PLMT 1911 May 1 7:00 - +07 1942 Dec 31 23:00 8:00 - +08 1945 Mar 14 23:00 9:00 - +09 1945 Sep 2 7:00 - +07 1947 Apr 1 8:00 - +08 1953 Nov 9 7:00 - +07 A good friend of mine born in 1951 in Phnom Pen is the adoptive daughter of late Cambodian ruler Prince Sihanouk. Being very interested in astrology, this friend of course much engaged in knowing the correct time zone for her birth. The information above would set it at 8h east of GMT for 1947 - 1953. My friend writes (and I have bolded the essential phrase): According to my father xxxx, during the French protectorate, Cambodia’s legal time was that of Hanoi. [..] My [adoptive] father Sihanouk confirmed the above in 2011 when I drafted my essay on King Sihanouk. I needed to ask him many questions, including details regarding our time zone, especially 5-6 August 1951. [...] King Sihanouk said that, during the Japanese occupation, starting with what historians refer to as “le coup de force du 9 mars 1945”, Cambodia, like the entire French Indochina, used Tokyo time zone. After Japan surrendered, 2 September 1945, Cambodia fell under French rule again and adopted Hanoi time zone again. *However, on 7 January 1946, Sihanouk and Tioulong managed to obtain a status of “internal autonomy” from the government of Charles de Gaulle. Although many fields remained under the administration of the French (customs, taxes, justice, defence, foreign affairs, etc.), the Cambodian administration was responsible for religious matters and traditional celebrations, which included our calendar and time. The time zone was GMT + 7 and _no_ DST was applied.* After Sihanouk and Tioulong achieved full independence, on 9 November 1953, GMT + 7 was maintained. -- end quote ket In view of this, I would tend to eliminate the line 8:00 - +08 1953 Nov 9 Of course, it is here like in many other cases the question what TZ wants to represent: offical time maintained by the colonial administration, or 'time on the ground' used by the local population for their own records, like a royal birth event. I do not expect action by Paul Eggert, as this is only backzone data.Still. I consider it worthwile to be recorded in the TZ mailing ist history.

3 4

Question regarding zone Asia/Seoul DST rules 1948-1951
by Alois Treindl Aug. 26, 2019

Aug. 26, 2019

For South Korea, TZ has rules covering the years 1948 - 1988, and the text comments confirm that they were applied in 1948. Rule ROK 1948 only - Jun 1 0:00 1:00 D Rule ROK 1948 only - Sep 12 24:00 0 S Rule ROK 1949 only - Apr 3 0:00 1:00 D Rule ROK 1949 1951 - Sep Sat>=7 24:00 0 S Rule ROK 1950 only - Apr 1 0:00 1:00 D Rule ROK 1951 only - May 6 0:00 1:00 D Rule ROK 1955 only - May 5 0:00 1:00 D Rule ROK 1955 only - Sep 8 24:00 0 S Rule ROK 1956 only - May 20 0:00 1:00 D Rule ROK 1956 only - Sep 29 24:00 0 S Rule ROK 1957 1960 - May Sun>=1 0:00 1:00 D Rule ROK 1957 1960 - Sep Sat>=17 24:00 0 S Rule ROK 1987 1988 - May Sun>=8 2:00 1:00 D Rule ROK 1987 1988 - Oct Sun>=8 3:00 0 S But the zone data apply only rules from 1954 onwards while those for 1948-51 are ignored. Why is this so? This may be an error made in 2014, when the ROK rules for 1948-1959 were added, but it was forgotten to enter ROK into the 1954 line. Zone Asia/Seoul 8:27:52 - LMT 1908 Apr 1 8:30 - KST 1912 Jan 1 9:00 - JST 1945 Sep 8 9:00 - KST 1954 Mar 21 8:30 ROK K%sT 1961 Aug 10 9:00 ROK K%sT

2 1

error in zone America/Kentucky/Louisville 1946
by Alois Treindl Aug. 26, 2019

Aug. 26, 2019

I have to report an error in zone America/Kentucky/Louisville zdump gives zdump -V -c 1945,1950 America/Kentucky/Louisville America/Kentucky/Louisville Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 17:59:59 1945 CWT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 18:00:00 1945 CPT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Sun Sep 30 06:59:59 1945 UT = Sun Sep 30 01:59:59 1945 CPT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Sun Sep 30 07:00:00 1945 UT = Sun Sep 30 01:00:00 1945 CST isdst=0 gmtoff=-21600 America/Kentucky/Louisville Tue Jan 1 05:59:59 1946 UT = Mon Dec 31 23:59:59 1945 CST isdst=0 gmtoff=-21600 America/Kentucky/Louisville Tue Jan 1 06:00:00 1946 UT = Tue Jan 1 01:00:00 1946 CDT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Sun Jun 2 06:59:59 1946 UT = Sun Jun 2 01:59:59 1946 CDT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Sun Jun 2 07:00:00 1946 UT = Sun Jun 2 01:00:00 1946 CST isdst=0 gmtoff=-21600 America/Kentucky/Louisville Sun Apr 27 07:59:59 1947 UT = Sun Apr 27 01:59:59 1947 CST isdst=0 gmtoff=-21600 America/Kentucky/Louisville Sun Apr 27 08:00:00 1947 UT = Sun Apr 27 03:00:00 1947 CDT isdst=1 gmtoff=-18000 with a strange transition CST to CDT on 1 January 1946. I have searched Louisville newspaper archives and find no report of such a clock change around New Year 1946. I find however the begin of CDT for 28 April 1946, and the switch back to CST on 2 June 1946. Shanks also has the transition on 28 April 1946. The cause I thnk is the strange formulation of Louisville rules # This also includes Clark, Floyd, and Harrison counties in Indiana. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Louisville 1921 only - May 1 2:00 1:00 D Rule Louisville 1921 only - Sep 1 2:00 0 S Rule Louisville 1941 1961 - Apr lastSun 2:00 1:00 D Rule Louisville 1941 only - Sep lastSun 2:00 0 S Rule Louisville 1946 only - Jun 2 2:00 0 S Rule Louisville 1950 1955 - Sep lastSun 2:00 0 S Rule Louisville 1956 1960 - Oct lastSun 2:00 0 S # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone America/Kentucky/Louisville -5:43:02 - LMT 1883 Nov 18 12:16:58 -6:00 US C%sT 1921 -6:00 Louisville C%sT 1942 -6:00 US C%sT 1946 -6:00 Louisville C%sT 1961 Jul 23 2:00 -5:00 - EST 1968 -5:00 US E%sT 1974 Jan 6 2:00 -6:00 1:00 CDT 1974 Oct 27 2:00 -5:00 US E%sT I attach a newspaper article describing the swith on 28 April.

3 3

Fiji DST 2019/2020
by Raymond Kumar Aug. 26, 2019

Aug. 26, 2019

Hi Paul There is a DST time change in Fiji island from November 10th 2019 The attached order states: Members of the public are advised to move their clocks one hour ahead at 2am on Sunday November 10th. The daylight saving period will end at 3am on Sunday January 12, 2020. Can a new tzdata be generated for Fiji Island. RuleFiji2014max-NovSun>=12:001:00- RuleFiji2015max-JanSun>=133:000- Thanks Raymond Kumar Head of Billing & Products +6797015315 ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.

3 3

Re: [tz] [Tzdist-bis] [calsify] tzdist and IANA
by Daniel Migault Aug. 23, 2019

Aug. 23, 2019

adding the tz mailing in the discussion Yours, Daniel On Thu, Jul 18, 2019 at 5:41 AM Martin Burnicki < martin.burnicki(a)burnicki.net> wrote: > Eliot Lear wrote: > > > >> On 18 Jul 2019, at 10:29, Martin Burnicki <martin.burnicki(a)burnicki.net> > wrote: > >> > >> Hi all, > >> > >> Eliot Lear wrote: > >>> Hi everyone, > >>> > >>> While the IANA does a great job at servicing our assigned number needs > >>> and delivering the TZ database to developers, they is not set up, nor > do > >>> they have *any* experience, to handle the load that end clients could > >>> place on them. Moreover, they are in no position to support millions > of > >>> people if something goes wrong. And make no mistake: something will go > >>> wrong. I would be okay with a limited tzdist service for those who are > >>> going to be distributing the data themselves, but the order of > receivers > >>> should be on 100s not millions. > >> > >> Wouldn't it be nice to have an infrastructure similar to what the NTP > >> pool provides for time synchronization? > > > > > > I guess I would want to see commitment from those who provide TZ service > to their customers today to go to such a new service before investing a lot > of money. Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the > others want to use it? I also realize that ICANN is well positioned to > fund this sort of thing, but it is not clear to me that it is right for > them to do so. There has to be a real need, and those who really need it > perhaps should foot the bill. > > > > I'm working at Meinberg > https://www.meinbergglobal.com/ > > and we are manufacturing NTP/PTP servers, beside related time > synchronization stuff. > > In the past, whenever governments as of Egypt, Morocco, etc. decided to > start or end DST just a couple of days before this really happens we get > support requests from industries, telecommunication companies, etc., > asking if our time servers could fix the problem to update the TZ data > quickly enough. > > We always have to tell them they need to wait until a new TZ DB has been > released, and then hope that their OS maintainers (Microsoft, Apple, > Linux distros, etc.) pick up the new TZ DB version and provide a > software/firmware update just to provide the latest changes quickly. > > Providing these updates also requires quite some effort for the > maintainers, and it would be much easier for them if this kind of > information could be updated automatically, which should also be faster > than with manual intervention required. > > TZ data must not be requested from a server as often as the current > time, so I think that even if the data size is larger than an NTP packet > the overall load compared to NTP will not be much higher than for a > server that provides NTP services, and if I remember correctly then data > only needs to be transferred if changes have become available. > > So I think this type of service and its advantages just need to be made > more public, to let the OS maintainers learn that they have less work > with rolling out and deploying software updates if they just use TZDIST. > > I'd expect that a TZDIST pool could be operated by volunteers, just like > the NTP pool. > > Martin > > _______________________________________________ > Tzdist-bis mailing list > Tzdist-bis(a)ietf.org > https://www.ietf.org/mailman/listinfo/tzdist-bis >

14 20

Java 1.8 update with new DST changes in Brazil?
by Jared Brunson Aug. 22, 2019

Aug. 22, 2019

Will there be an update to Java 1.8 with the new Brazil DST changes? Reference: https://www.timeanddate.com/news/time/brazil-scraps-dst.html The following page hasn't been updated yet. https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html This is very important for our software product that relies heavily on Java. Thanks, Jared Brunson PSE Symantec DLP

2 1

question regarding Europe/Brussels in 1914
by Alois Treindl Aug. 22, 2019

Aug. 22, 2019

TZ zone Europe/Brussels has a transition from WET to CET on 8 November 1914: 0:00 - WET 1914 Nov 8 1:00 - CET 1916 May 1 0:00 What is the source for this information? Shanks, Henri le Corre "Regime horaires pour l'Europe et l'Afrique' and Gabriel "Trait de l'heute dans le monde' have all 4 August 1914, which was the begin of the German invasion. It seems unlikely that the whole country switched to German time at the begin of the invasion, and therefore I do not trust these three sources. Brussels was occupied by the Germans on 20 August 1914.

2 1

leap second theory
by scs＠eskimo.com Aug. 20, 2019

Aug. 20, 2019

I was trying to point someone to a reference describing how the "right" zones can be used to enable a system to handle leap seconds more correctly, but I discovered that this isn't really documented anywhere. (There's Steve Allen's page at https://www.ucolick.org/~sla/leapsecs/right+gps.html , of course, but that describes a distinct variant of the scheme.) Would it make sense to add something like the attached patch to theory.html?

8 15

file asia needs Link for Asia/Hanoi
by Alois Treindl Aug. 16, 2019

Aug. 16, 2019

I think file asia should have a line Link Asia/Bangkok Asia/Hanoi If this is absent, and file backzone is not compiled, no binary file for Hanoi gets created. This breaks all references to it. For all other zones in backzone, a Link line exists so that a binary file is always created.

2 2

Fwd: Turkey timezone 1940/41
by Alois Treindl Aug. 15, 2019

Aug. 15, 2019

The claim that Turkey had double daylight time in 1940/41 as was published in http://www.astrolojidergisi.com/yazsaati.htm has now been retracted. I had insisted on a double check, because the wording in official documents is often unclear and ambiguous. > Von: Barış İlhan <barisilhan(a)superonline.com> > Datum: 15. August 2019 um 12:30:13 MESZ > An: "'Alois Treindl'" <alois(a)astro.ch> > Betreff: Aw:⁨ Turkey timezone change October 1978⁩ > > Dear Alois, > > I got in touch with the researcher, she said she made a correction for 1941 for one day, after she searched the newspapers. She came to the conclution that a sentence was written wrong in the official legal gazette. > So the final list is this for 1941; > > 01.07.1940 saat 00.00 > > 06.10.1940 saat 00.00 > 1 hour > 01.12.1940 saat 00.00 > - > 21.09.1941 saat 00.00 > 1 hour > 01.04.1942 saat 00.00 > 08.10.1945 saat 00.00 > > 1 hour > > The Milliye gazete archive will not be helpful, because that newspaper was founded in 1950. > > Best, > Baris > > From: Alois Treindl [mailto:alois@astro.ch] > Sent: Thursday, August 15, 2019 12:15 PM > To: Barış İlhan <barisilhan(a)superonline.com> > Subject: Re: Turkey timezone change October 1978 > > > > On 14.08.19 23:30, Barış İlhan wrote: > It looks complicated but actually it is clear. > In 1941 the government first announced 1 hour, and the next day 1 hour more. At the second announcement it says first announcement is still valid, so it makes 2 hours. > > Best, > Baris > > > Sorry, but we need to see this reports in public newspapers, both at the beginning and at the end of the period in question > > Newspapers do say things like 'clock shifts backward one hour' at the end of daylight saving time. In that case, around 21 September 1941, the newspapers must have mentioned a clock shift by two hours. > > The paper archive http://gazetearsivi.milliyet.com.tr/ is accessible for free and is searchable. My problem is that I cannot read Turkish. > > We do not trust the wording of formal government announcements. They have been unclear at other occasions, for example in 1978.

1 0

Re: [tz] Norfolk Island, Daylight Saving Time (DST) 6/10/19-05/04/20 [SEC=UNCLASSIFIED]
by Paul Eggert Aug. 14, 2019

Aug. 14, 2019

Michael H Deckers wrote: > F2018L01702 is just the diff for the revised > version of Norfolk Island Standard Time Ordinance 2015 > at [https://www.legislation.gov.au/Details/F2019C00010/Download] > > They seem to invalidate the diff after it has been > applied by Legislation Act -- it is probably not idempotent. Thanks for the clarification. I installed the attached patch to the development version on GitHub to implement the change to tzdb, and something like this should appear in the next release. This change assumes that the fall-back transition on 2020-04-05 will occur at 02:00 standard time (03:00 local time), not at 02:00 local time, as this is common practice in Australia.

1 0

Re: [tz] Norfolk Island, Daylight Saving Time (DST) 6/10/19-05/04/20 [SEC=UNCLASSIFIED]
by Stijn “Adhemar” Vandamme Aug. 14, 2019

Aug. 14, 2019

Paul Eggert wrote: > I just visited <https://www.legislation.gov.au/Details/F2018L01702> and found > that it says that F2018L01702 is "No longer in force". The web page details > say that F2018L01702 was registered 2018-12-07, tabled 2019-02-12, and > repealed 2019-08-02 by Division 1 of Part 3 of Chapter 3 of the Legislation > Act 2003, which contains a bunch of legal mumbo jumbo that I don't understand. F2018L01702 ("Norfolk Island Standard Time Amendment (Daylight Saving) Ordinance 2018") amends F2019C00010 ("Norfolk Island Standard Time Ordinance 2015"); and <https://www.legislation.gov.au/Details/F2019C00010> says that F2019C00010 is still in force, with the amendments in question included in the latest version. I guess C2019C00084 ("Legislation Act 2003"), Chapter 3, Part 3, Division 1 contains the legislative logic along the lines of "Once the amendment (diff) has been applied in the original text, the modifying text can fall out of force automatically." -- Adhemar

1 0

Call for evidence on UK adoption of EU summer time abolition
by Joseph Myers Aug. 5, 2019

Aug. 5, 2019

The House of Lords EU Internal Market Sub-Committee has published a call for written evidence on UK adoption of EU abolition of seasonal time changes. https://www.parliament.uk/business/committees/committees-a-z/lords-select/e… https://www.parliament.uk/documents/lords-committees/eu-internal-market-sub… -- Joseph S. Myers jsm(a)polyomino.org.uk

2 1

Fwd: Bulletin C number 58
by Chris Woodbury July 29, 2019

July 29, 2019

On Sat Jul 27 14:21:34 UTC 2019, Paul Eggert <eggert at cs.ucla.edu> wrote: >Thanks, I installed that into the development version on GitHub. > >I see that the updated file has a space at the end of the '#@ 3802291200' line >that encodes the expiration (2020-06-28 00:00:00 UTC). I assume this was >inadvertent. It doesn't break tzcode (which ignores that line), but the format >of the line is not documented anywhere that I can see. I dropped Judah Levine a >line about this. > Back in the dark ages, when I first started writing C code, it was said that the ultimate documentations was the code. In the NTP daemon, there is a subroutine leapsec_load() in which is the following: while (get_line(func, farg, linebuf, sizeof(linebuf))) { cp = linebuf; if (*cp == '#') { cp++; if (*cp == '@') { cp = skipws(cp+1); pt->head.expire = strtouv64(cp, &ep, 10); ... strtouv64() is an NTP native subroutine (found in libntp/vint64ops.c) which reads numeric data in a specified base (in this case 10). It skips "whitespace" (so the call to skipws() is superfluous), and then converts the digits, one at a time, to numeric in that base. It quits conversion when whatever it's pointing at isn't a digit in the selected base and returns the number and "ep", a pointer to where it stopped parsing. This allows for comments and/or additional data. So, a space instead of a line terminator or say, a comment such as "\t# 28 Jun 2020", after the expiration NTP timestamp is an acceptable field termination. Anyone who cares to can reference the "standard" implementation of the NTP code found at: <http://www.ntp.org/downloads.html> The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server...

6 6

CRLF terminated leap-seconds.list fix
by Chris Woodbury July 29, 2019

July 29, 2019

NIST has yet again generated a leap-seconds.list file with CRLF line terminations. If the file is transferred in FTP binary mode and used, it breaks leapseconds.awk. Using int( ) around the last column variable eliminates this problem. Therefore, I propose the attached patch.

3 3

Re: [tz] Fwd: Bulletin C number 58
by Pierpaolo Bernardi July 27, 2019

July 27, 2019

Il giorno 27 luglio 2019, alle ore 05:17, David Patte <dpatte(a)relativedata.com> ha scritto: >For my products I use an algorithm (Meeus; Astronomical Algorithms 1998) to 'predict' deltaT into the future. Does anyone have a good source for a more recent algorithm that takes into account IERS values since 1998? This page may be a start: https://eclipse.gsfc.nasa.gov/SEhelp/deltatpoly2004.html

3 2

Fwd: Bulletin C number 58
by Kurt Roeckx July 27, 2019

July 27, 2019

8 11

NIST leap-seconds.list is finally here
by Chris Woodbury July 26, 2019

July 26, 2019

There is now an updated for July 2019 "leap-seconds.list" file at NIST. Both the Boulder and Greenbelt FTP sites have the new file. Attached find a patch (as follows). $ git diff leap-seconds.list diff --git a/leap-seconds.list b/leap-seconds.list index fd3d192..a1bc5a7 100644 --- a/leap-seconds.list +++ b/leap-seconds.list @@ -204,10 +204,10 @@ # current -- the update time stamp, the data and the name of the file # will not change. # -# Updated through IERS Bulletin C57 -# File expires on: 28 December 2019 +# Updated through IERS Bulletin C58 +# File expires on: 28 June 2020 # -#@ 3786480000 +#@ 3802291200 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 @@ -252,4 +252,4 @@ # the hash line is also ignored in the # computation. # -#h 83c68138 d3650221 07dbbbcd 11fcc859 ced1106a +#h f28827d2 f263b6c3 ec0f19eb a3e0dbf0 97f3fa30

1 0

Re: [tz] [Tzdist-bis] tzdist and IANA
by Paul Eggert July 25, 2019

July 25, 2019

Here are some other thoughts about any potential IANA effort in this area: * As others have mentioned, the effort should address authentication of the timezone data. It would be helpful to have a real authentication expert in on this, since we want something simple and scalable and workable downstream (see below). * Each tzdb release comes with a version number like "2019b", development commits have version numbers like "2019b-11-gd8c6bf2". Downstream publishers often make minor changes to the data, and some append a suffix to the version number to indicate this. The mechanism for publishing this number is specified only loosely in Internet RFC 7808 section 3.10, and presumably the IANA effort would do something more specific. Downstream modifications will complicate data authentication. * Each tzdb release has auxiliary metadata files zone1970.tab and iso3166.tab that contain vague geographical information associated with each tzdb entry. (In some cases this vagueness is intentional, to avoid running into political disputes.) These files are not covered by TZDIST but some POSIX-style clients use them. How should metadata like this be addressed? * Each tzdb release has an auxiliary data file 'leapseconds' that is widely used by clients running NTP and related software. TZDIST has a "leapseconds" action that conveys the information in a different format, and we would need to make sure that this all hooks up correctly. * It'd be helpful to support not only TZDIST, but also a reasonably simple protocol, presumably based on HTTPS transfer of the data since HTTPS is widely supported. This could be used by platforms that don't support TZDIST, or that need auxiliary metadata that is outside the scope of TZDIST. For example, many NTP hosts need a 'leapseconds' file but don't support TZDIST or grok its leap seconds data format.

2 1

[PROPOSED] Mention IANA Updater, tzdbgen, ZIUpdater
by Paul Eggert July 25, 2019

July 25, 2019

* tz-link.html: Add linkjs for IANA Updater, tzdbgen, and ZIUpdater. Mention ‘make reaguard_tarballs’ too. --- tz-link.html | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/tz-link.html b/tz-link.html index 234c04e..a037972 100644 --- a/tz-link.html +++ b/tz-link.html @@ -268,7 +268,8 @@ For further information about updates, please see <a href="https://tools.ietf.org/html/rfc6557">Procedures for Maintaining the Time Zone Database</a> (Internet <abbr title="Request For Comments">RFC</abbr> 6557). More detail can be -found in <a href="theory.html">Theory and pragmatics of the tz code and data</a>. +found in <a href="theory.html">Theory and pragmatics of the +<code><abbr>tz</abbr></code> code and data</a>. <a href="https://a0.github.io/a0-tzmigration/">A0 TimeZone Migration</a> displays changes between recent <code><abbr>tzdb</abbr></code> versions. </p> @@ -361,6 +362,11 @@ title="JavaScript Object Notation">JSON</abbr></a> format.</li> <section> <h2 id="compilers">Other <code><abbr>tz</abbr></code> compilers</h2> +<p>Although some of these do not fully support +<code><abbr>tz</abbr></code> data, in recent <code><abbr>tzdb</abbr></code> +distributions you can generally work around compatibility problems by +running the command <code>make rearguard_tarballs</code> and compiling +from the resulting tarballs instead.</p> <ul> <li><a href="https://sourceforge.net/projects/vzic/">Vzic</a> is a <a href="https://en.wikipedia.org/wiki/C_%28programming_language%29">C</a> @@ -408,7 +414,7 @@ into an <abbr>ICU</abbr>-specific format. <abbr>BSD</abbr>-style license.</li> <li>The <a href="https://github.com/lau/tzdata">Tzdata</a> package for the <a href="https://elixir-lang.org">Elixir</a> language downloads -and compiles tz source and exposes <abbr +and compiles <code><abbr>tz</abbr></code> source and exposes <abbr title="Application Program Interface">API</abbr>s for use. It is freely available under the <abbr>MIT</abbr> license.</li> <li>Java-based compilers and libraries include: @@ -429,6 +435,11 @@ 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://bell-sw.com/pages/iana-updater/">IANA Updater</a>, +<a href="https://github.com/akashche/tzdbgen">tzdbgen</a>, and <a +href="https://www.azul.com/products/open-source-tools/ziupdater-time-zone-tool/">ZIUpdater</a> +are other alternatives to TZUpdater. IANA Updater's license is unclear; +the others are licensed under the <abbr>GPL</abbr>.</li> <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, @@ -1040,7 +1051,8 @@ is called "<abbr>GMT</abbr>".</li> <section> <h2 id="see-also">See also</h2> <ul> -<li><a href="theory.html">Theory and pragmatics of the tz code and data</a></li> +<li><a href="theory.html">Theory and pragmatics of the +<code><abbr>tz</abbr></code> code and data</a></li> <li><a href="tz-art.html">Time and the Arts</a></li> </ul> </section> -- 2.17.1

1 0