July 2015 - 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

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

zic changes (2/2)
by Arthur David Olson March 9, 2016

March 9, 2016

And now, the update. These changes arrange things so that binary files include "transition" entries for minimum time values; these entries eliminate localtime guesswork in handling low-valued time stamps. The bad news: binary files grow slightly as a result of these changes. The good news: there are no changes in the output of "zdump -v" applied to before-and-after versions of all the binary files generated by a "make install." Changes are attached and appear in mangled form below; these are relative to the github version of zic.c after the rollback in the earlier message today. @dashdashado 1.2 2805 lines 1.4 2813 lines *** /tmp/,azic.c 2014-05-01 01:51:36.998933800 -0400 --- /tmp/,bzic.c 2014-05-01 01:51:37.092534000 -0400 *************** *** 1480,1493 **** fromi = 0; while (fromi < timecnt && attypes[fromi].at < min_time) ++fromi; - if (isdsts[0] == 0) - while (fromi < timecnt && attypes[fromi].type == 0) - ++fromi; /* handled by default rule */ for ( ; fromi < timecnt; ++fromi) { ! if (toi != 0 && ((attypes[fromi].at + gmtoffs[attypes[toi - 1].type]) <= ! (attypes[toi - 1].at + gmtoffs[toi == 1 ? 0 ! : attypes[toi - 2].type]))) { attypes[toi - 1].type = attypes[fromi].type; continue; --- 1480,1490 ---- fromi = 0; while (fromi < timecnt && attypes[fromi].at < min_time) ++fromi; for ( ; fromi < timecnt; ++fromi) { ! if (toi > 1 && ((attypes[fromi].at + gmtoffs[attypes[toi - 1].type]) <= ! (attypes[toi - 1].at + ! gmtoffs[attypes[toi - 2].type]))) { attypes[toi - 1].type = attypes[fromi].type; continue; *************** *** 1532,1537 **** --- 1529,1541 ---- --timecnt32; ++timei32; } + /* + ** Output an INT32_MIN "transition" if appropriate--see below. + */ + if (timei32 > 0 && ats[timei32] > INT32_MIN) { + --timei32; + ++timecnt32; + } while (leapcnt32 > 0 && !is32(trans[leapcnt32 - 1])) --leapcnt32; while (leapcnt32 > 0 && !is32(trans[leapi32])) { *************** *** 1698,1704 **** #undef DO for (i = thistimei; i < thistimelim; ++i) if (pass == 1) ! puttzcode(ats[i], fp); else puttzcode64(ats[i], fp); for (i = thistimei; i < thistimelim; ++i) { unsigned char uc; --- 1702,1713 ---- #undef DO for (i = thistimei; i < thistimelim; ++i) if (pass == 1) ! /* ! ** Output an INT32_MIN "transition" ! ** if appropriate--see above. ! */ ! puttzcode(((ats[i] < INT32_MIN) ? ! INT32_MIN : ats[i]), fp); else puttzcode64(ats[i], fp); for (i = thistimei; i < thistimelim; ++i) { unsigned char uc; *************** *** 2176,2183 **** if (usestart) { addtt(starttime, type); usestart = FALSE; ! } else if (stdoff != 0) ! addtt(min_time, type); } else for (year = min_year; year <= max_year; ++year) { if (useuntil && year > zp->z_untilrule.r_hiyear) break; --- 2185,2191 ---- if (usestart) { addtt(starttime, type); usestart = FALSE; ! } else addtt(min_time, type); } else for (year = min_year; year <= max_year; ++year) { if (useuntil && year > zp->z_untilrule.r_hiyear) break;

7 22

Request to include www.timejones.com - tz database version 2014.8
by Web Master Dec. 9, 2015

Dec. 9, 2015

Hi, Greetings! First of all immense thanks for the introduction of tz database to the world. We are writing from www.timejones.com, an ultra simple time and weather services portal that helps people with time and weather information for 150000 places on Earth. We have developed this web site using tz database version 2014.8/ PHP 5.4.39 and hosted on a Apache/2.2.29. Could you please kindly include www.timejones.com under the section "Web sites using recent versions of the tz database" in http://cs.ucla.edu/~eggert/tz/tz-link.htm ? Thanks in advance! Best Regards, Webmaster(a)timejones.com

3 2

South Australia may move clocks 30 minutes
by Paul Eggert Sept. 10, 2015

Sept. 10, 2015

The South Australian government is considering changing their clocks by 30 minutes. The government would prefer advancing clocks by 30 minutes to match the time on the east coast. The public is split. Much of the resistance is coming from the west part of the state, where locals worry about their children leaving for school in the dark, and the government is prepared to consider changing school hours to address this. Another possibility is retarding clocks by 30 minutes; this would move closer to solar time, and would align better with Asia. This change would probably affect Broken Hill as well. Northern Territory will be consulted but seems less inclined to change. The consultation process will take at least two months. The government's website crashed as citizens went online to give their opinion. Sources: Nicholson M. South Australia has the most ridiculous time zone, and might be about to change it. Junkee 2015-02-06. http://junkee.com/south-australia-has-the-most-ridiculous-time-zone-and-mig… Ball G, Clift J, Coote G. Broken Hill urged to air views on proposed time zone change for South Australia. ABC News (Australia), 2015-02-06. http://www.abc.net.au/news/2015-02-06/broken-hill-community-urged-air-views… SA considers changing time zone to match eastern states. 9NEWS 2015-02-05. http://www.9news.com.au/national/2015/02/05/12/15/sa-considers-changing-tim… South Australians remain divided on whether it is time for the time to change. 9NEWS 2015-02-06. http://www.9news.com.au/national/2015/02/06/21/03/south-australians-remain-…

2 3

Time zone humor
by Matt Johnson Aug. 18, 2015

Aug. 18, 2015

For the art file http://www.maniacworld.com/time-zones-explained.html Enjoy!

3 4

[PROPOSED PATCH] Support %z in Zone formats
by Paul Eggert Aug. 11, 2015

Aug. 11, 2015

This extends the zic input format to add support for %z, which expands to a UTC offset in as-short-as-possible ISO 8601 format. It's intended to better support zones that do not have an established abbreviation already. This is a change only to zic; it does not affect the data, which can still be compiled with older zic versions. * NEWS, zic.8: Document this. * zic.c (struct zone): New member z_format_specifier. (PERCENT_Z_LEN_BOUND): New constant. (max_abbrvar_len): Initialize to it, rather than to 0. (associate, inzsub, doabbr): Add support for %z. (abbroffset): New function. (doabbr): 2nd arg is now struct zone *, not a char *. All callers changed. --- NEWS | 5 +++++ zic.8 | 13 +++++++++++ zic.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------------- 3 files changed, 85 insertions(+), 15 deletions(-) diff --git a/NEWS b/NEWS index b7593e7..9eff28c 100644 --- a/NEWS +++ b/NEWS @@ -25,6 +25,11 @@ Unreleased, experimental changes (Thanks to Jon Skeet and Arthur David Olson.) Constraints on simultaneity are now documented. + The two characters '%z' in a zone format now stand for the UTC + offset, e.g., '-07' for seven hours behind UTC and '+0530' for + five hours and thirty minutes ahead. This better supports time + zone abbreviations conforming to POSIX.1-2001 and later. + Changes affecting installed data files Data entries have been simplified for Atlantic/Canary, Europe/Simferopol, diff --git a/zic.8 b/zic.8 index dfb01db..94b6753 100644 --- a/zic.8 +++ b/zic.8 @@ -350,6 +350,19 @@ The pair of characters is used to show where the .q "variable part" of the time zone abbreviation goes. +Alternately, a format can use the pair of characters +.B %z +to stand for the UTC offset in the form +.RI \(+- hh , +.RI \(+- hhmm , +or +.RI \(+- hhmmss , +using the shortest form that does not lose information, where +.IR hh , +.IR mm , +and +.I ss +are the hours, minutes, and seconds east (+) or west (\(mi) of UTC. Alternately, a slash (/) separates standard and daylight abbreviations. diff --git a/zic.c b/zic.c index 6854033..3c4ae93 100644 --- a/zic.c +++ b/zic.c @@ -76,6 +76,7 @@ struct zone { zic_t z_gmtoff; const char * z_rule; const char * z_format; + char z_format_specifier; zic_t z_stdoff; @@ -130,6 +131,9 @@ static void rulesub(struct rule * rp, static zic_t tadd(zic_t t1, zic_t t2); static bool yearistype(int year, const char * type); +/* Bound on length of what %z can expand to. */ +enum { PERCENT_Z_LEN_BOUND = sizeof "+995959" - 1 }; + static int charcnt; static bool errors; static bool warnings; @@ -139,7 +143,7 @@ static bool leapseen; static zic_t leapminyear; static zic_t leapmaxyear; static int linenum; -static int max_abbrvar_len; +static int max_abbrvar_len = PERCENT_Z_LEN_BOUND; static int max_format_len; static zic_t max_year; static zic_t min_year; @@ -955,7 +959,7 @@ associate(void) ** Note, though, that if there's no rule, ** a '%s' in the format is a bad thing. */ - if (strchr(zp->z_format, '%') != 0) + if (zp->z_format_specifier == 's') error("%s", _("%s in ruleless zone")); } } @@ -1170,6 +1174,7 @@ static bool inzsub(char **fields, int nfields, bool iscont) { register char * cp; + char * cp1; static struct zone z; register int i_gmtoff, i_rule, i_format; register int i_untilyear, i_untilmonth; @@ -1201,13 +1206,21 @@ inzsub(char **fields, int nfields, bool iscont) z.z_linenum = linenum; z.z_gmtoff = gethms(fields[i_gmtoff], _("invalid UT offset"), true); if ((cp = strchr(fields[i_format], '%')) != 0) { - if (*++cp != 's' || strchr(cp, '%') != 0) { + if ((*++cp != 's' && *cp != 'z') || strchr(cp, '%') + || strchr(fields[i_format], '/')) { error(_("invalid abbreviation format")); return false; } } z.z_rule = ecpyalloc(fields[i_rule]); - z.z_format = ecpyalloc(fields[i_format]); + z.z_format = cp1 = ecpyalloc(fields[i_format]); + z.z_format_specifier = cp ? *cp : '\0'; + if (z.z_format_specifier == 'z') { + if (noise) + warning(_("format '%s' not handled by pre-2015 versions of zic"), + z.z_format); + cp1[cp - fields[i_format]] = 's'; + } if (max_format_len < strlen(z.z_format)) max_format_len = strlen(z.z_format); hasuntil = nfields > i_untilyear; @@ -1890,19 +1903,59 @@ writezone(const char *const name, const char *const string, char version) free(fullname); } +static char const * +abbroffset(char *buf, zic_t offset) +{ + char sign = '+'; + int seconds, minutes; + + if (offset < 0) { + offset = -offset; + sign = '-'; + } + + seconds = offset % SECSPERMIN; + offset /= SECSPERMIN; + minutes = offset % MINSPERHOUR; + offset /= MINSPERHOUR; + if (100 <= offset) { + error(_("%%z UTC offset magnitude exceeds 99:59:59")); + return "%z"; + } else { + char *p = buf; + *p++ = sign; + *p++ = '0' + offset / 10; + *p++ = '0' + offset % 10; + if (minutes | seconds) { + *p++ = '0' + minutes / 10; + *p++ = '0' + minutes % 10; + if (seconds) { + *p++ = '0' + seconds / 10; + *p++ = '0' + seconds % 10; + } + } + *p = '\0'; + return buf; + } +} + static size_t -doabbr(char *const abbr, const char *const format, const char *const letters, +doabbr(char *abbr, struct zone const *zp, char const *letters, bool isdst, bool doquotes) { register char * cp; register char * slashp; register size_t len; + char const *format = zp->z_format; slashp = strchr(format, '/'); if (slashp == NULL) { - if (letters == NULL) - strcpy(abbr, format); - else sprintf(abbr, format, letters); + char letterbuf[PERCENT_Z_LEN_BOUND + 1]; + if (zp->z_format_specifier == 'z') + letters = abbroffset(letterbuf, -zp->z_gmtoff); + else if (!letters) + letters = "%s"; + sprintf(abbr, format, letters); } else if (isdst) { strcpy(abbr, slashp + 1); } else { @@ -2127,7 +2180,7 @@ stringzone(char *result, const struct zone *const zpfirst, const int zonecount) if (stdrp == NULL && (zp->z_nrules != 0 || zp->z_stdoff != 0)) return -1; abbrvar = (stdrp == NULL) ? "" : stdrp->r_abbrvar; - len = doabbr(result, zp->z_format, abbrvar, false, true); + len = doabbr(result, zp, abbrvar, false, true); offsetlen = stringoffset(result + len, -zp->z_gmtoff); if (! offsetlen) { result[0] = '\0'; @@ -2136,7 +2189,7 @@ stringzone(char *result, const struct zone *const zpfirst, const int zonecount) len += offsetlen; if (dstrp == NULL) return compat; - len += doabbr(result + len, zp->z_format, dstrp->r_abbrvar, true, true); + len += doabbr(result + len, zp, dstrp->r_abbrvar, true, true); if (dstrp->r_stdoff != SECSPERMIN * MINSPERHOUR) { offsetlen = stringoffset(result + len, -(zp->z_gmtoff + dstrp->r_stdoff)); @@ -2307,8 +2360,7 @@ outzone(const struct zone * const zpfirst, const int zonecount) startoff = zp->z_gmtoff; if (zp->z_nrules == 0) { stdoff = zp->z_stdoff; - doabbr(startbuf, zp->z_format, - NULL, stdoff != 0, false); + doabbr(startbuf, zp, NULL, stdoff != 0, false); type = addtype(oadd(zp->z_gmtoff, stdoff), startbuf, stdoff != 0, startttisstd, startttisgmt); @@ -2400,7 +2452,7 @@ outzone(const struct zone * const zpfirst, const int zonecount) if (ktime < starttime) { startoff = oadd(zp->z_gmtoff, stdoff); - doabbr(startbuf, zp->z_format, + doabbr(startbuf, zp, rp->r_abbrvar, rp->r_stdoff != 0, false); @@ -2410,7 +2462,7 @@ outzone(const struct zone * const zpfirst, const int zonecount) startoff == oadd(zp->z_gmtoff, stdoff)) { doabbr(startbuf, - zp->z_format, + zp, rp->r_abbrvar, rp->r_stdoff != false, @@ -2419,7 +2471,7 @@ outzone(const struct zone * const zpfirst, const int zonecount) } eats(zp->z_filename, zp->z_linenum, rp->r_filename, rp->r_linenum); - doabbr(ab, zp->z_format, rp->r_abbrvar, + doabbr(ab, zp, rp->r_abbrvar, rp->r_stdoff != 0, false); offset = oadd(zp->z_gmtoff, rp->r_stdoff); type = addtype(offset, ab, rp->r_stdoff != 0, -- 2.1.4

3 4

suggestions for potential code improvements?
by Kees Dekker July 31, 2015

July 31, 2015

Hi, I extracted the v2015e code and like to ask some things: 1. Why do you not always initialize the variables that are now passed to the INITIALIZE macro (see date.c/localtime.c/zic.c/private.h)? It has (almost) no impact on performance and prevents strict compilers to complain about (potentially) non-initialized variables. If you assign zero upon declaration, the INITIALIZE macro can go away. 2. In asctime_r() (asctime.c:72 and later) two arrays are used for week days. These arrays use a size of '3' for a 3-letter weekday. I expect to use an array of '4', because the '\0' character need to fit too, because the wn and mn variables are used in a call to sprintf() (line 106), where sprintf() normally requires to use 0-terminated strings. By using a '4'-sized array, this is automatically achieved. I don't know whether all sprintf() implementations for all operating systems respect the width/size specifier and allow non-0 terminated string. Now a size/width of '3' is specified, which is not needed if the strings are well terminated, or by accident used somewhere else. I really appreciate if you will do something with these suggestions. Regards, Kees

4 24

CST timezone that does not account for DST
by Nilesh Parmar July 30, 2015

July 30, 2015

Hello Team, How can we have CST timezone that does not account for DST ? Using the POSIX string, we can create a timezone called CST that is GMT+6 as follows: [root@hp-dl120gen9-01 ~]# TZ=:CST6 date Thu Jul 9 06:50:29 CST 2015 But this is not consitent if tzdata package is update. Also this does take into account DST change? Thanks, Nilesh P.

6 7

Time zone identifiers in user interfaces
by Gilmore Davidson July 30, 2015

July 30, 2015

Hi, long time lurker here, finally throwing my voice into the ring. This is a follow-up to the “Time Zone City for China” thread a week ago (starting at http://mm.icann.org/pipermail/tz/2015-July/022480.html <http://mm.icann.org/pipermail/tz/2015-July/022480.html> ). What particularly caught my attention was the discussion about the use of time zone IDs in user interfaces. Paul Eggert: "The string 'Asia/Shanghai' is a tzdata-specific identifier, not intended to be visible to non-experts.” Guy Harris: "Several time zone selectors I've seen are lazily-written crap that either directly display the tzdb name or tweak it slightly by, for example, splitting it into continent and city and displaying them in a more "user-friendly" form.” Guy Harris: “> Looks like this logic is not well understood by the communities. Then we need to do a better job of explaining it to them.” Not to put too fine a point on it… Yes, there needs to be a better job done of explaining that the city names in time zone IDs should not be used in user interfaces. After reading that discussion I went looking through the tzdb files for guidance around the use of IDs in UIs. All I managed to find was this snippet in the Theory file, on line 385: This naming convention is not intended for use by inexperienced users to select TZ values by themselves (though they can of course examine and reuse existing settings). Distributors should provide documentation and/or a simple selection interface that explains the names; see the 'tzselect' program supplied with this distribution for one example. Given that the above snippet is around halfway through the file – and its wording still provides a fair bit of leeway – it’s not exactly enforcing the stronger opinions displayed on this list about how the IDs should be used. For some context, my domain knowledge is restricted to web sites/applications, so I can’t speak to the OS-level discussions in the previous thread. What I do know is how web developers deal with time zones, if they deal with them at all. For the most part, they use a library specific to their language of choice which slightly abstracts the tzdb data. There are two things these libraries have in common: 1. They use tzdb zone identifiers as the primary part of their API. 2. They don’t have any mentions in their documentation that these identifiers are not for public display. This is not me picking on time zone library authors, as I know that some of them are on this mailing list. My main point is that web developers are, for the most part, so abstracted from the tzdb source that the zone IDs are the only interface they know. Therefore the IDs are what they put in their selection UIs. There’s also the not-insignificant matter of localisation of display names (even Moment Timezone, referenced in tz-link.htm, notes in its API documentation: "Because these strings are generally localized, Moment Timezone does not provide any long names for zones.”). Personally, I didn’t know of the existence of CLDR until I started reading this mailing list. So, instead of dismissing zone-IDs-in-a-user-interface as “lazily written crap”, how about we: a) Acknowledge that most web-based UIs for picking time zones are written by developers who genuinely don’t know any better (I count my past self in this category) b) Make an effort to better educate them about recommended uses of the IDs. I am not intending for this to come across as antagonistic or facetious. I just genuinely want the quality of time zone selectors on the web to improve. Cheers, Gil

2 3

[PROPOSED PATCH 1/2] * southamerica: Give source for 1965 Venezuela transition.
by Paul Eggert July 30, 2015

July 30, 2015

--- southamerica | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/southamerica b/southamerica index dcc063f..dd9235f 100644 --- a/southamerica +++ b/southamerica @@ -1734,6 +1734,10 @@ Zone America/Montevideo -3:44:44 - LMT 1898 Jun 28 # Venezuela # +# From Paul Eggert (2015-07-28): +# For the 1965 transition see Gaceta Oficial № 27.619 (1964-12-15), p 205.533 +# http://www.pgr.gob.ve/dmdocuments/1964/27619.pdf +# # From John Stainforth (2007-11-28): # ... the change for Venezuela originally expected for 2007-12-31 has # been brought forward to 2007-12-09. The official announcement was @@ -1745,6 +1749,6 @@ Zone America/Montevideo -3:44:44 - LMT 1898 Jun 28 # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Caracas -4:27:44 - LMT 1890 -4:27:40 - CMT 1912 Feb 12 # Caracas Mean Time? - -4:30 - VET 1965 # Venezuela Time + -4:30 - VET 1965 Jan 1 0:00 # Venezuela T. -4:00 - VET 2007 Dec 9 3:00 -4:30 - VET -- 2.1.4

8 12

Uruguay out of DST
by J J July 24, 2015

July 24, 2015

>> >>* Source: http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambi… <http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambi…> * >> That is a press release published by an organization lobbying for the change, >> and surely such a source is less reliable than the newspapers we're already citing. >> The whole thing is very mysterious, at least to this outsider. Here is the decree signed by the president of Uruguay, on presidency website, http://archivo.presidencia.gub.uy/sci/decretos/2015/06/cons_min_201.pdf

1 0

Uruguay out of DST
by Steffen Thorsen July 23, 2015

July 23, 2015

According to media in Uruguay, it looks like they will not be using DST the coming summer: http://www.elobservador.com.uy/gobierno-resolvio-que-no-habra-cambio-horari… http://www.republica.com.uy/este-ano-no-se-modificara-el-huso-horario-en-ur… It is a bit unclear if this is just this coming summer, or a permanent change. Our English summary (will be updated when we know more details): http://www.timeanddate.com/news/time/uruguay-stops-dst-2015.html Best regards, Steffen Thorsen - timeanddate.com

22 63

Time Zone City for China
by 寇含军 July 23, 2015

July 23, 2015

Dear Sir or Madam, I have a question that bothered me for many years since I started to use the Linux systems. When we, Chinese users, are selecting the desired timezone for our Linux boxes, we always feel weird that there has been no "Asia/Beijing". Instead we see "Asia/Shanghai" or "Asia/Chongqing". This might by how IANA "thinks" what the China timezone convention is, but SERIOUSLY this is not what we, Chinese users, are expecting. We would be very happy to see "Asia/Beijing" among the list. I googled that this question has been asked in many places to different maintainers or distributors, and finally I figured out that IANA is the ultimate upstream who can fix this issue. As a matter of fact, if you take a look at the Windows time zone settings dialog, Beijing is in the list, but no Shanghai. Please add ""Asia/Beijing" to the list. Please take it into consideration and thank you very much! Best Regards, Hanjun Kou, an ordinary Chinese Linux user

7 15

Lack of "initial" transitions for some zones
by Jon Skeet July 22, 2015

July 22, 2015

I suspect this is just a matter of how the data has been specified, but it's a little odd... I'm looking at the output of zic for each zone, and almost all zones start with a "transition" for some timestamp in the long distant past - including fixed zones such as UTC and Etc/*. However, the legacy "root" zones of CET, EET, PST8PDT etc don't have this initial "transition" in the file - unless I'm misinterpreting it, which is always a possibility. Would it make sense to adjust either the data or zic to make all zic output (in the 8-byte-timestamp format, at least) cover all of time? I realize that this "extra" data (presumably an insertion of "standard time until the first transition") may well not be historically accurate - but I doubt that it would be any less accurate than other zones in a similar situation. Jon

4 10

No DST for Uruguay since 2015
by Guillermo Pereyra July 20, 2015

July 20, 2015

http://archivo.presidencia.gub.uy/sci/decretos/2015/06/cons_min_201.pdf

3 2

About the core city of a tz region
by David Patte ₯ July 20, 2015

July 20, 2015

I am curious about the protocol that tz uses to specify the name of each tz region. Is the core city in a region always the most populous city in the tz region? And what is done if a smaller city's population overtakes the named city? Is the zone renamed? Also, since historical data (pre-1970) is now maintained only for the named city in a region, does it not make sense to use the population as of 1970, since the historical records actually affected more people at that time?

4 4

Zone America/Glace_Bay
by Hank W. July 20, 2015

July 20, 2015

I just read in Wikipedia that Glace Bay, Nova Scotia, Canada existed only from 1901 to 1995. The government of Glace Bay was dissolved on 1 Aug 1995 when eight municipalities, including Glace Bay, were consolidated to form Cape Breton (a.k.a. CBRM, short for Cape Breton Regional Municipality), which is currently the second-most populous municipality in Nova Scotia after Halifax. Wikipedia shows Cape Bretons coordinates as 46° 9 north latitude by 60° 10 west longitude. That longitude corresponds to a local mean time of UTC-4:00:40. https://en.wikipedia.org/wiki/Glace_Bay https://en.wikipedia.org/wiki/Cape_Breton_Regional_Municipality Hank Wisniewski of Austin, Texas, U.S.A.

4 6

Type values in rules
by Jon Skeet July 19, 2015

July 19, 2015

Hi folks, It wasn't until last night that I first saw a non "-" entry for a type line - Australia/Adelaide had rules of Rule AS 1990 1994 even Mar Sun>=18 2:00s 0 - Rule AS 1990 1994 odd Mar Sun>=1 2:00s 0 - until release 2000f. Now in Noda Time I could probably support non-infinite rules with a fixed set of types (hopefully just odd and even), but it would be a bit of work. If type values are effectively obsolete, I may not bother. So, is it just coincidence that there have been no uses of the Type field in the released data since 2000f, or is this effectively policy now? (I can understand keeping the functionality for private usage, where others may use zic with their own data sets, but for Noda Time I'm not worried about that. Jon

2 2

Full timezone names
by William Roberts July 19, 2015

July 19, 2015

Hi I'm currently using the tz data that comes with PHP. Is there a way of retrieving the full timezone name from the tz database, eg. Central European Time, Eastern Standard Time etc. So far I haven't been able to, so am using the CLDR repository which assigns a metazone to each timezone from the tz database, and from that I can get the full timezone name but it's not ideal as they don't always match exactly with the abbreviations from the tz data. Are there any plans to enable the full timezone names to be retrieved from the tz database the same way you would the abbreviations in PHP for example, or is getting them from the CLDR repository the best way to go about it? Thanks.

2 1

Re: [tz] Full timezone names
by Matt Johnson July 19, 2015

July 19, 2015

CLDR is indeed the best resource available for full names, particularly due to localization concerns. AFAIK, there is no desire to replicate this in tzdb. Abbreviations are particularly tricky. Not only might they change per language, but there might not be any "real" abbreviation in use by people in the region. ________________________________ From: William Roberts<mailto:wmr501@outlook.com> Sent: ‎7/‎19/‎2015 8:57 PM To: tz(a)iana.org<mailto:tz@iana.org> Subject: [tz] Full timezone names Hi I'm currently using the tz data that comes with PHP. Is there a way of retrieving the full timezone name from the tz database, eg. Central European Time, Eastern Standard Time etc. So far I haven't been able to, so am using the CLDR repository which assigns a metazone to each timezone from the tz database, and from that I can get the full timezone name but it's not ideal as they don't always match exactly with the abbreviations from the tz data. Are there any plans to enable the full timezone names to be retrieved from the tz database the same way you would the abbreviations in PHP for example, or is getting them from the CLDR repository the best way to go about it? Thanks.

1 0

Behaviour in the face of multiple identical rules
by Jon Skeet July 19, 2015

July 19, 2015

This is more of an awareness-raising post than anything else... the data here is very far in the past. While trying to validate Noda Time against zic, I came up against issues with data releases between 1993 and 1996 in Egypt/Cairo. It turns out that this is because the Egypt rule is duplicated in the asia file, and this affects things. As a smallish example, if you create a file called testzone like this: Rule Egypt 1900 only - Oct 1 0:00 0 - > Rule Egypt 1943 1945 - Nov 1 0:00 0 - > Rule Egypt 1945 only - Apr 16 0:00 1:00 " > DST" > Rule Egypt 1957 only - May 10 0:00 1:00 " > DST" > Rule Egypt 1957 1958 - Oct 1 0:00 0 - > Rule Egypt 1958 only - May 1 0:00 1:00 " > DST" > # Rule Egypt 1957 only - May 10 0:00 1:00 " > DST" > > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Africa/Cairo 2:05:00 - LMT 1900 Oct > 2:00 Egypt EET%s ... then execute: $ zic -d . testzone && zdump -v -c 1955,1958 $PWD/Africa/Cairo You'll see output like this for the May 1957 transition: .../Africa/Cairo Thu May 9 21:59:59 1957 UT = Thu May 9 23:59:59 1957 > EET isdst=0 gmtoff=7200 > ...Africa/Cairo Thu May 9 22:00:00 1957 UT = Fri May 10 01:00:00 1957 > EET DST isdst=1 gmtoff=10800 That looks okay - the transition is around midnight, as described. If, however, you uncomment that last "Rule" line above - which is an exact duplicate of the earlier one - you get: .../Africa/Cairo Thu May 9 20:59:59 1957 UT = Thu May 9 22:59:59 1957 > EET isdst=0 gmtoff=7200 > .../Africa/Cairo Thu May 9 21:00:00 1957 UT = Fri May 10 00:00:00 1957 > EET DST isdst=1 gmtoff=10800 Now the transition is one hour earlier. As it happens, this duplicate rule doesn't make any difference to Noda Time - it still emits the first output. I *strongly suspect* that I shouldn't care about this - that situations with duplicate rules should be deemed out of scope for any implementation. However, if anyone can think of any good justification why an implementation *should* behave like zic in this case, I'd be really interested to hear it. (I'm not asking for zic to change here. It already emits a warning because the rule is defined in multiple files, and I think that's good enough.) Jon

3 4

No leap second on 2015-12-31.
by Tim Parenti July 18, 2015

July 18, 2015

Per IERS Bulletin C50 (2015-07-07), no leap second will be observed on 2015-12-31. This patch updates leap-seconds.list from NIST. -- Tim Parenti

2 1

[Announce] C++11 / C++14 IANA Time Zone Database Parser
by Howard Hinnant July 18, 2015

July 18, 2015

http://howardhinnant.github.io/tz.html It is still very early in its development process. It has only been tested on OS X 10.10.4. It requires at least C++11, and prefers C++14. Contributions to making it more portable to reasonable C++11 and beyond platforms are welcomed. Howard

2 5

[PROPOSED PATCH] Fix zdump problem with abbrevs like '-05'
by Paul Eggert July 16, 2015

July 16, 2015

* zdump.c (is_digit): New macro, copied from private.h. (abbrok): Use it. Allow abbreviations that (when quoted) conform to POSIX.1-2001 or later. * NEWS: Document this. --- NEWS | 3 ++- zdump.c | 28 +++++++++++----------------- 2 files changed, 13 insertions(+), 18 deletions(-) diff --git a/NEWS b/NEWS index 498e77b..101a1e5 100644 --- a/NEWS +++ b/NEWS @@ -21,7 +21,8 @@ Unreleased, experimental changes Changes affecting code - zic no longer warns about valid time zone abbreviations like '-05'. + zdump and zic no longer warn about valid time zone abbreviations + like '-05'. Release 2015e - 2015-06-13 10:56:02 -0700 diff --git a/zdump.c b/zdump.c index adb806c..64ff6ce 100644 --- a/zdump.c +++ b/zdump.c @@ -269,6 +269,9 @@ static void show(timezone_t, char *, time_t, bool); static const char *tformat(void); static time_t yeartot(intmax_t) ATTRIBUTE_PURE; +/* Unlike <ctype.h>'s isdigit, this also works if c < 0 | c > UCHAR_MAX. */ +#define is_digit(c) ((unsigned)(c) - '0' <= 9) + /* Is A an alphabetic character in the C locale? */ static bool is_alpha(char a) @@ -485,25 +488,16 @@ abbrok(const char *const abbrp, const char *const zone) if (warned) return; cp = abbrp; - wp = NULL; - while (is_alpha(*cp)) + while (is_alpha(*cp) || is_digit(*cp) || *cp == '-' || *cp == '+') ++cp; - if (cp - abbrp == 0) - wp = _("lacks alphabetic at start"); - else if (cp - abbrp < 3) - wp = _("has fewer than 3 alphabetics"); + if (cp - abbrp < 3) + wp = _("has fewer than 3 characters"); else if (cp - abbrp > 6) - wp = _("has more than 6 alphabetics"); - if (wp == NULL && (*cp == '+' || *cp == '-')) { - ++cp; - if ('0' <= *cp && *cp <= '9') - if (*cp++ == '1' && '0' <= *cp && *cp <= '4') - cp++; - if (*cp != '\0') - wp = _("differs from POSIX standard"); - } - if (wp == NULL) - return; + wp = _("has more than 6 characters"); + else if (*cp) + wp = _("has characters other than ASCII alphanumerics, '-' or '+'"); + else + return; fflush(stdout); fprintf(stderr, _("%s: warning: zone \"%s\" abbreviation \"%s\" %s\n"), -- 2.1.0

1 0