December 2019 - tz - lists.iana.org

Italy April 1944 discrepancy between comment and data
by Alois Treindl Oct. 5, 2021

Oct. 5, 2021

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

'Australia/Canberra' time zone?
by John Pye April 24, 2020

April 24, 2020

Hi there I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000. What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion? Here is what I believe to be an official source about the Canberra timezone (at least for the present day): https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-a… Cheers JP

8 19

Re: [tz] Leap Second Support Interval Field Request - RFC8536
by Paul Eggert Jan. 14, 2020

Jan. 14, 2020

On 12/4/19 1:04 PM, Michael Veth wrote: > The NIST leapsecond bulletin includes an expiration time which serves to > indicate the maximum validity interval for use of UTC time. In order to > safely use UTC timestamps, the user needs to be aware of this maximum > validity time or they could be unknowingly introducing timing errors. > > I was not able to find this field in the TZif (Feb 19) ICD. Would it be > possible to add a field to the TZdb that would represent this expiration > time? The TZif file format does provide for truncated files (see Internet RFC 8536 section 5.1), and one can generate files truncated to the current UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this: zic -r /@1593302427 -L leapseconds tzdata.zi However, it's awkward that one must count the number of seconds since 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the numeric timestamp (1593302427 in this case) to pass to zic. We could add support to zic to do this sort of thing in a more-natural way. A downside of the abovementioned approach is that it generates a TZif file that omits all DST and time zone transitions after the UTC expiration time. We could change the TZif format to represent UTC expiration time separately from the truncation time. One possibility would be to append a leap-second record with an "occur" value equal to the expiration time and a "corr" value equal to the previous record's "corr" value. Strictly speaking this would violate RFC 8536 section 3.2 "leap-second records" - though I doubt whether many clients would care - and so I suppose we'd need to increment the TZif format version number from 3 to 4. On the other hand, any files generated by this method would continue to be "incorrect" in that they'd continue to predict timestamps past the maximum leap second validity, so perhaps it wouldn't be worth going to all this work to generate "incorrect" files. I'll cc this to tz(a)iana.org and tzdist-bis(a)ietf.org to see whether anybody there cares to comment.

4 6

Hour 26? (was: Chaning time zone for Unix based tasks)
by Paul Gilmartin Jan. 7, 2020

Jan. 7, 2020

(cross-posting to tz and IBM-MAIN) Hi, TZData, On a Linux system, I see: 1043 $ uname -a Linux Bunsen5-PG 4.9.0-11-686-pae #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) i686 GNU/Linux 1044 $ cat /usr/share/zoneinfo/Asia/Tel_Aviv | tail -1 IST-2IDT,M3.4.4/26,M10.5.0 1045 $ ... This would seem to be Month 3, Week 4, Day 4, hour 26. 26? Is that supposed to be 02:00 the next day? But POSIX says: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#ta… ... The hour shall be between zero and 24, and the minutes (and seconds) -if present-between zero and 59. The result of using values outside of this range is unspecified. z/OS (which supports only POSIX format) seems to ignore that TZ (as allowed by "unspecified") and use UTC0: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r… (It doesn't specify.) Ouch! -- gil

3 4

Fake UK news
by Lester Caine Dec. 30, 2019

Dec. 30, 2019

Or rather another proposal for changes to time zones that did not happen - SDST https://www.bbc.co.uk/news/uk-50950961 -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk

1 0

Timekeeping in the news
by Arthur David Olson Dec. 27, 2019

Dec. 27, 2019

"Boeing Starliner Ends Up In Wrong Orbit After Clock Problem." https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html @dashdashado

7 9

[PATCH] * asia: Correct Hong Kong section name.
by Jimmy Yuen Ho Wong Dec. 19, 2019

Dec. 19, 2019

There are no records of Hong Kong being referred to as Xianggang, in the past or currently. The Pinyin romanization scheme of the Mandarin pronunciation of 香港 is not officially recognized or even mentioned in official documents. https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html https://www.elegislation.gov.hk/hk/cap5 --- asia | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/asia b/asia index cca004f..4f19d14 100644 --- a/asia +++ b/asia @@ -572,7 +572,7 @@ Zone Asia/Urumqi 5:50:20 - LMT 1928 6:00 - +06 -# Hong Kong (Xianggang) +# Hong Kong # Milne gives 7:36:41.7; round this. -- 2.24.0

2 1

[PATCH] * asia: Correct Hong Kong section name.
by Jimmy Yuen Ho Wong Dec. 18, 2019

Dec. 18, 2019

There are no records of Hong Kong being referred to as Xianggang, in the past or currently. The Pinyin romanization scheme of the Mandarin pronunciation of 香港 is not officially recognized or even mentioned in official documents. https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html https://www.elegislation.gov.hk/hk/cap5 --- asia | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/asia b/asia index cca004f..4f19d14 100644 --- a/asia +++ b/asia @@ -572,7 +572,7 @@ Zone Asia/Urumqi 5:50:20 - LMT 1928 6:00 - +06 -# Hong Kong (Xianggang) +# Hong Kong # Milne gives 7:36:41.7; round this. -- 2.24.0

1 0

isdst bug Europe/Dublin (tzdb-2019c)
by Stefan Rueger Dec. 16, 2019

Dec. 16, 2019

Looks like zdump claims Dublin has DST during winter, not summer: $ ./zdump -i -c2020,2021 Europe/Dublin TZ="Europe/Dublin" - - +00 GMT 1 2020-03-29 02 +01 IST 2020-10-25 01 +00 GMT 1 Compare with the output for London, which is as I would expect: $ ./zdump -i -c2020,2021 Europe/London TZ="Europe/London" - - +00 GMT 2020-03-29 02 +01 BST 1 2020-10-25 01 +00 GMT Generally, I think it's neater if the time stretches with the larger GMT values are considered DST. This is almost always true, except for Europe/Dublin, Eire, Africa/Casablanca and Africa/El_Aaiun. Morocco (and Western Sahara) change the time to have shorter fasts during Ramadan, so to speak to *not* save daylight. I would therefore still argue that the time outside Ramadan should be considered DST and the time during Ramadan the non-DST time. I am aware that the view "DST means larger GMT value" is not a precise definition (a region that change times zones in quick succession might easily accrue more than two GMT values within a few years). It's therefore not a great candidate for implementation in zic/zdump. However, I hold that periodic *future* annual back-and-forth switches should adopt that principle. Anyway, over to you Stefan PS: You are providing an *amazing* service - many thanks for that!

11 37

(no subject)
by Misty HICKMAN Dec. 16, 2019

Dec. 16, 2019

Yes . MistY 18months now . Very clear you know. The cAlEndAr Y ear ? Remember the TeaCUp ..

1 0