March 2020 - tz - lists.iana.org

Italy April 1944 discrepancy between comment and data
by Alois Treindl 05 Oct '21

05 Oct '21

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 24 Apr '20

24 Apr '20

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

Israel DST -- Stay Tuned
by Ephraim Silverberg 23 Mar '20

23 Mar '20

Due to the current Corona Lockdown of the State of Israel that is expected to get more strict, the government is considering delaying the start of DST that was supposed to start this Friday morning: https://www.jpost.com/Breaking-News/Litzman-Health-Ministry-considering-pos… No final decision has been taken though so, meanwhile, the original switchover time is still in effect. I will try to update if and when changes take place.

5 6

FYI (no action necessary): Utah permanent DST
by Dave DeLong 23 Mar '20

23 Mar '20

Hi all, This is a heads up that in the last legislative session, Utah passed a bill that would move the state on to permanent Mountain Daylight Time (bill: https://le.utah.gov/~2020/bills/static/SB0059.html <https://le.utah.gov/~2020/bills/static/SB0059.html>). However, this bill does not take effect until two conditions are met: Congress enacts legislation to amend 15 U.S.C. Sec. 260a to authorize states to observe daylight saving time year-round and At least four western states (not including Utah) also move to year-round daylight time (western states are defined as Arizona, California, Colorado, Idaho, Montana, Nevada, New Mexico, Oregon, Utah, Washington, and Wyoming) If this ends up getting actually triggered (one can hope!) then I will email the list again with the notice. Cheers, Dave DeLong

2 1

Israel DST -- Stay Tuned
by Eytan Schulman 23 Mar '20

23 Mar '20

Israeli media has reported and confirmed that DST will not be postponed. "After announcing last night that daylight saving time will be delayed to prevent an extra hour of evening daylight and encourage people to stay home, Interior Minister Aryeh Deri says the move won’t be possible after all." "Deri’s office says in a statement that the National Security Council has advised against making the postponement, and that daylight saving time will begin as planned later this week, during the night between March 26 and March 27." https://www.timesofisrael.com/liveblog_entry/daylight-saving-time-wont-be-d…

1 0

Daylight saving in Israel likely postponed
by Kurt Alfred Kluever 22 Mar '20

22 Mar '20

https://www.jpost.com/Breaking-News/Litzman-Health-Ministry-considering-pos… https://www.timesofisrael.com/liveblog_entry/attorney-general-okays-potenti… Neither of these articles seem to constitute an official announcement, but this situation should be monitored closely, as it would be a very last minute change. Cheers, -- kak

1 0

zdump with version 1 files
by Paul Ganssle 22 Mar '20

22 Mar '20

Howdy, As part of the implementation of the new zoneinfo module for the Python standard library, I have been attempting to generate some version 1 files for test purposes (in the sadly likely event that some people only have version 1 TZif files deployed). I have done this by taking existing TZif files, truncating them at the second TZif header, and changing the version number in the truncated file. I notice, however, that with the 2019c version of zdump, the files generated this way are considered invalid: $ zdump --version zdump (tzcode) 2019c $ zdump -i -c2038,2039 $(realpath .)/America/Los_Angeles /tmp/zoneinfon3c1bcna/v1/America/Los_Angeles: Invalid argument $ zdump -i -c2010,2011 $(realpath .)/America/Los_Angeles /tmp/zoneinfon3c1bcna/v1/America/Los_Angeles: Invalid argument Interestingly, if I /do not/ truncate the file and just change the version to "1" (in both the first *and* second header), it will read the file /and/ it will clearly use the version 2/3 data: $ file Australia/Sydney Australia/Sydney: timezone data, version 1, no gmt time flags, 5 std time flags, no leap seconds, 142 transition times, 5 abbreviation chars $ zdump -i -c2200,2201 $(realpath .)/Australia/Sydney TZ="/tmp/zoneinfot3h5_eyf/v1/Australia/Sydney" - - +11 AEDT 1 2200-04-06 02 +10 AEST 2200-10-05 03 +11 AEDT 1 So I guess my question is: does zdump support well-formed version 1 files, and I am failing to create well-formed version 1 files, or does 2019c's zdump have no support for version 1 files? I'll note that this whole thing came up because I was wondering what zdump does for times after the last transition in a version 1 file. RFC 8536 indicates that this behavior is undefined - I was planning to hold the value of the offset after the last transition, but I figured I might as well check what zdump does. Thanks, Paul

5 10

Re: [tz] zdump with version 1 files
by Hal Murray 21 Mar '20

21 Mar '20

eggert(a)cs.ucla.edu said: > As far as I can recall, only Android limits itself to 32-bit timestamps > (expiring in 2039) among current operating systems, even the 32-bit OSes. I assume you mean time_t when you say "timestamps". 32 bit Debian, Raspberian, and FreeBSD/Intel have 32 bit time_t. 32 bit FreeBSD/ARM has a 64 bit time_t 32 bit Fedora had it too, but they dropped support for i386. I haven't tried their 32 bit ARM version. -- These are my opinions. I hate spam.

2 1

[PATCH] Fix warning message with non-alphanumerics
by Paul Ganssle 21 Mar '20

21 Mar '20

Hi folks, I have noticed a minor issue with the warning issued by zdump when passed non-alphanumerics in a TZ string. If the TZ string, in quoted or unquoted form, contains a non-alphanumeric within the first 3 characters, the message erroneously says that the abbreviation has fewer than 3 characters: $ zdump '<AE)ST>5' <AE)ST>5 Fri Mar 20 09:11:05 2020 AE_ST zdump: warning: zone "<AE)ST>5" abbreviation "AE_ST" has fewer than 3 characters $ zdump '<AES)T>5' <AES)T>5 Fri Mar 20 09:11:09 2020 AES_T zdump: warning: zone "<AES)T>5" abbreviation "AES_T" has characters other than ASCII alphanumerics, '-' or '+' $ zdump 'AE)ST5' AE)ST5 Fri Mar 20 09:09:41 2020 AE_ST zdump: warning: zone "AE)ST5" abbreviation "AE_ST" has fewer than 3 characters $ zdump 'AES)T5' AES)T5 Fri Mar 20 09:09:51 2020 AES_T zdump: warning: zone "AES)T5" abbreviation "AES_T" has characters other than ASCII alphanumerics, '-' or '+' I've attached a patch that I believe fixes this issue, as evidenced by this check run in my local directory: $ ./zdump "<AT>5" <AT>5 Fri Mar 20 09:35:09 2020 AT ./zdump: warning: zone "<AT>5" abbreviation "AT" has fewer than 3 characters $ ./zdump "<AE)ST>5" <AE)ST>5 Fri Mar 20 09:35:24 2020 AE_ST ./zdump: warning: zone "<AE)ST>5" abbreviation "AE_ST" has characters other than ASCII alphanumerics, '-' or '+' Thanks! Paul P.S. git send-email didn't work for me because I haven't set up git to send e-mails directly, so hopefully attaching the .patch file manually is OK.

2 1

Maryland permanent DST?
by Arthur David Olson 18 Mar '20

18 Mar '20

"Maryland could spring forward permanently with Daylight Saving Time bill." https://wtop.com/maryland/2020/03/maryland-could-spring-forward-permanently… State Senate action is set for tomorrow; stay tuned. @dashdashado

3 8