- tz - lists.iana.org

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