- tz - lists.iana.org

[PATCH] Update to cite current version of POSIX.1
by Sanjeev Jan. 7, 2017

Jan. 7, 2017

There has been a new Technical Corrigendum issued, and incorporated in the 2016 Edition. Slight reorder of the citation to conform to how Opengroup likes it. --- Theory | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Theory b/Theory index 22164f4..f2a8dde 100644 --- a/Theory +++ b/Theory @@ -39,10 +39,11 @@ also available. The tz code is upwards compatible with POSIX, an international standard for UNIX-like systems. As of this writing, the current edition of POSIX is: - The Open Group Base Specifications Issue 7 - IEEE Std 1003.1, 2013 Edition - <http://pubs.opengroup.org/onlinepubs/9699919799/> - + IEEE Std 1003.1,2016 Edition + The Open Group Technical Standard Base Specifications, Issue 7 + incorporates IEEE Std 1003.1-2008, + IEEE Std 1003.1-2008/Cor 1-2013, + IEEE Std 1003.1-2008/Cor 2-2016 ----- Names of time zone rules ----- -- 2.10.2

5 4

[PROPOSED] Remove invented North American abbreviations
by Paul Eggert Jan. 5, 2017

Jan. 5, 2017

* NEWS: Document this. * northamerica (America/Anchorage): Use AST/AWT/APT instead of CAT/CAWT/CADT for time stamps before 1968. (Belize, America/Belize, DR, America/Santo_Domingo, America/Miquelon): Use numeric time zone abbreviations instead of invented one. --- NEWS | 11 ++++++++-- northamerica | 71 +++++++++++++++++++++++++++++------------------------------- 2 files changed, 43 insertions(+), 39 deletions(-) diff --git a/NEWS b/NEWS index 5e04e01..780c81c 100644 --- a/NEWS +++ b/NEWS @@ -50,8 +50,15 @@ Unreleased, experimental changes America/Sao_Paulo, Antarctica/Palmer, Atlantic/South_Georgia, Atlantic/Stanley, Pacific/Easter, and Pacific/Galapagos. - Similarly, switch to a numeric time zone abbreviation for Canary - Island time before 1946. + Similarly, switch to numeric time zone abbreviations for St Pierre + and Miquelon time, for half-hour DST in Belize before 1944 and in + the Dominican Republic before 1975, and for Canary Island time + before 1946. + + For Alaska time from 1900 through 1967, instead of "CAT" use the + abbreviation "AST", the abbreviation commonly used at the time + (Atlantic Standard Time had not been standardized yet). Use "AWT" + and "APT" instead of the invented abbreviations "CAWT" and "CAPT". Changes to code diff --git a/northamerica b/northamerica index e1ed9e4..bb0af6c 100644 --- a/northamerica +++ b/northamerica @@ -178,22 +178,6 @@ Zone CST6CDT -6:00 US C%sT Zone MST7MDT -7:00 US M%sT Zone PST8PDT -8:00 US P%sT -# From Bob Devine (1988-01-28): -# ...Alaska (and Hawaii) had the timezone names changed in 1967. -# old new -# Pacific Standard Time(PST) -same- -# Yukon Standard Time(YST) -same- -# Central Alaska S.T. (CAT) Alaska-Hawaii St[an]dard Time (AHST) -# Nome Standard Time (NT) Bering Standard Time (BST) -# -# ...Alaska's timezone lines were redrawn in 1983 to give only 2 tz. -# The YST zone now covers nearly all of the state, AHST just part -# of the Aleutian islands. No DST. - -# From Paul Eggert (1995-12-19): -# The tables below use 'NST', not 'NT', for Nome Standard Time. -# I invented 'CAWT' for Central Alaska War Time. - # From U. S. Naval Observatory (1989-01-19): # USA EASTERN 5 H BEHIND UTC NEW YORK, WASHINGTON # USA EASTERN 4 H BEHIND UTC APR 3 - OCT 30 @@ -250,6 +234,21 @@ Zone PST8PDT -8:00 US P%sT # Samoa standard time # The law doesn't give abbreviations. # +# From Paul Eggert (2016-12-19): +# Here are URLs for the 1918 and 1966 legislation: +# http://uscode.house.gov/statviewer.htm?volume=40&page=451 +# http://uscode.house.gov/statviewer.htm?volume=80&page=108 +# Although the 1918 names were officially "United States Standard +# Eastern Time" and similarly for "Central", "Mountain", "Pacific", +# and "Alaska", in practice "Standard" was placed just before "Time", +# as codified in 1966. In practice, Alaska time was abbreviated "AST" +# before 1968. Summarizing the 1967 name changes: +# 1918 names 1967 names +# -08 Standard Pacific Time (PST) Pacific standard time (PST) +# -09 (unofficial) Yukon (YST) Yukon standard time (YST) +# -10 Standard Alaska Time (AST) Alaska-Hawaii standard time (AHST) +# -11 (unofficial) Nome (NST) Bering standard time (BST) +# # From Paul Eggert (2000-01-08), following a heads-up from Rives McDow: # Public law 106-564 (2000-12-23) introduced ... "Chamorro Standard Time" # for time in Guam and the Northern Marianas. See the file "australasia". @@ -482,7 +481,7 @@ Zone America/Los_Angeles -7:52:58 - LMT 1883 Nov 18 12:07:02 -8:00 US P%sT # Alaska -# AK%sT is the modern abbreviation for -9:00 per USNO. +# AK%sT is the modern abbreviation for -09 per USNO. # # From Paul Eggert (2001-05-30): # Howse writes that Alaska switched from the Julian to the Gregorian calendar, @@ -588,10 +587,8 @@ Zone America/Yakutat 14:41:05 - LMT 1867 Oct 18 -9:00 US AK%sT Zone America/Anchorage 14:00:24 - LMT 1867 Oct 18 -9:59:36 - LMT 1900 Aug 20 12:00 - -10:00 - CAT 1942 - -10:00 US CAT/CAWT 1945 Aug 14 23:00u - -10:00 US CAT/CAPT 1946 # Peace - -10:00 - CAT 1967 Apr + -10:00 - AST 1942 + -10:00 US A%sT 1967 Apr -10:00 - AHST 1969 -10:00 US AH%sT 1983 Oct 30 2:00 -9:00 US Y%sT 1983 Nov 30 @@ -2734,15 +2731,15 @@ Zone America/Barbados -3:58:29 - LMT 1924 # Bridgetown # Belize # Whitman entirely disagrees with Shanks; go with Shanks & Pottenger. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Belize 1918 1942 - Oct Sun>=2 0:00 0:30 HD -Rule Belize 1919 1943 - Feb Sun>=9 0:00 0 S -Rule Belize 1973 only - Dec 5 0:00 1:00 D -Rule Belize 1974 only - Feb 9 0:00 0 S -Rule Belize 1982 only - Dec 18 0:00 1:00 D -Rule Belize 1983 only - Feb 12 0:00 0 S +Rule Belize 1918 1942 - Oct Sun>=2 0:00 0:30 -0530 +Rule Belize 1919 1943 - Feb Sun>=9 0:00 0 CST +Rule Belize 1973 only - Dec 5 0:00 1:00 CDT +Rule Belize 1974 only - Feb 9 0:00 0 CST +Rule Belize 1982 only - Dec 18 0:00 1:00 CDT +Rule Belize 1983 only - Feb 12 0:00 0 CST # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Belize -5:52:48 - LMT 1912 Apr - -6:00 Belize C%sT + -6:00 Belize %s # Bermuda @@ -3014,16 +3011,16 @@ Zone America/Havana -5:29:28 - LMT 1890 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule DR 1966 only - Oct 30 0:00 1:00 D -Rule DR 1967 only - Feb 28 0:00 0 S -Rule DR 1969 1973 - Oct lastSun 0:00 0:30 HD -Rule DR 1970 only - Feb 21 0:00 0 S -Rule DR 1971 only - Jan 20 0:00 0 S -Rule DR 1972 1974 - Jan 21 0:00 0 S +Rule DR 1966 only - Oct 30 0:00 1:00 EDT +Rule DR 1967 only - Feb 28 0:00 0 EST +Rule DR 1969 1973 - Oct lastSun 0:00 0:30 -0430 +Rule DR 1970 only - Feb 21 0:00 0 EST +Rule DR 1971 only - Jan 20 0:00 0 EST +Rule DR 1972 1974 - Jan 21 0:00 0 EST # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Santo_Domingo -4:39:36 - LMT 1890 -4:40 - SDMT 1933 Apr 1 12:00 # S. Dom. MT - -5:00 DR E%sT 1974 Oct 27 + -5:00 DR %s 1974 Oct 27 -4:00 - AST 2000 Oct 29 2:00 -5:00 US E%sT 2000 Dec 3 1:00 -4:00 - AST @@ -3313,8 +3310,8 @@ Zone America/Puerto_Rico -4:24:25 - LMT 1899 Mar 28 12:00 # San Juan # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre -4:00 - AST 1980 May - -3:00 - PMST 1987 # Pierre & Miquelon Time - -3:00 Canada PM%sT + -3:00 - -03 1987 # Pierre & Miquelon Time + -3:00 Canada -03/-02 # St Vincent and the Grenadines # See America/Port_of_Spain. -- 2.7.4

3 6

question about mktime_tzname()
by Kees Dekker Jan. 5, 2017

Jan. 5, 2017

Hi, I'm running into a potential bug. Please also see the attached C-source file for a reproduction. Reproduction steps: 1. Build tz code, in such way that a libtz.a exists 2. Compile attached source with (e.g. on Linux): gcc -g -o tztestcase2016j tztestcase.c -L <tzlibdir> -ltz 3. Checking the same test case source code with a system library (instead of IANA libtz.a) can be achieved by omitting -L and -l flags in previous command (see #2). It does not make much sense which version of tzcode is used, I tried 2013i and 2016j and both show the same behavior. The mktime() code returns -3600, while I expect 0. Because the TZ zone is explicitly specified, EST5EDT is GMT-5. So the provided time stamp (31-Jan-1969, 19:00) is exactly the same as UTC value 0 (1-Jan-1970, 00:00 GMT). Both Linux and Windows with system libraries return 0 in this specific case (I used these for reference). The remainder of this email is based on the tzcode2016j source code (e.g. for used line numbers). The provided TZ value is parsed in tzparse() and results in sp->ttis[0] set as DST value, and sp->ttis[1] as standard time value. This is at least contrary to in the else part of the if (*name == ',' || *name == ';') block (there DST is saved in sp->ttis[1]). Just grep on init_ttinfo() calls in localtime.c. However, in localsub(), around line 1428, the i becomes sp->defaulttype (which is zero), i.e. points to the DST value of sp->ttis[], which is assigned to ttisp. As result, because t is below sp->ats[0], DST takes into effect, which is incorrect, as everything after the last Sunday in October and before the first Sunday in April (see attachment, TZ="EST5EDT,M4.1.0/02:00,M10.5.0/02:00") is assumed to be standard time. I'm not sure whether I draw the right conclusion, but because the incorrect assumption of using DST, mktime() returns -3600 (on hour off) instead of the expected 0. Is this conclusion correct? I'm not sure how to fix it. When changing the call to init_ttinfo() and effectively swapping DST and standard time (also for symmetry with the else part) in sp-ttis[] (0 to 1 and 1 to 0) + keeping sp->defaulttype = 0 solved this problem, but introduces other conversion errors around DSTchanges (I don't have yet an reproduction, but can make one if needed). The sp->default type is used (in localsub ()) when if (sp->timecnt == 0 || t < sp->ats[0]). The other approach is to assign sp->defaulttype = 1 when the init_ttinfo() calls are not swapped. Anyhow, there is a tight relationship between the value of sp->defaulttype and the order in which DST/standard times are written in sp->ttis[]. If the previous idea is incorrect (and I guess it is), additional code may be needed in time2sub() if yourtm.tm_isdst == -1. In that case, the provided data in yourtm should be checked whether DST is (or is not) into effect. The found mytm struct should match. Otherwise a DST correction is needed (one-hour shift). The current code mistakenly uses DST, and that is why (if I understand all well) mktime() now returns -3600. If I was not able to explain the issue correctly, please let me know. I'm not sure to understand what's going wrong now, but may be, the provided attachment will help in giving better understanding. Because the provided date is near 1970, quite few steps are needed to see what's happing in localtime.c. Regards, Kees Dekker PS. This email has been sent assuming that attachments will not get lost. Otherwise, just copy paste the code below and save to e.g. tztestcase.c. #ifdef _WIN32 #define _CRT_SECURE_NO_WARNINGS #endif #include <time.h> #include <stdio.h> #include <stdlib.h> int main(void) { int ret = 0; const char *months[] = { "Jan", "Feb", "Mar", "April", "May", "June", "July", "Aug", "Sep", "Oct", "Nov", "Dec" }; const char *days[] = { "Sun", "Mon", "Tue", "Wed", "Tur", "Fri", "Sat" }; /* DST switch in April in first Sunday and October, last Sunday */ putenv("TZ=EST5EDT,M4.1.0/02:00,M10.5.0/02:00"); /* January, 1970, invalid input for tm_mday (0 instead 1..31) */ /* non-normalized input for minutes: 1140/60 = 19, so 19:00 EST5EDT time, which is 5 hours before GMT, and should result in t == 0 below */ /* let system figure out whether DST is effect */ struct tm tmp = { 0, 1140, 0, 0, 0, 70, -858993460, -858993460, -1}; printf("enter mktime with: %04d/%s/%02d %02d:%02d:%02d, week day: %d, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, tmp.tm_wday, tmp.tm_yday, tmp.tm_isdst); time_t t = mktime(&tmp); /* expect: t == 0, DST is off, time is exactly at the boundary of lowest possible UTC value */ printf("the return value of mktime is: %lld\n", (long long)t); printf("normalized times: %04d/%s/%02d %02d:%02d:%02d, week day: %s, year day: %d, dst: %d\n", tmp.tm_year + 1900, months[tmp.tm_mon], tmp.tm_mday, tmp.tm_hour, tmp.tm_min, tmp.tm_sec, days[tmp.tm_wday], tmp.tm_yday, tmp.tm_isdst); if (t >= 0) { printf("tz=%s, %s\n", tzname[0], tzname[1]); } return 0; }

1 0

Definition for timezone Asia/Urumqi and Asia/Kashgar, CST, and other questions about Chinese timezones.
by gfb hjjhjh Jan. 5, 2017

Jan. 5, 2017

1. Currently, Asia/Urumqi and Asia/Kashgar are defined as UTC+6, covering most of Xinjiang and Tibet. However, from brief search result, I cannot see any indication about the UTC+6 usage by ethnic non-han in Xinjiang also exists in Tibet, and Lhasa resident daily activities are apparently only one hours later than those in inner China too. The official announcement about UTC+6 usage in Xinjiang also does not cover Tibet. Thus it seems like those UTC+6 timezones in tz database should not cover Tibet. However, there might be some undocumented official announcement or on the ground usage that I does not notice and require further validation. 2. Actually, which file define the boundary of timezones in tz database? I see they are in comments for China but how about generally? 3. And given Asia/Urumqi is currently defined differently from Asia/Shanghai, and Maoming, Guandong is now using UTC+8, no matter what historical reason might be behind the consideration of putting Maoming, Guangdong in Asia/Urumqi, its current time usage along should have justified putting it in Asia/Shanghai instead 3.a. In http://mm.icann.org/pipermail/tz/2006-July/013704.html , it said Maoming and etc. are in Xinjiang tinezone with data from astro.com but I cannot find anywhere on the site that include historical timezone info and what are their sources? 4. as the name "Central Standard Time" in China was created by ROC, the current main use of this term is for the time in Taiwan and thus it might be unsuitable to use the name for timzone in mainland china area. 5. Why there are 5 different zones in China when the theory file say "if all the clocks in the region have agreed since 1970, don't bother to inclide more than one location even if subregions' clocks disagreed before 1970" ?

5 7

zdump broken with -DUSE_LTZ=0
by Joseph Myers Dec. 21, 2016

Dec. 21, 2016

I tried updating the copy of tzcode in glibc. I found that as of the latest release and current git, zdump doesn't build with -DUSE_LTZ=0, because that configuration disables the inclusion of private.h, which defines the INITIALIZE macro which zdump now uses unconditionally. (There's also a -Wundef issue with the "#if !HAVE_POSIX_DECLS", as that's also only defined in private.h, but that's easy to work around.) -- Joseph S. Myers joseph(a)codesourcery.com

2 1

Minor fixes to commentary
by Tim Parenti Dec. 19, 2016

Dec. 19, 2016

The attached patch fixes a few minor issues left in commentary, and also adds a note about the constructed lines for America/Montevideo which currently work around the non-prevalence of zic which supports %z. -- Tim Parenti

2 1

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] Pacify ‘make check_character_set’
by Paul Eggert Dec. 19, 2016

Dec. 19, 2016

* tz-art.htm: Convert to ASCII. --- tz-art.htm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tz-art.htm b/tz-art.htm index de56b07..296a2d9 100644 --- a/tz-art.htm +++ b/tz-art.htm @@ -376,12 +376,13 @@ line is "Lights go out and I can't be saved".</td></tr> <tr><td> </td></tr> <tr><td>Artist</td><td>Jaime Guevara</td></tr> -<tr><td>Song</td><td><a href="https://www.youtube.com/watch?v=ZfN4Fe_A50U">Qué +<tr><td>Song</td><td><a +href="https://www.youtube.com/watch?v=ZfN4Fe_A50U">Qué hora es</a></td></tr> <tr><td>Date</td><td>1993</td></tr> <tr><td>Total Time</td><td>3:04</td></tr> <tr><td>Notes</td><td>The song protested "Sixto Hour" in Ecuador -(1992–3). Its lyrics include "Amanecía en mitad de la noche, los +(1992–3). Its lyrics include "Amanecía en mitad de la noche, los guaguas iban a clase sin sol" ("It was dawning in the middle of the night, the buses went to class without sun"). <tr><td> </td></tr> -- 2.7.4

1 0

Havranek et al. on DST's effect on energy consumption
by Paul Eggert Dec. 18, 2016

Dec. 18, 2016

A recent meta-analysis of energy savings due to daylight-saving time found a mean effect close to zero (the weighted mean of 0.343% was less than the estimated standard error). The largest energy savings from DST was found in high-latitude countries; areas closer to the equator tended to have negative energy savings. Studies published in journals with high impact factors tended to be more pessimistic about energy-savings benefits. The study concluded, "the effects of daylight saving time on energy consumption are too small to justify the biannual time-shifting." Havranek T, Herman D, Irsova Z. Does daylight saving save energy? a meta-analysis. MPRA Paper No. 74518 (2016-10-12). https://mpra.ub.uni-muenchen.de/74518/1/MPRA_paper_74518.pdf

1 0

Re: [tz] Request to add entry to "Programmatic interfaces that map geographical coordinates"
by Evan Siroky Dec. 17, 2016

Dec. 17, 2016

The package tz-lookup and geo-tz are independent of each other. As far as I know, the major difference between the two is the data source that is used. geo-tz is released under the MIT license. Feel free to link to the timezone tag. Although in my opinion a lot of the packages aren't the best because they don't get updated frequently enough with changes to the timezone db. Evan On Saturday, 10 December 2016, 12:02, Paul Eggert <eggert(a)cs.ucla.edu> wrote: Evan Siroky via tz wrote: > I maintain a node.js library that looks up the timezone name at a GPS coordinate. The project is called geo-tz: https://www.npmjs.com/package/geo-tz My library uses data produced from timezone-boundary-builder. Can you please add an entry to tz-link.html for my project? What's a good way to do that? Currently tz-link.htm says: <li>The <a href="https://www.npmjs.com/package/tz-lookup">tz-lookup module</a> for <a href="https://nodejs.org/en/">Node.js</a> is in the public domain.</li> How should the relationship between tz-lookup and geo-tz be described? Also, what's the license for geo-tz? It is not obvious from its web page. In looking at <https://www.npmjs.com/browse/keyword/timezone> I see several more Node.js time zone packages that seem relevant. Perhaps we should link to that page?

3 6