- tz - lists.iana.org

Re: [tz] Fwd: Bulletin C number 58
by Pierpaolo Bernardi July 27, 2019

July 27, 2019

Il giorno 27 luglio 2019, alle ore 05:17, David Patte <dpatte(a)relativedata.com> ha scritto: >For my products I use an algorithm (Meeus; Astronomical Algorithms 1998) to 'predict' deltaT into the future. Does anyone have a good source for a more recent algorithm that takes into account IERS values since 1998? This page may be a start: https://eclipse.gsfc.nasa.gov/SEhelp/deltatpoly2004.html

3 2

Fwd: Bulletin C number 58
by Kurt Roeckx July 27, 2019

July 27, 2019

8 11

NIST leap-seconds.list is finally here
by Chris Woodbury July 26, 2019

July 26, 2019

There is now an updated for July 2019 "leap-seconds.list" file at NIST. Both the Boulder and Greenbelt FTP sites have the new file. Attached find a patch (as follows). $ git diff leap-seconds.list diff --git a/leap-seconds.list b/leap-seconds.list index fd3d192..a1bc5a7 100644 --- a/leap-seconds.list +++ b/leap-seconds.list @@ -204,10 +204,10 @@ # current -- the update time stamp, the data and the name of the file # will not change. # -# Updated through IERS Bulletin C57 -# File expires on: 28 December 2019 +# Updated through IERS Bulletin C58 +# File expires on: 28 June 2020 # -#@ 3786480000 +#@ 3802291200 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 @@ -252,4 +252,4 @@ # the hash line is also ignored in the # computation. # -#h 83c68138 d3650221 07dbbbcd 11fcc859 ced1106a +#h f28827d2 f263b6c3 ec0f19eb a3e0dbf0 97f3fa30

1 0

Re: [tz] [Tzdist-bis] tzdist and IANA
by Paul Eggert July 25, 2019

July 25, 2019

Here are some other thoughts about any potential IANA effort in this area: * As others have mentioned, the effort should address authentication of the timezone data. It would be helpful to have a real authentication expert in on this, since we want something simple and scalable and workable downstream (see below). * Each tzdb release comes with a version number like "2019b", development commits have version numbers like "2019b-11-gd8c6bf2". Downstream publishers often make minor changes to the data, and some append a suffix to the version number to indicate this. The mechanism for publishing this number is specified only loosely in Internet RFC 7808 section 3.10, and presumably the IANA effort would do something more specific. Downstream modifications will complicate data authentication. * Each tzdb release has auxiliary metadata files zone1970.tab and iso3166.tab that contain vague geographical information associated with each tzdb entry. (In some cases this vagueness is intentional, to avoid running into political disputes.) These files are not covered by TZDIST but some POSIX-style clients use them. How should metadata like this be addressed? * Each tzdb release has an auxiliary data file 'leapseconds' that is widely used by clients running NTP and related software. TZDIST has a "leapseconds" action that conveys the information in a different format, and we would need to make sure that this all hooks up correctly. * It'd be helpful to support not only TZDIST, but also a reasonably simple protocol, presumably based on HTTPS transfer of the data since HTTPS is widely supported. This could be used by platforms that don't support TZDIST, or that need auxiliary metadata that is outside the scope of TZDIST. For example, many NTP hosts need a 'leapseconds' file but don't support TZDIST or grok its leap seconds data format.

2 1

[PROPOSED] Mention IANA Updater, tzdbgen, ZIUpdater
by Paul Eggert July 25, 2019

July 25, 2019

* tz-link.html: Add linkjs for IANA Updater, tzdbgen, and ZIUpdater. Mention ‘make reaguard_tarballs’ too. --- tz-link.html | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/tz-link.html b/tz-link.html index 234c04e..a037972 100644 --- a/tz-link.html +++ b/tz-link.html @@ -268,7 +268,8 @@ For further information about updates, please see <a href="https://tools.ietf.org/html/rfc6557">Procedures for Maintaining the Time Zone Database</a> (Internet <abbr title="Request For Comments">RFC</abbr> 6557). More detail can be -found in <a href="theory.html">Theory and pragmatics of the tz code and data</a>. +found in <a href="theory.html">Theory and pragmatics of the +<code><abbr>tz</abbr></code> code and data</a>. <a href="https://a0.github.io/a0-tzmigration/">A0 TimeZone Migration</a> displays changes between recent <code><abbr>tzdb</abbr></code> versions. </p> @@ -361,6 +362,11 @@ title="JavaScript Object Notation">JSON</abbr></a> format.</li> <section> <h2 id="compilers">Other <code><abbr>tz</abbr></code> compilers</h2> +<p>Although some of these do not fully support +<code><abbr>tz</abbr></code> data, in recent <code><abbr>tzdb</abbr></code> +distributions you can generally work around compatibility problems by +running the command <code>make rearguard_tarballs</code> and compiling +from the resulting tarballs instead.</p> <ul> <li><a href="https://sourceforge.net/projects/vzic/">Vzic</a> is a <a href="https://en.wikipedia.org/wiki/C_%28programming_language%29">C</a> @@ -408,7 +414,7 @@ into an <abbr>ICU</abbr>-specific format. <abbr>BSD</abbr>-style license.</li> <li>The <a href="https://github.com/lau/tzdata">Tzdata</a> package for the <a href="https://elixir-lang.org">Elixir</a> language downloads -and compiles tz source and exposes <abbr +and compiles <code><abbr>tz</abbr></code> source and exposes <abbr title="Application Program Interface">API</abbr>s for use. It is freely available under the <abbr>MIT</abbr> license.</li> <li>Java-based compilers and libraries include: @@ -429,6 +435,11 @@ and time <abbr>API</abbr></a> contains a class Java 8 <code>java.time</code>, which its users should migrate to once they can assume Java 8 or later. It is available under the <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License</a>.</li> +<li><a href="https://bell-sw.com/pages/iana-updater/">IANA Updater</a>, +<a href="https://github.com/akashche/tzdbgen">tzdbgen</a>, and <a +href="https://www.azul.com/products/open-source-tools/ziupdater-time-zone-tool/">ZIUpdater</a> +are other alternatives to TZUpdater. IANA Updater's license is unclear; +the others are licensed under the <abbr>GPL</abbr>.</li> <li><a href="https://github.com/MenoData/Time4A">Time4A: Advanced date and time library for Android</a> and <a href="https://github.com/MenoData/Time4J/">Time4J: Advanced date, @@ -1040,7 +1051,8 @@ is called "<abbr>GMT</abbr>".</li> <section> <h2 id="see-also">See also</h2> <ul> -<li><a href="theory.html">Theory and pragmatics of the tz code and data</a></li> +<li><a href="theory.html">Theory and pragmatics of the +<code><abbr>tz</abbr></code> code and data</a></li> <li><a href="tz-art.html">Time and the Arts</a></li> </ul> </section> -- 2.17.1

1 0

probable correction to Europe/Kaliningrad 1945
by Alois Treindl July 25, 2019

July 25, 2019

3 3

error in zone Erope/Vienna 1946
by Alois Treindl July 25, 2019

July 25, 2019

2 1

Error in zone America/Edmonton 1967, no DST
by Alois Treindl July 25, 2019

July 25, 2019

2 2

Error in America/Vancouver for 1946
by Alois Treindl July 25, 2019

July 25, 2019

3 7

Indian Time zone history and choice of Kolkata as reference location
by Alois Treindl July 24, 2019

July 24, 2019

3 3

tzdata2019b failing to be parsed
by Ian Kaebery July 22, 2019

July 22, 2019

Hello, I’m having trouble with the TZUpdater tool. I’m using the latest version to try and update my timezone definitions to either the ‘latest' package, or the ‘2019b' package, retreived from the IANA website. Both are failing on an entry with Japan using a time of 25:00. I’ve read inconsistent comments on the internet stating a number of things - that this was fixed in the 2018 version, or that there is a script you can run to patch the line, or that there’s an unofficial version (rearguard?) available - but since this is for work I’d prefer to use an unmodified and up-to-date (>2018) version directly from IANA’s website. Do you know if there is any official package I can use for the 2019b definitions that would work with the TZUpdater tool? Thanks very much, Ian

4 4

time zone history Nagorno-Karabakh
by Alois Treindl July 21, 2019

July 21, 2019

Nagorno-Karabakh is an 'Armenian enclave' inside Azerbaijan, which seceded from Azerbaijan in the 1990s, and has some kind of unclear status of autonomy since a ceasefire agreement in 1994. See https://en.wikipedia.org/wiki/Nagorno-Karabakh and https://en.wikipedia.org/wiki/Nagorno-Karabakh_Autonomous_Oblast Azerbaijan and Armenia have different time zone rules, represented in TZ by Asia/Baku and Asia/Yerevan. Has anyone researched the time zone and DST rules in Nagorno-Karabakh? If the time zone rules followed locally differ from Azerbaijan, the situation there justifies the creation of a separate TZ zone. The zone exists now since 25 years with rather high political stability.

3 2

Brazil might stick with daylight saving after all
by Paul Eggert July 21, 2019

July 21, 2019

Our reward for pushing out tzdb 2019b to publish Brazil's DST abolition months early, is that Brazilian President Bolsonaro is now threatening to change his mind and not abolish DST after all. On Thursday, Bolsonaro signaled that possibility as follows: “A minha caneta Bic está à disposição de vocês, qualquer decreto pode ser modificado. A gente entra em contato com a assessoria de assuntos jurídicos e estuda. Se for o caso, a gente altera o decreto para atender o bem-estar da população, sem extrapolar os limites da lei.” Google Translate renders this as: “My Bic pen is at your disposal, any decree can be modified. We get in touch with legal counsel and study. If this is the case, we amend the decree to meet the welfare of the population, without extrapolating the limits of the law.” Reference: Ernesto M. Bolsonaro sinaliza que pode voltar com horário de verão. Correio Braziliense. 2019-07-18. https://www.correiobraziliense.com.br/app/noticia/politica/2019/07/18/inter…

1 0

Dubious coding in tzcode 2019b
by Tom Lane July 20, 2019

July 20, 2019

Some compilers in the Postgres buildfarm are unhappy[1] about this coding in 2019b's zic.c: register ptrdiff_t thistimei, thistimecnt, thistimelim; bool locut, hicut; ... thistimecnt = - locut - hicut; I think they have a point: at best this code is seriously opaque, and at worst it's unportable. I can't even figure out whether this is assuming that bool promotes to signed or unsigned int; and even if whichever choice that is supported by the C99 spec, what will happen in environments where "bool" does not mean the C99 type, but rather signed or unsigned char? (For my immediate purposes, that includes every released branch of Postgres :-(.) I think this would be a lot better if it were written as some if-tests that just consider locut and hicut as boolean values, without any assumptions about how bool converts to integer. If we must have such assumptions, please write them as explicit casts. While the compilers aren't whining about it, this line a bit further down seems like equally bad style to me: convert(locut + thistimecnt + hicut, tzh.tzh_timecnt); This also seems like it's making dubious assumptions about how signed and possibly-unsigned values will mix. regards, tom lane [1] https://www.postgresql.org/message-id/20190719035347.GJ1859@paquier.xyz

4 5

[PROPOSED] HKWT observed in late 1941 in Hong Kong
by Paul Eggert July 12, 2019

July 12, 2019

* NEWS: Mention this. * asia (Asia/Hong_Kong): Treat the period from 1941-10-01 to 1941-12-25 as 30-minute DST rather than as standard time. * theory.html (Time zone abbreviations): Add HKWT. --- NEWS | 5 +++++ asia | 19 ++++++++++++++----- theory.html | 2 +- 3 files changed, 20 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 65c67a2..e2ebe32 100644 --- a/NEWS +++ b/NEWS @@ -12,6 +12,11 @@ Unreleased, experimental changes Fix several errors in pre-1970 transitions in Perry County, IN. (Thanks to Alois Triendl for pointing out the 1967/9 errors.) + Changes to past time zone abbreviations and DST flags + + Hong Kong Winter Time, observed from 1941-10-01 to 1941-12-25, + is now flagged as DST and is abbreviated HKWT not HKT. + Changes to commentary Nashville's newspapers dueled about the time of day in the 1950s. diff --git a/asia b/asia index 348e2b5..47a0b25 100644 --- a/asia +++ b/asia @@ -8,7 +8,7 @@ # tz(a)iana.org for general use in the future). For more, please see # the file CONTRIBUTING in the tz distribution. -# From Paul Eggert (2018-06-19): +# From Paul Eggert (2019-07-11): # # Unless otherwise specified, the source for data through 1990 is: # Thomas G. Shanks and Rique Pottenger, The International Atlas (6th edition), @@ -47,13 +47,13 @@ # 7:00 WIB west Indonesia (Waktu Indonesia Barat) # 8:00 WITA central Indonesia (Waktu Indonesia Tengah) # 8:00 CST China -# 8:00 PST PDT* Philippine Standard Time +# 8:00 HKT HKST Hong Kong (HKWT* for Winter Time in late 1941) +# 8:00 PST PDT* Philippines # 8:30 KST KDT Korea when at +0830 # 9:00 WIT east Indonesia (Waktu Indonesia Timur) # 9:00 JST JDT Japan # 9:00 KST KDT Korea when at +09 -# 9:30 ACST Australian Central Standard Time -# *I invented the abbreviation PDT; see "Philippines" below. +# *I invented the abbreviations HKWT and PDT; see below. # Otherwise, these tables typically use numeric abbreviations like +03 # and +0330 for integer hour and minute UT offsets. Although earlier # editions invented alphabetic time zone abbreviations for every @@ -653,6 +653,15 @@ Zone Asia/Urumqi 5:50:20 - LMT 1928 # * 1941-09-30, Hong Kong Daily Press, Winter Time Warning. # https://i.imgur.com/dge4kFJ.png +# From Paul Eggert (2019-07-11): +# "Hong Kong winter time" is considered to be daylight saving. +# "Hong Kong had adopted daylight saving on June 15 as a wartime measure, +# clocks moving forward one hour until October 1, when they would be put back +# by just half an hour for 'Hong Kong Winter time', so that daylight saving +# operated year round." -- Low Z. The longest day: when wartime Hong Kong +# introduced daylight saving. South China Morning Post. 2019-06-28. +# https://www.scmp.com/magazines/post-magazine/short-reads/article/3016281/lo… + # From P Chan (2018-12-31): # * According to the Hong Kong Daylight-Saving Regulations, 1941, the # 1941 spring-forward transition was at 03:00. @@ -754,7 +763,7 @@ Rule HK 1979 only - Oct 21 3:30 0 - Zone Asia/Hong_Kong 7:36:42 - LMT 1904 Oct 30 0:36:42 8:00 - HKT 1941 Jun 15 3:00 8:00 1:00 HKST 1941 Oct 1 4:00 - 8:30 - HKT 1941 Dec 25 + 8:00 0:30 HKWT 1941 Dec 25 9:00 - JST 1945 Nov 18 2:00 8:00 HK HK%sT diff --git a/theory.html b/theory.html index e0b3233..1e7df4a 100644 --- a/theory.html +++ b/theory.html @@ -428,7 +428,7 @@ in decreasing order of importance: EET/EEST Eastern European, GST/GDT Guam, HST/HDT/HWT/HPT Hawaii, - HKT/HKST Hong Kong, + HKT/HKST/HKWT Hong Kong, IST India, IST/GMT Irish, IST/IDT/IDDT Israel, -- 2.17.1

1 0

Re: [tz] zone America/Indiana/Tell_city 1967 - 1969
by Paul Eggert July 11, 2019

July 11, 2019

Michael H Deckers wrote: > -Rule Perry 1960 only - Oct lastSun 2:00 0 S Thanks for catching that typo; I installed the attached.

1 0

USNO steps gingerly into the daylight saving mess
by Paul Eggert July 10, 2019

July 10, 2019

Last month the US Naval Observatory's Astronomical Applications Department published a web page that displays daylight saving starting and ending dates for US rules since 1967. A web page lets you enter a year like 1967 and the response will tell you start and end dates for that year. There is also an API that returns the data in a JSON format. Only US federal rules are supported, and only years from 1967 through 9999. See: https://aa.usno.navy.mil/data/docs/daylight_time.php

1 0

zone America/Indiana/Tell_city 1967 - 1969
by Alois Treindl July 10, 2019

July 10, 2019

I am afraid I have to challenge the entry Zone America/Indiana/Tell_City -5:47:03 - LMT 1883 Nov 18 12:12:57 -6:00 US C%sT 1946 -6:00 Perry C%sT 1964 Apr 26 2:00 -5:00 - EST 1969 -5:00 US E%sT 1971 -5:00 - EST 2006 Apr 2 2:00 -6:00 US C%sT It conflicts with Shanks for 1967-169, and therefore I checked newspaper archives. The Indianapolis News, Friday 27 October 1967 states that Perry County returned to CST. It went again to EST on 27 April 1969, as documented by the Indianapolis star of Saturday 26 April. (second screenshot attached)

2 1

VTIMEZONEs and Outlook
by Ken Murchison July 10, 2019

July 10, 2019

All, Sorry for the off-topic post, but I'm fishing. I'm one of the maintainers of vzic, a utility to convert IANA tzdata into iCalendar VTIMEZONE components. In the process of tweaking the tool to handle recent tzdata changes and to generate more correct/compact VTIMEZONEs in "pure" mode, I managed to break the generation of Outlook-compatible VTIMEZONEs. Does anyone know what parts of the iCalendar/VTIMEZONE spec that Outlook doesn't properly handle and/or know what the requirements are to be compatible with Outlook? -- Ken Murchison Cyrus Development Team Fastmail US LLC

4 4

Blocked USNO sites was: Updated Public Domain leapseconds.list
by Chris Woodbury July 8, 2019

July 8, 2019

>On Mon Jul 8 11:16:42 UTC 2019,Tony Finch dot at dotat.at wrote: > >The main problem that I can see is 3 out of the 7 navy.mil DNS servers say >that usno.navy.mil does not exist, so it's a matter of luck whether you'll >be able to contact it or not. > >Tony. Great detective work, Tony! After a little "digging" of my own, I discovered it's even worse than that. There are no public facing "authoritative" DNS servers for Navy.MIL (or USNO.Navy.MIL as all of them are unreachable). The Navy.MIL DNS servers have *no authoritative data* for USNO; they all appear to be caching secondary servers. The give away is that the TTLs decrements between "dig" runs. (Possibly "slit horizon" DNS servers that internally referencing their other half. There's no way to tell from this side.) This also means that the primary server listed in the SOA is not the real primary. There must be hidden primary and secondary DNS server somewhere as the servers we can actually see have cached RR (resource records). Someone hasn't thought out all of the implications of what they're doing. When I was looking, only two of seven Navy.MIL DNS servers returning NXDOMAIN for USNO.Navy.MIL. These were ns1.csd.disa.mil, the purported Navy.MIL primary DNS server (with no authoritative SOA RR) and updciftr01.csd.disa.mil. I could not reach *any* of the USNO.Navy.MIL DNS servers, period (The Naval Oceanographic Portal. (NoP) is up as I was able to FTP to Tycho and MAIA. I'm going to have to add Psyche.USNO.Navy.MIL to my /etc/hosts it seems (when I can figure out its IP address)). I must agree that a guaranteed 28% failure rate for USNO.Navy.MIL DNS lookups is unacceptable. The USNO SOA points to hostmaster(a)usno.navy.mil and none of the hosts in that MX RR are reachable. Does anyone have the 'phone number of a responsible person at USNO proper? The Petty Officer who answered the 'phone at the main number was less than helpful... (I hesitate to call Jeff Prillaman about this issue.)

1 0

Blocked USNO sites was: Updated Public Domain leapseconds.list
by Chris Woodbury July 8, 2019

July 8, 2019

Brian et al, DoD sites are subject to frequent attack from the Internet. One of their defense strategies is to "go turtle"". Sometimes they're not there at all but, more often, they isolate just portion of their "space". (TRACERT ends in never-neverland.) I have discovered that, when this happens, the Navy.Mil and USNO.Navy.Mil DNS servers are often not reachable. As a result, while USNO sites are actually available though the Naval Oceanographic Portal (NoP) (point of presence (PoP) in Portsmouth, VA), their DNS entries are not. I, personally, solved part of this problem by adding the USNO sites I use to /etc/host (or its Windows equivalent, %WINDIR%\System32\drivers\etc\hosts). These are: 199.211.133.23 maia.usno.navy.mil 199.211.133.93 aa.usno.navy.mil 199.211.133.239 tycho.usno.navy.mil # Charon is a USNO.Navy.Mil DNS server on the NOP 199.211.133.5 charon.usno.navy.mil charon.nofs.navy.mil 192.68.148.66 charon.nofs.navy.mil 192.68.148.80 toshi.nofs.navy.mil MAIA also has backup servers for their data at NASA Goldstone Space Flight Center (cddis.gsfc.nasa.gov) and, as Brian mentioned, toshi.nofs.navy.mil. (At this instant, MAIA and Toshi are unavailable via HTTP but FTP is just fine (with /etc/host entries). If one is running a local DNS server, adding a pointer to USNO.Navy.Mil with a Charon.USNO.Navy.Mil NS RR might help the cause... Since I've done these things (particularly the /etc/hosts entries), I rarely have problems reaching USNO sites. Also, sometimes, DoD restrict themselves to Secure DNS. As I've got (some of) the certificate information installed, I may not have problems where others might. Lastly, occasionally I can't reach MAIA via HTTP but FTP works just fine. (I've just change my references to ser7.dat to FTP for that reason.) (Pardon my edits to the following. No words were removed...) > On Sat Jul 6 16:12:26 UTC 2019, Brian Inglis Brian.Inglis at SystematicSw.ab.ca wrote: >>On 2019-07-05 15:55, Chris Woodbury via tz wrote: >> # 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> >> ... >> # See: http://maia.usno.navy.mil/ser7/ser7.txt > > Seems to be some DNS resolver and network blocking, possibly only > outside the US, to maia.usno.navy.mil ; interactive web browser access > and Naval Oceanography Portal to tycho.usno.navy.mil and aa.usno.navy.mil > mostly work, but web browser ftp access does not, and non web browser > resolution and access do not, e.g. host or wget; however everything resolves > and is accessible form the browser and command line from toshi.nofs.navy.mil. > Some other previous reports back this up, but there were no followups to say > whether issues were temporary and cleared up, or persisted and were permanent. > > It may be possible that lookups or accesses may be rate limited to deter > intrusions, or entries may have expired because they may be offline for July 4 > thru the weekend, or sites may be blocked due to lack of monitoring staff or > funding for non-defense services.

3 3

Re: [tz] DST in Detroit 1967
by Paul Eggert July 7, 2019

July 7, 2019

Alois Treindl wrote: > So whether it was DST or not, at the time given in the article light cannot have > started to fail That depends on what the article's author Bill Dow meant by "fail". In a burning city, light could "fail" well before astronomical sunset. > You say in your comment that you have seen "multiple reports that (Shanks DST > data) is incorrect." > > I am curious what those other reports might be. Sorry, I don't remember the details. As I vaguely recall, the situation in Michigan was chaotic. The state rebelled against the federal daylight-saving law, some counties rebelled against the state, cases went to the state supreme court which may have (temporarily?) suspended the state's suspension of DST, and I don't know of any reliable catalog of what actually happened that year in Detroit. Perhaps someone could spring the money and read all the stories in the Detroit Free Press and Detroit News archives related to daylight saving time that year. I expect there would be dozens of stories to wade through. Let's hope the competing newspapers in Detroit didn't follow the model of Nashville in the previous decade. That Nashville story is so entertaining that it should be promoted from our email archive to the northamerica comments. Proposed patch attached.

1 1

Blocked USNO sites was: Updated Public Domain leapseconds.list
by Chris Woodbury July 6, 2019

July 6, 2019

For reasons I can not fathom, I did not check on all the links in the leap-seconds.list I just submitted to the list. As a result, I failed to notice that the link to IERS Bulletin A was incorrect. The proper link is: # <ftp://maia.usno.navy.mil/ser7/ser7.dat> ^^^ Also available via HTTP. Note: the FTP and HTTP versions *have different timestamps* (and therefore are most likely separate files in different file structures). Otherwise, the files are identical. (This is why I've got alias cp='cp --preserve=timestamps' in my run commands....) Also, I managed to include a dot (.) at the end of a link in my first Bulletin C number 58 message. The proper URL for the directory in which to find the IERS leap-seconds.list file is: <ftp://hpiers.obspm.fr/iers/bul/bulc/ntp/> "leap-seconds.list" is a symbolic link. Its "real" name is "leap-seconds.3771235866" (4 Jul 2019 15:31:06 CEST) One may also use HTTP or HTTPS protocols to get there. Sorry about that.

1 0

Updated Public Domain leapseconds.list
by Chris Woodbury July 6, 2019

July 6, 2019

# -=*( 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 58 (4 Jul 2019) # Found at <ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat> # # Bulletin C 58 did not announce a new leap-second. # The last leap-second occurred on 1 Jan 2017 (3692217600). # # -=<*>=- # # This file is not produced by a national metrology laboratory. # It *is* created using data from one: # # United States Naval Observatory (USNO) # IERS Rapid Service/Prediction Center for Earth Orientation # 3450 Massachusetts Ave NW, Washington, DC 20392 # # It should be noted that anyone with proper information can # generate an NTP leap-seconds.list file. # # This file's generation was originally necessitated by a U.S. # government shutdown and the resulting lack of an NIST or USNO # generated file until late in January 2019. # # -=<*>=- # # The Network Time Protocol (NTP) keeps time in Coordinated # Universal Time (UTC). UTC is a time scale based upon # Standard International (SI) seconds and derived from Temps # Atomique International (TAI). UTC is the basis for legal # time since 1 Jan 1972 0h. # # [Le] Bureau International des Poids et Mesures (BIPM) tracks # TAI, UT1, TE and UTC uses a weighted ensemble of 420+ atomic # clocks at over 80+ national metrology laboratories worldwide # to track time and Very-Long-Baseline Interferometry (VLBI) # for precision millisecond pulsars timing and to track Earth's # orientation in space. The origin of TAI has been agreed # officially to coincide with UT1 on 1 January 1958 0h. # # For further information, read BIPM monograph "Time Scales" # found at: # # <https://www.bipm.org/... # utils/common/pdf/monographies-misc/Monographie1994-1.pdf> # # And "Coordinated Universal Time" at: # # <https://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-32_noteUTC.pdf> # # And, lastly: # # "Atomic Time Scales for Dynamical Astronomy" pp.51-56 # # "How Can Millisecond Pulsars Improve the Long-Term Stability # of Atomic Time Scales?", pp.57-60: # # Proceedings of the 6th European Frequency and Time Forum # (17-19 March 1992) # # <http://www.eftf.org/proceedings/proceedingsEFTF1992.pdf> # # -=<*>=- # # 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 (and the # basis of legal time until 1972). IERS Bulletin A keeps # track of and predicts the value of UT1-UTC. # # See: http://maia.usno.navy.mil/ser7/ser7.txt # # The 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 0h 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-Recommendation (ITU-R) # 460-6 (Standard-frequency and Time-Signal Emissions), # Annex 1 (Time scales), Section 2 (Leap-Seconds). # # Note: Version 460-6 of the Recommendation is incorporated # by reference in the [ITU] Radio Regulations. # # <http://www.itu.int/rec/R-REC-TF.460-6-200202-I/> # # Section 2.3: Delegates leap-second timing/dissemination to the # International Earth Rotation and Reference System Service (IERS), # (in its role as inheritor of Bureau International de l'Heure (BIH)). # # 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. [I am of the opinion] it should be updated whenever # a new IERS Bulletin C is issued. CCW] # #$ 3771187200 # # 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 (#@). # # File expires on: 28 Jun 2020 # #@ 3802291200 # # 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 # ignored 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. # # Additionally, there may be an "#SHA256" digest record. If # present, it is a FIPS-180 SHA256 digest that includes the # same records as "#h" plus the comment Day, Month and Year # included in each NTP leap-second record (thus making it # possible to *verify* those comments as well as the file time- # stamps, and NTP leap-second data. # # NTP delta #timestamp T 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) # #SHA256: 128f9463dc3828a1c7a611a4017bc311aabdfbe4c33fd8278a63bed7ef3ba0e2 #h bca6f457 5f358e20 a63e0aab a79ad3c3 c0a21083

3 3

Bulletin C number 58
by Chris Woodbury July 6, 2019

July 6, 2019

Christian Bizouard has struck again (and exactly a week earlier than I was expecting). No new leap-second. I predict (after a careful perusal of Bulletin A) that we will see one in July 2020. i.e.: 3802550400 38 # 1 Jul 2020 There is a new, IERS leap-seconds.3771235866 file at https://hpiers.obspm.fr/iers/bul/bulc/ntp. Dr. Levine and Jeff Prillaman will no doubt shortly generate NIST and USNO versions respectively. (Today is a federal holiday in the US.) For those who can't wait, I have attached another leap-seconds.list file, Eggert_leap-seconds.3771187200, which has a FIPS style SHA-256 digest that includes the erstwhile day, month and year from the comments. Happy (U.S.) Independence Day !!

2 1