July 2019 - tz - lists.iana.org

Italy April 1944 discrepancy between comment and data
by Alois Treindl Oct. 5, 2021

Oct. 5, 2021

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

proposed time zone package changes (Samoa, Factory, et al.)
by Arthur David Olson Aug. 28, 2019

Aug. 28, 2019

Below find proposed time zone package changes; the executive summary: * Makefile Change LOCALTIME default from "Factory" to "GMT"; do not compile "factory" file (but keep it in the distribution). * Theory Remove reference to "Factory" zone. * australasia Change end of DST in Samoa in 2011 from 2011-04-03 0:00 to 2011-04-03 1:00 (thanks to Raymond Hughes for a reference). * localtime.c Initialize ttinfo structures filled by tzparse (thanks to Ravindra for reporting a valgrind warning). * zic.c Fix generation of POSIX strings for zones with rules using "weekday<=n" forms of dates (thanks to Lei Liu for finding the problem). Also, limit output for non-POSIX-specificable zones defined to follow the same rules every year. (Note that no zones of either of the above types appear in the distribution; these changes cater to add-on zones). If no problems are found, 2010n will appear on 2010-10-25. --ado diff -r -c old/Makefile new/Makefile *** old/Makefile Mon Sep 27 09:24:25 2010 --- new/Makefile Tue Oct 12 12:36:50 2010 *************** *** 1,5 **** # <pre> ! # @(#)Makefile 8.8 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)Makefile 8.9 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 12,18 **** # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= Factory # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, --- 12,18 ---- # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= GMT # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, *************** *** 262,269 **** DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera factory backward ! NDATA= systemv SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab --- 262,269 ---- DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward ! NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab diff -r -c old/Theory new/Theory *** old/Theory Mon Sep 27 09:24:25 2010 --- new/Theory Tue Oct 12 12:36:50 2010 *************** *** 1,4 **** ! @(#)Theory 8.4 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. --- 1,4 ---- ! @(#)Theory 8.5 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. *************** *** 287,294 **** See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', `EET' (see the file `europe'), ! and `Factory' (see the file `factory'). ----- Time zone abbreviations ----- --- 287,293 ---- See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', and `EET' (see the file `europe'). ----- Time zone abbreviations ----- diff -r -c old/australasia new/australasia *** old/australasia Mon Sep 27 09:24:27 2010 --- new/australasia Tue Oct 12 13:14:56 2010 *************** *** 1,5 **** # <pre> ! # @(#)australasia 8.18 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)australasia 8.19 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 487,497 **** # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 -11:00 - WST # Solomon Is --- 487,507 ---- # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> + # From Raymond Hughes (2010-10-07): + # Please see + # <a href="http://www.mcil.gov.ws"> + # http://www.mcil.gov.ws + # </a>, + # the Ministry of Commerce, Industry and Labour (sideframe) "Last Sunday + # September 2010 (26/09/10) - adjust clocks forward from 12:00 midnight + # to 01:00am and First Sunday April 2011 (03/04/11) - adjust clocks + # backwards from 1:00am to 12:00am" + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 1:00 -11:00 - WST # Solomon Is diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Mon Sep 27 09:24:26 2010 --- new/localtime.c Tue Oct 12 12:36:51 2010 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.14"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.15"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 914,919 **** --- 914,920 ---- register unsigned char * typep; register char * cp; register int load_result; + static struct ttinfo zttinfo; INITIALIZE(dstname); stdname = name; *************** *** 986,991 **** --- 987,993 ---- /* ** Two transitions per year, from EPOCH_YEAR forward. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -dstoffset; sp->ttis[0].tt_isdst = 1; sp->ttis[0].tt_abbrind = stdlen + 1; *************** *** 1099,1106 **** } /* ** Finally, fill in ttis. - ** ttisstd and ttisgmt need not be handled. */ sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; --- 1101,1108 ---- } /* ** Finally, fill in ttis. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; *************** *** 1113,1118 **** --- 1115,1121 ---- dstlen = 0; sp->typecnt = 1; /* only standard time */ sp->timecnt = 0; + sp->ttis[0] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_abbrind = 0; diff -r -c old/zic.c new/zic.c *** old/zic.c Mon Sep 27 09:24:26 2010 --- new/zic.c Tue Oct 12 13:37:29 2010 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.22"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.24"; #include "private.h" #include "locale.h" *************** *** 1881,1896 **** register int week; if (rp->r_dycode == DC_DOWGEQ) { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", --- 1881,1896 ---- register int week; if (rp->r_dycode == DC_DOWGEQ) { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) return -1; + week = 1 + rp->r_dayofmonth / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) return -1; + week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", *************** *** 2018,2023 **** --- 2018,2024 ---- register char * envvar; register int max_abbr_len; register int max_envvar_len; + register int prodstic; /* all rules are min to max */ max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; *************** *** 2032,2037 **** --- 2033,2039 ---- timecnt = 0; typecnt = 0; charcnt = 0; + prodstic = zonecount == 1; /* ** Thanks to Earl Chew ** for noting the need to unconditionally initialize startttisstd. *************** *** 2053,2058 **** --- 2055,2062 ---- updateminmax(rp->r_loyear); if (rp->r_hiwasnum) updateminmax(rp->r_hiyear); + if (rp->r_lowasnum || rp->r_hiwasnum) + prodstic = FALSE; } } /* *************** *** 2075,2080 **** --- 2079,2094 ---- if (max_year <= INT_MAX - YEARSPERREPEAT) max_year += YEARSPERREPEAT; else max_year = INT_MAX; + /* + ** Regardless of any of the above, + ** for a "proDSTic" zone which specifies that its rules + ** always have and always will be in effect, + ** we only need one cycle to define the zone. + */ + if (prodstic) { + min_year = 1900; + max_year = min_year + YEARSPERREPEAT; + } } /* ** For the benefit of older systems,

5 6

Re: [tz] [Tzdist-bis] [calsify] tzdist and IANA
by Daniel Migault Aug. 22, 2019

Aug. 22, 2019

adding the tz mailing in the discussion Yours, Daniel On Thu, Jul 18, 2019 at 5:41 AM Martin Burnicki < martin.burnicki(a)burnicki.net> wrote: > Eliot Lear wrote: > > > >> On 18 Jul 2019, at 10:29, Martin Burnicki <martin.burnicki(a)burnicki.net> > wrote: > >> > >> Hi all, > >> > >> Eliot Lear wrote: > >>> Hi everyone, > >>> > >>> While the IANA does a great job at servicing our assigned number needs > >>> and delivering the TZ database to developers, they is not set up, nor > do > >>> they have *any* experience, to handle the load that end clients could > >>> place on them. Moreover, they are in no position to support millions > of > >>> people if something goes wrong. And make no mistake: something will go > >>> wrong. I would be okay with a limited tzdist service for those who are > >>> going to be distributing the data themselves, but the order of > receivers > >>> should be on 100s not millions. > >> > >> Wouldn't it be nice to have an infrastructure similar to what the NTP > >> pool provides for time synchronization? > > > > > > I guess I would want to see commitment from those who provide TZ service > to their customers today to go to such a new service before investing a lot > of money. Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the > others want to use it? I also realize that ICANN is well positioned to > fund this sort of thing, but it is not clear to me that it is right for > them to do so. There has to be a real need, and those who really need it > perhaps should foot the bill. > > > > I'm working at Meinberg > https://www.meinbergglobal.com/ > > and we are manufacturing NTP/PTP servers, beside related time > synchronization stuff. > > In the past, whenever governments as of Egypt, Morocco, etc. decided to > start or end DST just a couple of days before this really happens we get > support requests from industries, telecommunication companies, etc., > asking if our time servers could fix the problem to update the TZ data > quickly enough. > > We always have to tell them they need to wait until a new TZ DB has been > released, and then hope that their OS maintainers (Microsoft, Apple, > Linux distros, etc.) pick up the new TZ DB version and provide a > software/firmware update just to provide the latest changes quickly. > > Providing these updates also requires quite some effort for the > maintainers, and it would be much easier for them if this kind of > information could be updated automatically, which should also be faster > than with manual intervention required. > > TZ data must not be requested from a server as often as the current > time, so I think that even if the data size is larger than an NTP packet > the overall load compared to NTP will not be much higher than for a > server that provides NTP services, and if I remember correctly then data > only needs to be transferred if changes have become available. > > So I think this type of service and its advantages just need to be made > more public, to let the OS maintainers learn that they have less work > with rolling out and deploying software updates if they just use TZDIST. > > I'd expect that a TZDIST pool could be operated by volunteers, just like > the NTP pool. > > Martin > > _______________________________________________ > Tzdist-bis mailing list > Tzdist-bis(a)ietf.org > https://www.ietf.org/mailman/listinfo/tzdist-bis >

14 20

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 28, 2019

July 28, 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