November 2016 - tz - lists.iana.org

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

Syntax highlighting for Sublime Text
by Gilmore Davidson Aug. 16, 2017

Aug. 16, 2017

Hi, I’ve created some tzdata syntax highlighting rules for the Sublime Text editor: https://packagecontrol.io/packages/zoneinfo <https://packagecontrol.io/packages/zoneinfo> I have no idea if anyone other than me uses that particular text editor for looking at tzdata files. But I thought I’d mention it just in case it’s useful to someone. Cheers, Gil

3 3

Re: [tz] Version in zoneinfo files?
by Guy Harris Feb. 10, 2017

Feb. 10, 2017

On Oct 25, 2015, at 10:55 AM, Paul G <paul(a)ganssle.io> wrote: > I'm not suggesting that it be impossible to create a weird result when asking for the version, just that there's a standard place for the version to go, and preferably the standard default gives you something that you expected. I.e., something that works most of the time is sufficient? So what exactly is the intended use of this version field? > As it is now, you're virtually guaranteed to have a lot of incompatibility because there's nothing you can point to that says, "This is the canonical way to store version information about zoneinfo files", and no standard has emerged on how to do this as is. > > On 10/25/2015 01:51 PM, Guy Harris wrote: >> >> On Oct 25, 2015, at 10:37 AM, Paul G <paul(a)ganssle.io> wrote: >> >>> On 10/25/2015 01:35 PM, Guy Harris wrote: >>> >>>> So where would zic get the version information to put into the binary files? >>> >>> My understanding is that it's the VERSION= line of the Makefile in the tzdata tarballs. >> >> I.e., you're proposing that the value of the VERSION value in the Makefile be passed as an argument to zic, and zic would put the value of that argument into a field in the files? >> >> So, if the goal is to provide a "reliable way to get the version information in a cross-platform way", what would ensure that this field be set properly, for some value of "properly", everywhere that binary tzdata files are generated? >> >> I.e., what is to guarantee that >> >> 1) nobody downstream change VERSION if they aren't changing the zic files from what's distributed >> >> and >> >> 2) people change it "properly" if the files don't correspond to a particular version of files that were distributed (e.g., if some downstream supplier takes 2015q and adds some changes mentioned on the list to it before 2015r comes out with those changes plus other changes, they should call the resulting files something other than "2015q" or "2015r")? >> >

20 55

Proposal: validation text file with releases
by Jon Skeet Dec. 19, 2016

Dec. 19, 2016

Background: I'm the primary developer for Noda Time <http://nodatime.org> which consumes the tz data. I'm currently refactoring the code to do this... and I've come across some code (originally ported from Joda Time) which I now understand in terms of what it's doing, but not exactly why. For a little while now, the Noda Time source repo has included a text dump file <https://github.com/nodatime/nodatime/blob/master/src/NodaTime.Test/TestData…>, containing a text dump of every transition (up to 2100, at the moment) for every time zone. It looks like this, picking just one example: Zone: Africa/Maseru LMT: [StartOfTime, 1892-02-07T22:08:00Z) +01:52 (+00) SAST: [1892-02-07T22:08:00Z, 1903-02-28T22:30:00Z) +01:30 (+00) SAST: [1903-02-28T22:30:00Z, 1942-09-20T00:00:00Z) +02 (+00) SAST: [1942-09-20T00:00:00Z, 1943-03-20T23:00:00Z) +03 (+01) SAST: [1943-03-20T23:00:00Z, 1943-09-19T00:00:00Z) +02 (+00) SAST: [1943-09-19T00:00:00Z, 1944-03-18T23:00:00Z) +03 (+01) SAST: [1944-03-18T23:00:00Z, EndOfTime) +02 (+00) I use this file for confidence when refactoring my time zone handling code - if the new code comes up with the same set of transitions as the old code, it's probably okay. (This is just one line of defence, of course - there are unit tests, though not as many as I'd like.) It strikes me that having a similar file (I'm not wedded to the format, but it should have all the same information, one way or another) released alongside the main data files would be really handy for *all* implementors - it would be a good way of validating consistency across multiple platforms, with the release data being canonical. For any platforms which didn't want to actually consume the rules as rules, but just wanted a list of transitions, it could even effectively replace their use of the data. One other benefit: diffing the dump between two releases would make it clear what had changed in *effect*, rather than just in terms of rules. One sticking point is size. The current file for Noda Time is about 4MB, although it zips down to about 300K. Some thoughts around this: - We wouldn't need to distribute it in the same file as the data - just as we have data and code file, there could be a "textdump" file or whatever we'd want to call it. These could be retroactively generated for previous releases, too. - As you can see, there's redundancy in the format above, in that it's a list of "zone intervals" (as I call them in Noda Time) rather than a list of transitions - the end of each interval is always the start of the next interval. - For zones which settle into an infinite daylight saving pattern, I currently generate from the start of time to 2100 (and then a single zone interval for the end of time as Noda Time understands it; we'd need to work out what form that would take, if any). If we decided that "year of release + 30 years" was enough, that would cut down the size considerably. Any thoughts? If the feeling is broadly positive, the next step would be to nail down the text format, then find a willing victim/volunteer to write the C code. (You really don't want me writing C...) Jon

18 92

[PROPOSED] New zone Asia/Atyrau
by Paul Eggert Dec. 6, 2016

Dec. 6, 2016

(Thanks to Stepan Golosunov.) * NEWS: Document this. * asia, zone.tab, zone1970.tab (Asia/Atyrau): New zone. In comments, prefer what I assume to be Library of Congress romanization for place names in Kazakhstan. * asia (Asia/Aqtau): Omit now-redundant transition. --- NEWS | 6 ++++ asia | 91 +++++++++++++++++++++++++++++++++++------------------------- zone.tab | 3 +- zone1970.tab | 5 ++-- 4 files changed, 64 insertions(+), 41 deletions(-) diff --git a/NEWS b/NEWS index d5f7217..24faeaf 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,12 @@ News for the tz database Unreleased, experimental changes + Changes to past time stamps + + The new zone Asia/Atyrau for Atyraū Region, Kazakhstan, is like + Asia/Aqtau except it switched from +04/+05 to +05/+06 in spring + 1999, not fall 1994. (Thanks to Stepan Golosunov.) + Changes to past time zone abbreviations Asia/Gaza and Asia/Hebron now use "EEST", not "EET", to denote diff --git a/asia b/asia index bb7534a..c6f63b5 100644 --- a/asia +++ b/asia @@ -1583,12 +1583,12 @@ Zone Asia/Amman 2:23:44 - LMT 1931 # was "blended" with the Central zone. Therefore, Kazakhstan now has # two time zones, and difference between them is one hour. The zone # closer to UTC is the former Western zone (probably still called the -# same), encompassing four provinces in the west: Aqtobe, Atyrau, -# Mangghystau, and West Kazakhstan. The other zone encompasses +# same), encompassing four provinces in the west: Aqtöbe, Atyraū, +# Mangghystaū, and West Kazakhstan. The other zone encompasses # everything else.... I guess that would make Kazakhstan time zones # de jure UTC+5 and UTC+6 respectively. -# From Stepan Golosunov (2016-03-27) ([*] means see later comments below): +# From Stepan Golosunov (2016-03-27): # Review of the linked documents from http://adilet.zan.kz/ # produced the following data for post-1991 Kazakhstan: # @@ -1634,7 +1634,7 @@ Zone Asia/Amman 2:23:44 - LMT 1931 # # This implies that on 1991-03-31 Asia/Oral remained on +04/+05 while # the rest of Kazakhstan switched from +06/+07 to +05/06 or from +05/06 -# to +04/+05. It's unclear how Kzyl-Orda oblast moved into the fifth +# to +04/+05. It's unclear how Qyzylorda oblast moved into the fifth # time belt. (By switching from +04/+05 to +05/+06 on 1991-09-29?) ... # # 1. Act of the Cabinet of Ministers of the Republic of Kazakhstan @@ -1647,25 +1647,25 @@ Zone Asia/Amman 2:23:44 - LMT 1931 # on the whole territory of Kazakhstan 1 hour forward on 1992-01-19 at # 2:00, specified DST rules. It acknowledged that Kazakhstan was # located in the fourth and the fifth time belts and specified the -# border between them to be located east of Kustanay and Aktyubinsk -# oblasts (notably including Turgai and Kzyl-Orda oblasts into the fifth +# border between them to be located east of Qostanay and Aktyubinsk +# oblasts (notably including Turgai and Qyzylorda oblasts into the fifth # time belt). # # This means switch on 1992-01-19 at 2:00 from +04/+05 to +05/+06 for -# Asia/Aqtau, Asia/Aqtobe, Asia/Oral, Atyrau and Kustanay oblasts; from -# +05/+06 to +06/+07 for Asia/Almaty and Asia/Qyzylorda (and Arkalyk) [*].... +# Asia/Aqtau, Asia/Aqtobe, Asia/Oral, Atyraū and Qostanay oblasts; from +# +05/+06 to +06/+07 for Asia/Almaty and Asia/Qyzylorda (and Arkalyk).... # # 2. Act of the Cabinet of Ministers of the Republic of Kazakhstan # from 1992-03-27 No. 284 # http://adilet.zan.kz/rus/docs/P920000284_ -# cancels extra hour ("decree time") for Uralsk and Kzyl-Orda oblasts +# cancels extra hour ("decree time") for Uralsk and Qyzylorda oblasts # since the last Sunday of March 1992, while keeping them in the fourth # and the fifth time belts respectively. # # 3. Order of the Prime Minister of the Republic of Kazakhstan # from 1994-09-23 No. 384 # http://adilet.zan.kz/rus/docs/R940000384_ -# cancels the extra hour ("decree time") on the territory of Mangystau +# cancels the extra hour ("decree time") on the territory of Mangghystaū # oblast since the last Sunday of September 1994 (saying that time on # the territory would correspond to the third time belt as a # result).... @@ -1679,14 +1679,11 @@ Zone Asia/Amman 2:23:44 - LMT 1931 # 5. Act of the Government of the Republic of Kazakhstan # from 1999-03-26 No. 305 # http://adilet.zan.kz/rus/docs/P990000305_ -# cancels the extra hour ("decree time") for Atyrau oblast since the +# cancels the extra hour ("decree time") for Atyraū oblast since the # last Sunday of March 1999 while retaining the oblast in the fourth # time belt. # -# This means change from +05/+06 to +04/+05. -# -# There is no zone for Atyrau currently (listed under Asia/Aqtau in -# zone1970.tab).[*] +# This means change from +05/+06 to +04/+05.... # # 6. Act of the Government of the Republic of Kazakhstan # from 2000-11-23 No. 1749 @@ -1696,10 +1693,10 @@ Zone Asia/Amman 2:23:44 - LMT 1931 # The only changes I noticed are in definition of the border between the # fourth and the fifth time belts. They account for changes in spelling # and administrative division (splitting of Turgai oblast in 1997 -# probably changed time in territories incorporated into Kostanay oblast -# (including Arkalyk) from +06/+07 to +05/+06) and move Kyzylorda oblast +# probably changed time in territories incorporated into Qostanay oblast +# (including Arkalyk) from +06/+07 to +05/+06) and move Qyzylorda oblast # from being in the fifth time belt and not using decree time into the -# fourth time belt (no change in practice).[*] +# fourth time belt (no change in practice). # # 7. Act of the Government of the Republic of Kazakhstan # from 2003-12-29 No. 1342 @@ -1709,7 +1706,7 @@ Zone Asia/Amman 2:23:44 - LMT 1931 # 8. Act of the Government of the Republic of Kazakhstan # from 2004-07-20 No. 775 # http://adilet.zan.kz/rus/archive/docs/P040000775_/20.07.2004 -# modified the 2000-11-23 act to move Kostanay and Kyzylorda oblasts into +# modified the 2000-11-23 act to move Qostanay and Qyzylorda oblasts into # the fifth time belt and add Aktobe oblast to the list of regions not # using extra hour ("decree time"), leaving Kazakhstan with only 2 time # zones (+04/+05 and +06/+07). The changes were to be implemented @@ -1721,14 +1718,14 @@ Zone Asia/Amman 2:23:44 - LMT 1931 # http://adilet.zan.kz/rus/docs/P040001059_ # modified the 2000-11-23 act to remove exceptions from the "decree time" # (leaving Kazakhstan in +05/+06 and +06/+07 zones), amended the -# 2004-07-20 act to implement changes for Atyrau, West Kazakhstan, -# Kostanay, Kyzylorda and Mangystau oblasts by not moving clocks -# during the 2014 transition to "winter" time. +# 2004-07-20 act to implement changes for Atyraū, West Kazakhstan, +# Qostanay, Qyzylorda and Mangghystaū oblasts by not moving clocks +# during the 2004 transition to "winter" time. # -# This means transition from +04/+05 to +05/+06 for Atyrau oblast (no +# This means transition from +04/+05 to +05/+06 for Atyraū oblast (no # zone currently), Asia/Oral, Asia/Aqtau and transition from +05/+06 to -# +06/+07 for Kostanay oblast (Kostanay and Arkalyk, no zones currently) -# and Asia/Qyzylorda on 2004-10-31 at 3:00....[*] +# +06/+07 for Qostanay oblast (Qostanay and Arkalyk, no zones currently) +# and Asia/Qyzylorda on 2004-10-31 at 3:00.... # # 10. Act of the Government of the Republic of Kazakhstan # from 2005-03-15 No. 231 @@ -1744,14 +1741,9 @@ Zone Asia/Amman 2:23:44 - LMT 1931 # Kazakh 1992-01-13 act appears to provide the same rules and 1992-03-27 # act was to be enacted on the last Sunday of March 1992. -# From Paul Eggert (2016-04-15): -# The tables below should reflect Stepan Golosunov's remarks above, -# except for the items marked "[*]" which I haven't gotten to yet. -# It looks like we will need new zones Asia/Atyrau and Asia/Qostanay -# to handle changes from 1992 through 2004 that we did not previously -# know about. +# From Paul Eggert (2016-11-07): +# The tables below reflect Golosunov's remarks, with exceptions as noted. -# # Zone NAME GMTOFF RULES FORMAT [UNTIL] # # Almaty (formerly Alma-Ata), representing most locations in Kazakhstan @@ -1764,6 +1756,8 @@ Zone Asia/Almaty 5:07:48 - LMT 1924 May 2 # or Alma-Ata 6:00 RussiaAsia +06/+07 2004 Oct 31 2:00s 6:00 - +06 # Qyzylorda (aka Kyzylorda, Kizilorda, Kzyl-Orda, etc.) (KZ-KZY) +# This currently includes Qostanay (aka Kostanay, Kustanay) (KZ-KUS); +# see comments below. Zone Asia/Qyzylorda 4:21:52 - LMT 1924 May 2 4:00 - +04 1930 Jun 21 5:00 - +05 1981 Apr 1 @@ -1775,7 +1769,21 @@ Zone Asia/Qyzylorda 4:21:52 - LMT 1924 May 2 6:00 RussiaAsia +06/+07 1992 Mar 29 2:00s 5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s 6:00 - +06 -# Aqtobe (aka Aktobe, formerly Aktyubinsk) (KZ-AKT) +# The following zone is like Asia/Qyzylorda except for being one +# hour earlier from 1991-09-29 to 1992-03-29. The 1991/2 rules for +# Qostenay are unclear partly because of the 1997 Turgai +# reorganization, so this zone is commented out for now. +#Zone Asia/Qostanay 4:14:20 - LMT 1924 May 2 +# 4:00 - +04 1930 Jun 21 +# 5:00 - +05 1981 Apr 1 +# 5:00 1:00 +06 1981 Oct 1 +# 6:00 - +06 1982 Apr 1 +# 5:00 RussiaAsia +05/+06 1991 Mar 31 2:00s +# 4:00 RussiaAsia +04/+05 1992 Jan 19 2:00s +# 5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s +# 6:00 - +06 +# +# Aqtöbe (aka Aktobe, formerly Aktyubinsk) (KZ-AKT) Zone Asia/Aqtobe 3:48:40 - LMT 1924 May 2 4:00 - +04 1930 Jun 21 5:00 - +05 1981 Apr 1 @@ -1785,14 +1793,11 @@ Zone Asia/Aqtobe 3:48:40 - LMT 1924 May 2 4:00 RussiaAsia +04/+05 1992 Jan 19 2:00s 5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s 5:00 - +05 -# Qostanay (KZ-KUS) - -# Mangghystau (KZ-MAN) +# Mangghystaū (KZ-MAN) # Aqtau was not founded until 1963, but it represents an inhabited region, # so include time stamps before 1963. Zone Asia/Aqtau 3:21:04 - LMT 1924 May 2 4:00 - +04 1930 Jun 21 - 5:00 - +05 1963 5:00 - +05 1981 Oct 1 6:00 - +06 1982 Apr 1 5:00 RussiaAsia +05/+06 1991 Mar 31 2:00s @@ -1800,7 +1805,17 @@ Zone Asia/Aqtau 3:21:04 - LMT 1924 May 2 5:00 RussiaAsia +05/+06 1994 Sep 25 2:00s 4:00 RussiaAsia +04/+05 2004 Oct 31 2:00s 5:00 - +05 - +# Atyraū (KZ-ATY) is like Mangghystaū except it switched from +# +04/+05 to +05/+06 in spring 1999, not fall 1994. +Zone Asia/Atyrau 3:27:44 - LMT 1924 May 2 + 4:00 - +04 1930 Jun 21 + 5:00 - +05 1981 Oct 1 + 6:00 - +06 1982 Apr 1 + 5:00 RussiaAsia +05/+06 1991 Mar 31 2:00s + 4:00 RussiaAsia +04/+05 1992 Jan 19 2:00s + 5:00 RussiaAsia +05/+06 1999 Mar 28 2:00s + 4:00 RussiaAsia +04/+05 2004 Oct 31 2:00s + 5:00 - +05 # West Kazakhstan (KZ-ZAP) # From Paul Eggert (2016-03-18): # The 1989 transition is from USSR act No. 227 (1989-03-14). diff --git a/zone.tab b/zone.tab index f4969d2..bf78be7 100644 --- a/zone.tab +++ b/zone.tab @@ -239,7 +239,8 @@ KY +1918-08123 America/Cayman KZ +4315+07657 Asia/Almaty Kazakhstan (most areas) KZ +4448+06528 Asia/Qyzylorda Qyzylorda/Kyzylorda/Kzyl-Orda KZ +5017+05710 Asia/Aqtobe Aqtobe/Aktobe -KZ +4431+05016 Asia/Aqtau Atyrau/Atirau/Gur'yev, Mangghystau/Mankistau +KZ +4431+05016 Asia/Aqtau Mangghystau/Mankistau +KZ +4707+05156 Asia/Atyrau Atyrau/Atirau/Gur'yev KZ +5113+05121 Asia/Oral West Kazakhstan LA +1758+10236 Asia/Vientiane LB +3353+03530 Asia/Beirut diff --git a/zone1970.tab b/zone1970.tab index f48f7a6..ea2e1e5 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -210,8 +210,9 @@ KP +3901+12545 Asia/Pyongyang KR +3733+12658 Asia/Seoul KZ +4315+07657 Asia/Almaty Kazakhstan (most areas) KZ +4448+06528 Asia/Qyzylorda Qyzylorda/Kyzylorda/Kzyl-Orda -KZ +5017+05710 Asia/Aqtobe Aqtobe/Aktobe -KZ +4431+05016 Asia/Aqtau Atyrau/Atirau/Gur'yev, Mangghystau/Mankistau +KZ +5017+05710 Asia/Aqtobe Aqtöbe/Aktobe +KZ +4431+05016 Asia/Aqtau Mangghystaū/Mankistau +KZ +4707+05156 Asia/Atyrau Atyraū/Atirau/Gur'yev KZ +5113+05121 Asia/Oral West Kazakhstan LB +3353+03530 Asia/Beirut LK +0656+07951 Asia/Colombo -- 2.7.4

2 2

Zone name policy
by Maksym Besida Dec. 2, 2016

Dec. 2, 2016

Hello, In all versions of TZ data Ukraine zones are named using Russian language transliteration (e.g Europe/Kiev, Europe/Uzhgorod, Europe/Zaporozhye). In *tzdata2016j* in file *europe *it is said *"Kyiv is the transliteration of the Ukrainian name, but "Kiev" is more common in English".* But this is a mistake, because *"more common"* is a very subjective measure and in this case is imposed by russian speaking community which is larger than ukrainian one. Believe that in most groups of Chinese language the mentioned names are pronounced differently from Russian transliteration(even if chinese speaking population is greater than russian one). The official language in Ukraine is Ukrainian, so the proper names of mentioned cities are Kyiv, Uzhhorod and Zaporizhia respectively. Who is responsible for editing this data? -- Regards, Maksym Besida.

9 12

Doubt about releases/updates
by Pablo Sánchez Dec. 1, 2016

Dec. 1, 2016

Greetings, everyone! I have a doubt about the TZ database release or updates, and maybe you can help me to solve it. So, is the database update BEFORE or AFTER a new DST has started? The reason why I need to know it is because we are having issues about calculating some ETAs and presenting the information on reports, because PHP internal database doesn't get updates automatically. So we decided to use an extension that uses IANA's Timezone Database (updated approximatelly 23 times an year). So, we need to know if those updates are released before the daylight saving time starts or if you release it before it starts. Since there are usually political decisions that delays or rushes the DST beginning, I believe those updates comes prior to the actual fact, with a data on wich day begin, so I should not worry on using the extension that updates itself with 24 hours delay, right? So, do you update it before DST comes, or after? -- *Pablo Santiago Sánchez* ZCE ZEND006757 phackwer(a)gmail.com (61) 9843-0883 http://www.sansis.com.br *"Pluralitas non est ponenda sine necessitate"*

6 7

Re: [tz] DST cancelled for Asia/Baku since 17 March 2016
by Ariel Dor Nov. 30, 2016

Nov. 30, 2016

Ahh. Nm. Found it under thread "Azerbaijan canceled daylight saving time" >From March. BR Ariel From: Ariel Dor Sent: Wednesday, November 30, 2016 16:30 To: 'tz(a)iana.org' Subject: DST cancelled for Asia/Baku since 17 March 2016 Hi, I couldn't find a reference for this change from 17/Mar/2016 to be implemented in any tzdata revision. I did see that there was a minor correction for Asia/Baku in 2016e DB (for 1992), but not for the change from 2016 and on. Source https://www.timeanddate.com/news/time/no-dst-azerbaijan.html BR, Ariel

1 0

DST cancelled for Asia/Baku since 17 March 2016
by Ariel Dor Nov. 30, 2016

Nov. 30, 2016

Hi, I couldn't find a reference for this change from 17/Mar/2016 to be implemented in any tzdata revision. I did see that there was a minor correction for Asia/Baku in 2016e DB (for 1992), but not for the change from 2016 and on. Source https://www.timeanddate.com/news/time/no-dst-azerbaijan.html BR, Ariel

1 0

Happy 30th anniversary!
by Arthur David Olson Nov. 29, 2016

Nov. 29, 2016

------------------------------ > ...*Tue Nov 25 00:58:12 UTC 1986* > ... > Now that we've moved from 4.1BSD to 4.3BSD here at elsie, > I've set things up so that mail sent to > seismo!elsie!tz > will go to folks who've expressed an interest in time zone matters. http://mm.icann.org/pipermail/tz/1986-November/008946.html (Note that it was really the 24th local time.) @dashdashado

5 4