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. 23, 2019

Aug. 23, 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 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

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