- tz - lists.iana.org

Call for evidence on UK adoption of EU summer time abolition
by Joseph Myers Aug. 5, 2019

Aug. 5, 2019

The House of Lords EU Internal Market Sub-Committee has published a call for written evidence on UK adoption of EU abolition of seasonal time changes. https://www.parliament.uk/business/committees/committees-a-z/lords-select/e… https://www.parliament.uk/documents/lords-committees/eu-internal-market-sub… -- Joseph S. Myers jsm(a)polyomino.org.uk

2 1

Fwd: Bulletin C number 58
by Chris Woodbury July 29, 2019

July 29, 2019

On Sat Jul 27 14:21:34 UTC 2019, Paul Eggert <eggert at cs.ucla.edu> wrote: >Thanks, I installed that into the development version on GitHub. > >I see that the updated file has a space at the end of the '#@ 3802291200' line >that encodes the expiration (2020-06-28 00:00:00 UTC). I assume this was >inadvertent. It doesn't break tzcode (which ignores that line), but the format >of the line is not documented anywhere that I can see. I dropped Judah Levine a >line about this. > Back in the dark ages, when I first started writing C code, it was said that the ultimate documentations was the code. In the NTP daemon, there is a subroutine leapsec_load() in which is the following: while (get_line(func, farg, linebuf, sizeof(linebuf))) { cp = linebuf; if (*cp == '#') { cp++; if (*cp == '@') { cp = skipws(cp+1); pt->head.expire = strtouv64(cp, &ep, 10); ... strtouv64() is an NTP native subroutine (found in libntp/vint64ops.c) which reads numeric data in a specified base (in this case 10). It skips "whitespace" (so the call to skipws() is superfluous), and then converts the digits, one at a time, to numeric in that base. It quits conversion when whatever it's pointing at isn't a digit in the selected base and returns the number and "ep", a pointer to where it stopped parsing. This allows for comments and/or additional data. So, a space instead of a line terminator or say, a comment such as "\t# 28 Jun 2020", after the expiration NTP timestamp is an acceptable field termination. Anyone who cares to can reference the "standard" implementation of the NTP code found at: <http://www.ntp.org/downloads.html> The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server...

6 6

CRLF terminated leap-seconds.list fix
by Chris Woodbury July 29, 2019

July 29, 2019

NIST has yet again generated a leap-seconds.list file with CRLF line terminations. If the file is transferred in FTP binary mode and used, it breaks leapseconds.awk. Using int( ) around the last column variable eliminates this problem. Therefore, I propose the attached patch.

3 3

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