- tz - lists.iana.org

Today's CalConnect event
by Arthur David Olson Feb. 14, 2019

Feb. 14, 2019

I listened in on today's just-concluded CalConnect event; CalConnect is "the calendaring and scheduling consortium." Just a few notes. I heard hopes for work on the time zone database, both changes (to opaque time zone identifiers) and additions (of localization information, zone boundary information, and sequencing information to track splits and mergers of time zones). There was recognition that the database work is a volunteer effort and that there's a limit to what volunteers can do. There was mention by an ISO person of ISO's effort to establish a time zone registry with requirements for advance notification of changes; the hope is that the ISO's governmental connections would help encourage compliance. A Google representative noted the company's "under construction" (no details provided) effort to develop a time zone information distribution mechanism that would allow data to get from IANA publication to in-the-field devices within a month (seen as a reasonable objective that would deal with most real-world situations). Folks saw value in having open database maintenance processes (such as the one now used by IANA) and in having multiple sources of time zone information (that can be cross-checked against one another). I trust that other folks will correct and elaborate as appropriate. @dashdashado

11 18

[PROPOSED] Internet RFC 8536 has been published
by Paul Eggert Feb. 14, 2019

Feb. 14, 2019

* Makefile, NEWS, theory.html, tz-link.html, tzfile.5, tzfile.h: Mention the new RFC. --- Makefile | 4 ++-- NEWS | 2 ++ theory.html | 4 +++- tz-link.html | 13 ++++++------- tzfile.5 | 14 ++++++++++++-- tzfile.h | 3 +++ 6 files changed, 28 insertions(+), 12 deletions(-) diff --git a/Makefile b/Makefile index 1e0a5e4..680f040 100644 --- a/Makefile +++ b/Makefile @@ -115,8 +115,8 @@ TIME_T_ALTERNATIVES = $(TIME_T_ALTERNATIVES_HEAD) $(TIME_T_ALTERNATIVES_TAIL) TIME_T_ALTERNATIVES_HEAD = int64_t TIME_T_ALTERNATIVES_TAIL = int32_t uint32_t uint64_t -# What kind of TZif data files to generate. -# (TZif is the binary time zone data format that zic generates.) +# What kind of TZif data files to generate. (TZif is the binary time +# zone data format that zic generates; see Internet RFC 8536.) # If you want only POSIX time, with time values interpreted as # seconds since the epoch (not counting leap seconds), use # REDO= posix_only diff --git a/NEWS b/NEWS index 7a84052..f5d708c 100644 --- a/NEWS +++ b/NEWS @@ -14,6 +14,8 @@ Unreleased, experimental changes Changes to documentation + Mention Internet RFC 8536 (February 2019), which documents TZif. + tz-link.html now cites tzdata-meta <https://tzdata-meta.timtimeonline.com/>. diff --git a/theory.html b/theory.html index a8da065..5ea1369 100644 --- a/theory.html +++ b/theory.html @@ -983,7 +983,9 @@ an older <code>zic</code>. constrained to be a string containing abbreviations and numeric data as described <a href="#POSIX">above</a>. The file's format is <dfn><abbr>TZif</abbr></dfn>, - a timezone information format that contains binary data. + a timezone information format that contains binary data; see + <a href="https://tools.ietf.org/html/8536">Internet + <abbr>RFC</abbr> 8536</a>. The daylight saving time rules to be used for a particular timezone are encoded in the <abbr>TZif</abbr> file; the format of the file allows <abbr>US</abbr>, diff --git a/tz-link.html b/tz-link.html index efeacd0..89ebd40 100644 --- a/tz-link.html +++ b/tz-link.html @@ -144,7 +144,9 @@ After obtaining the code and data files, see the <code>README</code> file for what to do next. The code lets you compile the <code><abbr>tz</abbr></code> source files into machine-readable binary files, one for each location. The binary files -are in a special timezone information format (<dfn><abbr>TZif</abbr></dfn>). +are in a special timezone information format (<dfn><abbr>TZif</abbr></dfn>) +specified by <a href="https://tools.ietf.org/html/8536">Internet +<abbr>RFC</abbr> 8536</a>. The code also lets you read a <abbr>TZif</abbr> file and interpret timestamps for that location.</p> @@ -282,15 +284,12 @@ along with <a href="https://tools.ietf.org/html/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for transferring time zone data by reference. The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis -mailing list</a> discusses two Internet drafts: <a +mailing list</a> discusses the Internet draft <a id="TZDIST-Geolocate" href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate">TZDIST -Geolocate Extension</a> lets a client determine its timezone +Geolocate Extension</a>, which lets a client determine its timezone from its geographic location using a <a -href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>, and -<a href="https://tools.ietf.org/html/draft-murchison-tzdist-tzif">The -Time Zone Information Format (<abbr>TZif</abbr>)</a> specifies the format of -<abbr>TZif</abbr> data.</li> +href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> Internet Calendaring and Scheduling Core Object Specification (iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) diff --git a/tzfile.5 b/tzfile.5 index bbdccfc..2f70915 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -15,7 +15,8 @@ The timezone information files used by .BR tzset (3) are typically found under a directory with a name like .IR /usr/share/zoneinfo . -These files begin with a 44-byte header containing the following fields: +These files use the format described in Internet RFC 8536. +The format begins with a 44-byte header containing the following fields: .IP * 2 The magic four-byte ASCII sequence .q "TZif" @@ -384,6 +385,15 @@ of one hour, or of 15 minutes, or of 1 minute. .BR tzset (3), .BR tzselect (8), .BR zdump (8), -.BR zic (8) +.BR zic (8). +.PP +Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). +2019 Feb. +.UR https://\:www.rfc-editor.org/\:info/\:rfc8536 +Internet RFC 8536 +.UE +.UR https://\:doi.org/\:10.17487/\:RFC8536 +doi:10.17487/RFC8536 +.UE . .\" This file is in the public domain, so clarified as of .\" 1996-06-05 by Arthur David Olson. diff --git a/tzfile.h b/tzfile.h index 27a38cc..446c8d5 100644 --- a/tzfile.h +++ b/tzfile.h @@ -33,6 +33,9 @@ #define TZDEFRULES "posixrules" #endif /* !defined TZDEFRULES */ + +/* See Internet RFC 8536 for more details about the following format. */ + /* ** Each file begins with. . . */ -- 2.20.1

2 5

Fwd: RFC 8536 on The Time Zone Information Format (TZif)
by Ken Murchison Feb. 13, 2019

Feb. 13, 2019

FYI. -------- Forwarded Message -------- Subject: RFC 8536 on The Time Zone Information Format (TZif) Date: Tue, 12 Feb 2019 12:48:24 -0800 (PST) From: rfc-editor(a)rfc-editor.org Reply-To: ietf(a)ietf.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: drafts-update-ref(a)iana.org, rfc-editor(a)rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 8536 Title: The Time Zone Information Format (TZif) Author: A. Olson, P. Eggert, K. Murchison Status: Standards Track Stream: IETF Date: February 2019 Mailbox: arthurdavidolson(a)gmail.com, eggert(a)cs.ucla.edu, murch(a)fastmailteam.com Pages: 34 Characters: 83992 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-murchison-tzdist-tzif-16.txt URL: https://www.rfc-editor.org/info/rfc8536 DOI: 10.17487/RFC8536 This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC

1 0

zic option for including data from a certain year onward
by Christopher Wong Feb. 5, 2019

Feb. 5, 2019

Hi, I think the tzdb is very good with its history. However, I would like to minimize the size and has been looking into how to achieve that. Will it be of any interest with an option in zic to include only data from a certain year onward? What is the best way? 1.? Remove the Rules and Zone entries not relevant for that year onward during the parsing. Tried this, but ended up with with some nasty warnings. 2. Make changes in writezone-function. Trying this now, but I am getting confused with types, omittype, typemap, and so on. It would be good if someone that knows the code can give me some hints if this is the right place to make such a change. BR, Christopher Wong

4 4

About time
by Arthur David Olson Feb. 2, 2019

Feb. 2, 2019

Having stumbled across a copy of the educational film "About Time," I can correct the quotations that kick off the README file; the diffs should be attached. @dashdashado

4 3

Europe/Budapest timezone
by Lev Feb. 2, 2019

Feb. 2, 2019

Dear all, I've downloaded the current time zone data from this link: https://data.iana.org/time-zones/releases/tzdata2018i.tar.gz , and compiled the time zone files with zic. For Europe/Budapest, I got this tz string: CET-1CEST,M3.5.0,M10.5.0/3 I think IMHO it should be: CET-1CEST,M3.5.0/2,M10.5.0/3 Best regards, Levente -- Levente Kovacs Senior Electronic Engineer W: http://levente.logonex.eu

4 5

Fwd: Bulletin C number 57
by Tim Parenti Feb. 1, 2019

Feb. 1, 2019

FYI, per IERS Bulletin C57, there will be no leap second on 2019-06-30. Unfortunately, NIST is affected by the partial shutdown of the US government <https://www.commerce.gov/news/blog/2018/12/shutdown-due-lapse-congressional…> which has been ongoing since 2018-12-22 00:00 -05, so most of their website is unavailable, meaning it will likely be some time before they publish an updated leap-seconds.list. But since the current NIST file doesn't expire until 2019-06-28, we've got some time before we have to deal with that. Last we had left the problem of being able to take the equivalent file directly from the IERS at https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list, some lines had been added to https://hpiers.obspm.fr/iers/bul/bulc/README on 2017-04-11, but the exact text did not make any assertions about surrounding files, and we would prefer the notice be added to leap-seconds.list itself. (There are a few other typos therein which I spotted as well.) See: https://mm.icann.org/pipermail/tz/2017-April/024990.html https://mm.icann.org/pipermail/tz/2017-April/024988.html In light of the current US/NIST situation, it would be helpful to re-energize these efforts. Happy to help Christian and others come up with something workable. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Mon, 7 Jan 2019 at 10:56 Subject: Bulletin C number 57 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 07 January 2019 Bulletin C 57 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2019. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

8 19

[calsify] Streaming info for CalConnect Public Time Zone Workshop on February 5 in Zurich, Switzerland
by David Thewlis Jan. 31, 2019

Jan. 31, 2019

The CalConnect Public Time Zone Workshop will be next Tuesday, 5 February 2019, between 1400 and 1730 Central European Time. We have made arrangements with our host, Google, to stream the CalConnect Public Time Zone Workshop <https://www.calconnect.org/events/calconnect-public-time-zone-worksjop> for any interested parties who cannot be present. (The workshop was announced in November and we did get a few queries as to streaming.) The streaming will be done using Google Hangouts; the URL to join the stream is https://meet.google.com/qjb-zbip-cpf <https://meet.google.com/qjb-zbip-cpf>. You do have to have a google id of some sort (gmail is fine) to join the streaming. When you access the stream, your request to join will be authorized. Please do not attempt to join before 1345 CET. The workshop itself will take place between 1400-1730 CET. The inbound audio and video stream will be disabled, so this will be a one-way outbound feed. However, there is a chat function so you can ask questions via the chat. Our plan is to take periodic pauses so the chat questions can be brought up and answered. If that proves impractical we will answer the chat questions after the workshop is over, so you’ll want to include an e-mail address for a response. Dave Thewlis Here’s the original post: Please note that this is NOT an IETF event. CalConnect <http://www.calconnect.org/> will host a Public Time Zone Workshop on Tuesday afternoon, February 5th, during its conference at Google in Zürich, Switzerland <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019>. The Time Zone Workshop will be Tuesday February 5th from 13:30 to 17:30 at the Google facility <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019#location>. This workshop will be focussed on the potential impact of EU Summer Time changes and how the changes might be mitigated; please see our news release <http://www.calconnect.org/news/2018/10/30/calconnect-calls-eu-reconsider-ti…>. The workshop is open to the public but you must register in advance. There is no fee to attend the workshop. Attendees are invited to stay for a Welcome Reception following the workshop. More information will be provided as planning continues. The workshop is intended for anyone who needs to plan and prepare for this and other TZ/DST changes, in particular representatives from governments, industries affected by tz changes (travel, financial, health, device manufacturers, etc.), organizations deploying tz data, and organizations maintaining and updating tz data. Please register for this event at https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets… <https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets…>. We invite anyone who is interested in or concerned by the pending changes and how time zone change information might better be distributed and implemented to attend. Dave Thewlis -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org <http://www.calconnect.org/> | Dave.Thewlis(a)calconnect.org <mailto:Dave.Thewlis@calconnect.org> _______________________________________________ calsify mailing list calsify(a)ietf.org https://www.ietf.org/mailman/listinfo/calsify

1 0

DST ends 2040 in Oracle database
by Joachim Damm Jan. 31, 2019

Jan. 31, 2019

Hello, we found one issue in the Oracle database that DST calculation is wrong from 2040 and beyond. I create a SR at Oracle and the Oracle support told me, that this behavior is from the IANA tzdata file and not from Oracle. My question is, if this is the case, where can I find the required information? If this is not the case, please let me also know to give the information to the Oracle support. I will appreciate your feedback regarding the information from the Oracle SR team! Mit freundlichen Grüßen / Kind Regards i.A. Joachim Damm Senior Database Consultant Systems Integration [cid:image001.jpg@01CF7F53.FD0881C0] Werum IT Solutions GmbH Wulf-Werum-Str. 3, 21337 Lüneburg, Germany T +49 4131 8900-515 F +49 4131 8900-20 Joachim.Damm(a)Werum.com<mailto:Joachim.Damm@Werum.com> www.werum.com<http://www.werum.com/> Geschäftsführer / Managing Directors: Rüdiger Schlierenkämper, Richard Nagorny, Hans-Peter Subel RG Lüneburg / Court of Jurisdiction: Lüneburg, Germany Handelsregisternummer / Commercial Register: HRB 204984 USt.-IdNr. / VAT No.: DE 116 083 850 Connect with us: [cid:image006.jpg@01D4B3D4.B9323120] <https://www.linkedin.com/company/werum> [cid:image007.jpg@01D4B3D4.B9323120] <https://twitter.com/werum> [cid:image008.jpg@01D4B3D4.B9323120] <http://www.vimeo.com/werum> [cid:image009.jpg@01D4B3D4.B9323120] <https://www.youtube.com/werum>

12 23

Re: [tz] DST ends 2040 in Oracle database
by Brian Inglis Jan. 31, 2019

Jan. 31, 2019

On 2019-01-31 15:25, Scott Nelson wrote: >> On Jan 31, 2019, at 4:17 PM, Brian Inglis wrote: >> Device expiration date is specified as ISO: >> https://www.ecfr.gov/cgi-bin/retrieveECFR?n=se21.8.801_118 >> "Title 21 → Chapter I → Subchapter H → Part 801 → Subpart A → §801.18 >> Title 21: Food and Drugs >> PART 801—LABELING >> Subpart A—General Labeling Provisions >> §801.18 Format of dates provided on a medical device label. >> ... >> (a) In general. Whenever the label of a medical device includes a printed >> expiration date, date of manufacture, or any other date intended to be brought >> to the attention of the user of the device, the date must be presented in the >> following format: The year, using four digits; followed by the month, using two >> digits; followed by the day, using two digits; each separated by hyphens. For >> example, January 2, 2014, must be presented as 2014-01-02. >> ... >> [78 FR 58818, Sept. 24, 2013]” > Yeah, but the exception is rather large: > (b) Exceptions. (1) A combination product that properly bears a National Drug > Code (NDC) number is not subject to the requirements of paragraph (a) of this > section. Why I restricted my statement to "Device expiration date" -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.

1 0

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

Re: [tz] Bulletin C number 57
by Hal Murray Jan. 20, 2019

Jan. 20, 2019

eggert(a)cs.ucla.edu said: > but I worry that the format change will also mess up downstream programs too > (notably NTP-related) Worked OK for ntpsec. There is a checksum in the file, but it only covers the non-comment digits in the file. (so white space changes are OK) The payload lines must start on column 1 - no leading white space. -- These are my opinions. I hate spam.

3 2

Conrad Maldives Rangali Island resort
by Deborah Goldsmith Jan. 20, 2019

Jan. 20, 2019

Apparently, this resort in the Maldives has its own time zone and observes GMT+06 year round, unlike Male at GMT+05. It looks like we’d need a new zone for this. Source: Internal reports and: http://conradglobalmediacenter.com/assets/CNRD/docs/FactSheets/ConradMaldiv… (search for “Local Time”) I wasn’t able to find any source contradicting this information. Apparently it’s a known issue that Maldives resort islands have their own (unofficial) time zones: https://www.timeanddate.com/time/zone/maldives At the moment, users need to find a time zone that has the same GMT offset (in this case Indian/Chagos works) and use that instead. Thanks, Debbie

11 15

Some rules in tz specification files seem to be applied (by zic) outside of their declared period of applicability
by Parsifal Herzog Jan. 19, 2019

Jan. 19, 2019

In the example shown below, copied from from tzdata2018i Africa file, the last Zone line, referencing the Namibia rule, should start at 1990 March 21 2:00 am. There are no Namibia transitions defined from that start, until 1994. However zic does create a transition using the second Namibia rule at the start time, as shown in the zdump output below. There are many other cases like this, where an UNTIL specification ends well before the next applicable rule of the following zone line. I am trying to read the zic manual page as a specification, and I do not understand why zic inserts that transition. It seems to me that either the last Zone line (SAST) would remain in effect until 1994, as there is no other transition defined, or that period is in an undefined state, as the SAST transition is not in effect after1990 March 21. Can someone correct my understanding? ------- Specification extract # RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Vanguard section, for zic and other parsers that support negative DST. Rule Namibia 1994 only - Mar 21 0:00 -1:00 WAT Rule Namibia 1994 2017 - Sep Sun>=1 2:00 0 CAT Rule Namibia 1995 2017 - Apr Sun>=1 2:00 -1:00 WAT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Windhoek 1:08:24 - LMT 1892 Feb 8 1:30 - +0130 1903 Mar 2:00 - SAST 1942 Sep 20 2:00 2:00 1:00 SAST 1943 Mar 21 2:00 2:00 - SAST 1990 Mar 21 # independence # Vanguard section, for zic and other parsers that support negative DST. 2:00 Namibia %s ------ Zicdump output: $ zdump -v -c 1892,1996 Africa/Windhoek Africa/Windhoek -9223372036854775808 = NULL Africa/Windhoek -9223372036854689408 = NULL Africa/Windhoek Sun Feb 7 22:51:35 1892 UT = Sun Feb 7 23:59:59 1892 LMT isdst=0 gmtoff=4104 Africa/Windhoek Sun Feb 7 22:51:36 1892 UT = Mon Feb 8 00:21:36 1892 +0130 isdst=0 gmtoff=5400 Africa/Windhoek Sat Feb 28 22:29:59 1903 UT = Sat Feb 28 23:59:59 1903 +0130 isdst=0 gmtoff=5400 Africa/Windhoek Sat Feb 28 22:30:00 1903 UT = Sun Mar 1 00:30:00 1903 SAST isdst=0 gmtoff=7200 Africa/Windhoek Sat Sep 19 23:59:59 1942 UT = Sun Sep 20 01:59:59 1942 SAST isdst=0 gmtoff=7200 Africa/Windhoek Sun Sep 20 00:00:00 1942 UT = Sun Sep 20 03:00:00 1942 SAST isdst=1 gmtoff=10800 Africa/Windhoek Sat Mar 20 22:59:59 1943 UT = Sun Mar 21 01:59:59 1943 SAST isdst=1 gmtoff=10800 Africa/Windhoek Sat Mar 20 23:00:00 1943 UT = Sun Mar 21 01:00:00 1943 SAST isdst=0 gmtoff=7200 Africa/Windhoek Tue Mar 20 21:59:59 1990 UT = Tue Mar 20 23:59:59 1990 SAST isdst=0 gmtoff=7200 Africa/Windhoek Tue Mar 20 22:00:00 1990 UT = Wed Mar 21 00:00:00 1990 CAT isdst=0 gmtoff=7200 <------ zic inserted the 1994 "CAT" transition. How was this chosen? Africa/Windhoek Sun Mar 20 21:59:59 1994 UT = Sun Mar 20 23:59:59 1994 CAT isdst=0 gmtoff=7200 Africa/Windhoek Sun Mar 20 22:00:00 1994 UT = Sun Mar 20 23:00:00 1994 WAT isdst=1 gmtoff=3600 <----- first applicable rule in 1994. Africa/Windhoek Sun Sep 4 00:59:59 1994 UT = Sun Sep 4 01:59:59 1994 WAT isdst=1 gmtoff=3600 Africa/Windhoek Sun Sep 4 01:00:00 1994 UT = Sun Sep 4 03:00:00 1994 CAT isdst=0 gmtoff=7200 Africa/Windhoek Sat Apr 1 23:59:59 1995 UT = Sun Apr 2 01:59:59 1995 CAT isdst=0 gmtoff=7200 Africa/Windhoek Sun Apr 2 00:00:00 1995 UT = Sun Apr 2 01:00:00 1995 WAT isdst=1 gmtoff=3600 Africa/Windhoek Sun Sep 3 00:59:59 1995 UT = Sun Sep 3 01:59:59 1995 WAT isdst=1 gmtoff=3600 Africa/Windhoek Sun Sep 3 01:00:00 1995 UT = Sun Sep 3 03:00:00 1995 CAT isdst=0 gmtoff=7200 Africa/Windhoek 9223372036854689407 = NULL Africa/Windhoek 9223372036854775807 = NULL -------

6 6

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

Jan. 19, 2019

On Tue Jan 8 01:32:04 UTC 2019, Paul Eggert wrote:> In the meantime perhaps we could forge the NIST leap-seconds.list file > (including a comment that it's a forgery and why we're doing the > forgery), and then substitute the real thing whenever it shows up. I'd > rather have a script to do that than do it by hand, though. We'd need > that script anyway if we start basing our distribution on the IERS file, > as so many users now grab the NIST file from us rather than from the NIST.Your wish is my command.... # -=*( This file is in the public domain )*=- # This NTP leap-second file was created with data obtained from # the United States Naval Observatory (USNO) MAIA FTP server. # # Find it at: <ftp://maia.usno.navy.mil/ser7/leapsec.dat> # Updated using information from IERS Bulletin C 57 (7 Jan 2019) # Found at <ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat> # # This file is not a forgery, per se, but it is created # by some one/thing other than a national metrology lab. # It is necessitated by a current US government shutdown # and the resulting lack of an NIST generated file. # # UTC is a time scale based upon standard international (SI) # seconds and derived from Temps Atomique International (TAI). # # Leap seconds are an official correction to UTC to keep it # within 0.9 seconds of UT1; yet another time standard # based upon the orientation of the earth in space. # # These data, kept in "leap-seconds.list", are used by the # Network Time Protocol daemon (NTPd) to determine when to # apply leap seconds to Coordinated Universal Time (UTC). # "leap-seconds.list" is a symbolic link to the actual # file name, leap-seconds.xxxxxxxxxx, where xxxxxxxxxx # is derived from the NTP update timestamp (below). # # Theoretically, a leap second may be positive or negative. # Realistically, negative leap seconds are unlikely to occur. # # All timestamps in this leap seconds file are encoded using the # NTP epoch. These timestamps represent the number of seconds # since 1 Jan 1900 0:00:00. This is Modified Julian Date (MJD) # 15020 and Julian Date 2415020.5. There will be an unsigned # 32-bit overflow to the second NTP era in 2036 (07 Feb 2036 # 06:28:16 UTC to be precise). # # A leap second datum consists of an NTP timestamp and the # number of seconds difference between TAI and UTC (e.g. # currently TAI-UTC is 37). UTC was established at midnight on # 1 Jan 1972 with TAI-UTC started at 10. There was no mechanism # prior to that time defining when to apply leap seconds. # # Note: the first datum in the leap-seconds.list file is *not* # a leap-second; it denotes the definition of the UTC timescale. # # Leap-seconds rules are establish in: # # International Telecommunications Union-Regulation (ITU-R) # 460-6, Annex 1, Section 2. # # <http://www.itu.int/rec/R-REC-TF.460-6-200202-I/> # # NTP Leap second files have an update time (#$). This is often # the UTC zero (0) hour time of the day when the leap second file # is built. It should be updated whenever a new IERS Bulletin C # is issued. # #$ 3755808000 # # Leap second data have a lifetime. Traditionally, this ends on # the twenty-eighth (28) day of the month six months after the # period of time described in the latest IERS Bulletin C. This # is the expiry time (#@). # #@ 3786480000 # # Leap second files have a hash, as define in NIST's FIPS 180 # Secure Hash Standard (SHS), current revision 4 (FIPS 180-4). # # FIPS Publications: <http://csrc.nist.gov/publications/fips/> # Direct Link: <http://dx.doi.org/10.6028/NIST.FIPS.180-4> # # It is based on an SHA[1] digest, created using the data # portions of the file including leap second data and the update # and expiry timestamps. All "white space" and comments are # excluded in the computation thereof. The 160-bit SHA[1] # digest polynomial are encoded in five hexadecimal grouping at # the end of the file (#h). The hash itself is NOT included in # the SHA[1]. It can also be calculated using GNU sha1sum which # generates the same 160-bit digest, given the same data, in # forty hexadecimal characters. # # NTP delta #timestamp T sign Date of Change 2272060800 10 # + : 1 Jan 1972 (MJD 41317) 2287785600 11 # + : 1 Jul 1972 (MJD 41499) 2303683200 12 # + : 1 Jan 1973 (MJD 41683) 2335219200 13 # + : 1 Jan 1974 (MJD 42048) 2366755200 14 # + : 1 Jan 1975 (MJD 42413) 2398291200 15 # + : 1 Jan 1976 (MJD 42778) 2429913600 16 # + : 1 Jan 1977 (MJD 43144) 2461449600 17 # + : 1 Jan 1978 (MJD 43509) 2492985600 18 # + : 1 Jan 1979 (MJD 43874) 2524521600 19 # + : 1 Jan 1980 (MJD 44239) 2571782400 20 # + : 1 Jul 1981 (MJD 44786) 2603318400 21 # + : 1 Jul 1982 (MJD 45151) 2634854400 22 # + : 1 Jul 1983 (MJD 45516) 2698012800 23 # + : 1 Jul 1985 (MJD 46247) 2776982400 24 # + : 1 Jan 1988 (MJD 47161) 2840140800 25 # + : 1 Jan 1990 (MJD 47892) 2871676800 26 # + : 1 Jan 1991 (MJD 48257) 2918937600 27 # + : 1 Jul 1992 (MJD 48804) 2950473600 28 # + : 1 Jul 1993 (MJD 49169) 2982009600 29 # + : 1 Jul 1994 (MJD 49534) 3029443200 30 # + : 1 Jan 1996 (MJD 50083) 3076704000 31 # + : 1 Jul 1997 (MJD 50630) 3124137600 32 # + : 1 Jan 1999 (MJD 51179) 3345062400 33 # + : 1 Jan 2006 (MJD 53736) 3439756800 34 # + : 1 Jan 2009 (MJD 54832) 3550089600 35 # + : 1 Jul 2012 (MJD 56109) 3644697600 36 # + : 1 Jul 2015 (MJD 57204) 3692217600 37 # + : 1 Jan 2017 (MJD 57754) # #h ffee5390 2e3cf253 e15b646e 01768a18 e83785c3

2 1

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

Jan. 17, 2019

On Tue Jan 8 01:32:04 UTC 2019 Paul Eggert <eggert(a)cs.ucla.edu> wrote: > In the meantime perhaps we could forge the NIST leap-seconds.list file > (including a comment that it's a forgery and why we're doing the > forgery), and then substitute the real thing whenever it shows up. I'd > rather have a script to do that than do it by hand, though. We'd need > that script anyway if we start basing our distribution on the IERS file, > as so many users now grab the NIST file from us rather than from the NIST. Your wish is my command. See attachment.

1 0