January 2019 - tz - lists.iana.org

new NIST leap-seconds.list
by Chris Woodbury Jan. 31, 2019

Jan. 31, 2019

Thanks to Dr. Levine, NIST has a newer version of leap-seconds.list with an expiry of 28 Dec 2019. Hurrah!! (Note: I re-named it so I could see the different versions.) $ FIPS180 -f NIST_leap-seconds.3676924800.2019-01-31 -v -h Generated SHA digest matches file digest File name: NIST_leap-seconds.3676924800.2019-01-3 Original file name: leap-seconds.3676924800 Last modified: 31 Jan 2019 08:02:47 UTC Updated: 08 Jul 2016 00:00:00 UTC Expires: 28 Dec 2019 00:00:00 UTC #h 83c68138 d3650221 07dbbbcd 11fcc859 ced1106a $

1 0

Time Zone Standards
by Samah Kareem Jan. 31, 2019

Jan. 31, 2019

Hello All I want to ask about references, countries can change their time zone depending on, I want name of standards, guidelines if any. Regards Samah Kareem

3 2

Daylight saving in 2372
by Arthur David Olson Jan. 30, 2019

Jan. 30, 2019

In the "Star Trek: Deep Space Nine" episode "Paradise Lost," Captain Sisko, at Starfleet's San Francisco headquarters, mentions "19 hundred 47 hours P. S. T." Per one source*, theepisode is set in June 2372. Seems there's no daylight saving in San Francisco in 2372, but the "standard" "S" is still used. @dashdashado _ *http://www.johnstonsarchive.net/startrek/st-episodes-1.html

5 5

Bulletin C number 57
by Chris Woodbury Jan. 30, 2019

Jan. 30, 2019

Something else, as it may not be obvious. The comments and white space do not contribute to the FIPS 180 digest and they may all be edited with impunity. This is the primary reason that using the date in the comments as data is such a bad idea. There's absolutely is no way to detect any changes or tampering. So, if someone doesn't like the fact that I put in the sign of the TAI-UTC delta T (or the MJD) as comments, edit it out. (Or any line starting with # (except the timestamps) for that matter.) Paul, your "corrected" leap-seconds.list file is an attachment.

1 0

California Prop 7 approved by voters
by Alan Mintz Jan. 29, 2019

Jan. 29, 2019

Since I don't see it mentioned... In November 2018, California voters approved Proposition 7 (by a 60-40 vote), which allows the state legislature to put the state on UTC-7 (the current DST) year-round. It requires a 2/3 majority in legislature, and federal law would have to be changed to allow it as well. Apparently, Florida did something similar, and Senator Marco Rubio is pushing bills in the U.S. Senate to legalize the changes. [ http://www.capradio.org/articles/2018/11/08/californias-daylight-saving-pro… ] California Assembly Bill 7 <http://leginfo.legislature.ca.gov/faces/billStatusClient.xhtml?bill_id=2019…> was introduced in December 2018 and is currently in committee. U.S. Senate bills S. 2536 <https://www.congress.gov/bill/115th-congress/senate-bill/2536> and S. 2537 <https://www.congress.gov/bill/115th-congress/senate-bill/2537> were introduced in March 2018 and are currently in committee. -- Alan Mintz <Alan.Mintz(a)gMail.com>

1 0

Re: [tz] Bulletin C number 57
by Chris Woodbury Jan. 29, 2019

Jan. 29, 2019

Brian Inglis is correct, changes to the "white space" [newline, space, tab, and carriage return] and comments do not change FIPS 180 Secure Hash Standard (SHS) digests. And, yes, Paul Eggert is correct, I have a script that generated the file I submitted to the mailing list. However, it was written for my personal use (I generate my own leap-seconds.list file for use by NTPd on my local systems) and does decidedly *not* meet all the restrictions placed upon the code within the TZ sphere.by ICANN/IANA (and IETF?). I shudder at the thought of making it do so. First, it uses GNU's sha1sum to calculate the FIPS 180 digest string. sha1sum will return the same digest as FIPS 180 given the *same input*. The trick is getting the same input... It also uses tolower() in AWK to ease the parsing it does. (I've got a FIPS180 shell function, too.) Two, the script is really automatic. It parses Bulletin C and the USNO/MAIA's leapsec.dat file. I use AWK to pull leap-second data from leapsec.dat, convert it to NTP timestamps and TAI-UTC offsets, which, along with the data extracted from Bulletin C (which provides the update and expiry timestamps) is all the information needed to make a leap-seconds.list file. Lastly, *it literally drives me nuts* (see real mail address) that leapseconds.awk uses the date in the comments to generate "leapseconds". So, no, I don't think I'll change the comments in the file. THEY'RE COMMENTS! There is no, none, zero, nada guarantee the comments represent anything in particular. Data on the other hand, does ... we really should be using it. Maybe we should be using USNO/MAIA leapsec.dat to generate the ZIC Leap directives in the first place. The date there is not a comment. It's also easier to manipulate days than seconds (86400 time less chance of an overflow.) We could even generate our own version of leap-seconds.list for downstream users (and never worry about government shutdowns again). (A trade-off with Paris rioting?) IERS/USNO/MAIA Bulletin A (ser7.dat), series14.txt and leapsec.dat could be used instead of the the copyright files at the Paris Observatory. This is not to say I won't help. I would be glad to provide leapseconds.awk code that use the *actual data* to generate the proper ZIC Leap directives. I have several versions of leapseconds.awk that meet all hoops the TZ code must be put through. In particular, I, and Dennis Ferguson, have AWK functions that manipulate NTP timestamps into a format that can generate date strings usable for ZIC LEAP directives. Thanks to dennis.c.ferguson for the germ of an idea to start years on 1 March when calculating leap-days. BTW, Dennis, 15th century Gregorian timestamps are not proleptic. The Gregorian calendar starts on 15 Oct 1582 (14th cent). A belated and long overdue thanks to Paul for pointing out Dennis function. I apologize. Finally, this is all moot, the shutdown is over, NIST will eventually make an updated leap-seconds.list file (with the wrong update timestamp but a correct expiry). Also, Jeff Prillaman at USNO Time Services Dept. has put up an updated leap-seconds.list file at Tycho.USNO.Navy.Mil. (Thank you, Jeff !!) (The GIT backup source for leap-seconds.list (I hope)?)

1 0

Java TZDB compiler
by Marcos Passos Jan. 26, 2019

Jan. 26, 2019

Hello, The Java TZDB compiler models transitions in terms of historical transitions and transition rules. All transition rules start one year after the latest year among the unbounded rules in the TZDB database for a given zone. Reading the docs, I found the following explanation about that extra year: Also add one more year to avoid weird case where penultimate year has odd > offset. Does anyone know what does it mean and in which cases does it occur? - Marcos

2 2

How long will the rearguard formats continue be provided?
by Pramoth Murali Jan. 25, 2019

Jan. 25, 2019

Hello! Our team utilizes a custom version of tzcode and a calendar utility that don't support negative DST offsets that was brought back in 2018e nor the 2018f fallback transactions Japan rules that were at 25:00 hour. We utilized 2018i rearguard-format version and we were able to utilize 2018i with our parsers. The 2018i announcement mentions that the rearguard is intended to be a temporary transition aid; that raises fear if we have to patch one of the upcoming tzdata releases that don't provide a rearguard with similar fixes. While we are planning to work on fixes for our timezone parsers; in order to ensure we have enough leeway for our new solutions, we would be curious to know how long will these rearguard versions (with no negative offsets) continue to be provided?

4 4

[PROPOSED] Put “North” before “Macedonia”
by Paul Eggert Jan. 25, 2019

Jan. 25, 2019

* backzone, europe, iso3166.tab: Put “North” before “Macedonia” in commentary and metadata. Might as well do it now, since the name change appears to be a done deal. This does not affect time data. --- backzone | 2 +- europe | 4 ++-- iso3166.tab | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/backzone b/backzone index 97792b1..c464ce6 100644 --- a/backzone +++ b/backzone @@ -625,7 +625,7 @@ Zone Europe/Sarajevo 1:13:40 - LMT 1884 1:00 - CET 1982 Nov 27 1:00 EU CE%sT -# Macedonia +# North Macedonia Zone Europe/Skopje 1:25:44 - LMT 1884 1:00 - CET 1941 Apr 18 23:00 1:00 C-Eur CE%sT 1945 May 8 2:00s diff --git a/europe b/europe index 587f7b0..b735a48 100644 --- a/europe +++ b/europe @@ -1855,7 +1855,7 @@ Zone Europe/Luxembourg 0:24:36 - LMT 1904 Jun 1:00 Belgium CE%sT 1977 1:00 EU CE%sT -# Macedonia +# North Macedonia # See Europe/Belgrade. # Malta @@ -3359,7 +3359,7 @@ Zone Europe/Belgrade 1:22:00 - LMT 1884 Link Europe/Belgrade Europe/Ljubljana # Slovenia Link Europe/Belgrade Europe/Podgorica # Montenegro Link Europe/Belgrade Europe/Sarajevo # Bosnia and Herzegovina -Link Europe/Belgrade Europe/Skopje # Macedonia +Link Europe/Belgrade Europe/Skopje # North Macedonia Link Europe/Belgrade Europe/Zagreb # Croatia # Slovakia diff --git a/iso3166.tab b/iso3166.tab index c2e0f8e..98fb988 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -166,7 +166,7 @@ ME Montenegro MF St Martin (French) MG Madagascar MH Marshall Islands -MK Macedonia +MK North Macedonia ML Mali MM Myanmar (Burma) MN Mongolia -- 2.17.1

1 0

Metlakatla
by TechOps Jan. 22, 2019

Jan. 22, 2019

Hello. The Metlakatla community in Alaska has decided not to change its clock back an hour starting on November 4th, 2018 (day before yesterday). They will be gmtoff=-28800 year-round. I'm told this is the list to send this information to. Any assistance or advice on getting this updated in the database is appreciated. https://www.facebook.com/141055983004923/photos/pb.141055983004923.-2207520… [image: MIC time change.jpg] - Ryan _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ AKTechOps <http://serrc.org/techops> | techops(a)serrc.org | *(907) 523-7290* *| Brian 523-7248 | Michaela 523-7258 | Nate 523-7275 | Nick 523-7291 | Ryan 523-7272 | SERRC 586-6806 |*

7 13