- tz - lists.iana.org

[PROPOSED] Merge some changes from man-pages project
by Paul Eggert June 19, 2018

June 19, 2018

Make some minor formatting changes to be more like man-pages. * tzfile.5: Break a line the same place that man-pages does. * zdump.8, zic.8: Use bold, not italics, for command and function names. Do not capitalize command names. Add a section header OPTIONS. Document --help. Fix some problems with fonts. Don’t quote "SEE ALSO", and don’t mention newctime(3). Put FILES before NOTES, and format a la man-pages. * zic.8: Also, do some fixes of our own, noticed while merging the above. Use real life US Rule, not an invented one. Write “UTOFF”, not “GMTOFF” (man-pages used “UTCOFF” but it’s not necessarily UTC either). Quote more carefully. --- tzfile.5 | 3 +- zdump.8 | 22 ++++++++------ zic.8 | 88 ++++++++++++++++++++++++++++++++------------------------ 3 files changed, 66 insertions(+), 47 deletions(-) diff --git a/tzfile.5 b/tzfile.5 index 13213d2..2e6c3aa 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -181,7 +181,8 @@ use two minor extensions to the POSIX TZ format, as described in .BR newtzset (3). First, the hours part of its transition times may be signed and range from \*-167 through 167 instead of the POSIX-required unsigned values -from 0 through 24. Second, DST is in effect all year if it starts +from 0 through 24. +Second, DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time. .PP diff --git a/zdump.8 b/zdump.8 index 833dd54..92e9e62 100644 --- a/zdump.8 +++ b/zdump.8 @@ -18,16 +18,19 @@ zdump \- time zone dumper .. .ie \n(.g .ds - \f(CW-\fP .el ds - \- -.I Zdump -prints the current time in each +The +.B zdump +program prints the current time in each .I zonename named on the command line. -.PP -These options are available: +.SH OPTIONS .TP -.BI "\*-\*-version" +.B \*-\*-version Output version information and exit. .TP +.B \*-\*-help +Output short usage message and exit. +.TP .B \*-i .I "(This option is experimental: its behavior may change in future versions.)" Output a description of time intervals. For each @@ -68,7 +71,7 @@ except omit the times relative to the extreme time values. This generates output that is easier to compare to that of implementations with different time representations. .TP -.BI "\*-c " [loyear,]hiyear +.BI "\*-c " \fR[\fIloyear , \fR]\fIhiyear Cut off interval output at the given year(s). Cutoff times are computed using the proleptic Gregorian calendar with year 0 and with Universal Time (UT) ignoring leap seconds. @@ -80,7 +83,7 @@ of 1970 includes the transition. The default cutoff is .BR \*-500,2500 . .TP -.BI "\*-t " [lotime,]hitime +.BI "\*-t " \fR[\fIlotime , \fR]\fIhitime Cut off interval output at the given time(s), given in decimal seconds since 1970-01-01 00:00:00 Coordinated Universal Time (UTC). @@ -220,7 +223,8 @@ for newer and .q "UT" for older timestamps, partly because the exact date of the introduction of UTC is problematic. -.SH "SEE ALSO" -newctime(3), tzfile(5), zic(8) +.SH SEE ALSO +.BR tzfile (5), +.BR zic (8) .\" This file is in the public domain, so clarified as of .\" 2009-05-17 by Arthur David Olson. diff --git a/zic.8 b/zic.8 index 00d4267..3e33618 100644 --- a/zic.8 +++ b/zic.8 @@ -28,27 +28,30 @@ zic \- time zone compiler . ds : . ds - \- .\} -.I Zic -reads text from the file(s) named on the command line +The +.B zic +program reads text from the file(s) named on the command line and creates the time conversion information files specified in this input. If a .I filename is .q "\*-" , -the standard input is read. -.PP -These options are available: +standard input is read. +.SH OPTIONS .TP -.BI "\*-\*-version" +.B "\*-\*-version" Output version information and exit. .TP +.B \*-\*-help +Output short usage message and exit. +.TP .BI "\*-d " directory Create time conversion information files in the named directory rather than in the standard directory named below. .TP .BI "\*-l " timezone Use the given time zone as local time. -.I Zic +.B zic will act as if the input contained a link line of the form .sp .ti +.5i @@ -57,7 +60,7 @@ Link \fItimezone\fP localtime .BI "\*-p " timezone Use the given time zone's rules when handling POSIX-format time zone environment variables. -.I Zic +.B zic will act as if the input contained a link line of the form .sp .ti +.5i @@ -80,17 +83,17 @@ The input specifies a link to a link. .PP A year that appears in a data file is outside the range of years representable by -.IR time (2) +.BR time (2) values. .PP A time of 24:00 or more appears in the input. Pre-1998 versions of -.I zic +.B zic prohibit 24:00, and pre-2007 versions prohibit times greater than 24:00. .PP A rule goes past the start or end of the month. Pre-2004 versions of -.I zic +.B zic prohibit this. .PP The output file does not contain all the information about the @@ -102,7 +105,7 @@ represented. .PP The output contains data that may not be handled properly by client code designed for older -.I zic +.B zic output formats. These compatibility issues affect only timestamps before 1970 or after the start of 2038. .PP @@ -148,7 +151,7 @@ to the end of the line the sharp character appears on. White space characters and sharp characters may be enclosed in double quotes (") if they're to be used as part of a field. Any line that is blank (after comment stripping) is ignored. -Non-blank lines are expected to be of one of three types: +Nonblank lines are expected to be of one of three types: rule lines, zone lines, and link lines. .PP Names must be in English and are case insensitive. @@ -165,14 +168,14 @@ abbreviation must be unambiguous in context. A rule line has the form .nf .ti +.5i -.ta \w'Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'1973\0\0'u +\w'TYPE\0\0'u +\w'Apr\0\0'u +\w'lastSun\0\0'u +\w'2:00s\0\0'u +\w'1:00d\0\0'u +.ta \w'Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'1973\0\0'u +\w'TYPE\0\0'u +\w'Apr\0\0'u +\w'lastSun\0\0'u +\w'2:00w\0\0'u +\w'1:00d\0\0'u .sp Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S .sp For example: .ti +.5i .sp -Rule US 1967 1973 \*- Apr lastSun 2:00s 1:00d D +Rule US 1967 1973 \*- Apr lastSun 2:00w 1:00d D .sp .fi The fields that make up a rule line are: @@ -220,7 +223,7 @@ field. should be .q \*- and is present for compatibility with older versions of -.I zic +.B zic in which it could contain year types. .TP .B IN @@ -274,7 +277,7 @@ Recognized forms include: where hour 0 is midnight at the start of the day, and hour 24 is midnight at the end of the day. Although -.I zic +.B zic rounds times to the nearest integer second (breaking ties to the even integer), the fractions may be useful to other applications requiring greater precision. @@ -321,7 +324,7 @@ Negative offsets are allowed; in Ireland, for example, daylight saving time is observed in winter and has a negative offset relative to Irish Standard Time. The offset is merely added to standard time; for example, -.I zic +.B zic does not distinguish a 10:30 standard time plus an 0:30 .B SAVE from a 10:00 standard time plus a 1:00 @@ -347,8 +350,8 @@ A zone line has the form .sp .nf .ti +.5i -.ta \w'Zone\0\0'u +\w'Asia/Amman\0\0'u +\w'GMTOFF\0\0'u +\w'Jordan\0\0'u +\w'FORMAT\0\0'u -Zone NAME GMTOFF RULES FORMAT [UNTIL] +.ta \w'Zone\0\0'u +\w'Asia/Amman\0\0'u +\w'UTOFF\0\0'u +\w'Jordan\0\0'u +\w'FORMAT\0\0'u +Zone NAME UTOFF RULES FORMAT [UNTIL] .sp For example: .sp @@ -357,7 +360,7 @@ Zone Asia/Amman 2:00 Jordan EE%sT 2017 Oct 27 01:00 .sp .fi The fields that make up a zone line are: -.TP "\w'GMTOFF'u" +.TP "\w'UTOFF'u" .B NAME The name of the time zone. This is the name used in creating the time conversion information file for the @@ -369,7 +372,7 @@ or a file name component is a maximal substring that does not contain .q "/" . .TP -.B GMTOFF +.B UTOFF The amount of time to add to UT to get standard time in this zone. This field has the same format as the .B AT @@ -413,7 +416,10 @@ Alternatively, a slash (/) separates standard and daylight abbreviations. To conform to POSIX, a time zone abbreviation should contain only -alphanumeric ASCII characters, "+" and "\*-". +alphanumeric ASCII characters, +.q "+" +and +.q "\*-". .TP .B UNTIL The time at which the UT offset or the rule(s) change for a location. @@ -518,7 +524,7 @@ if the leap second time given by the other fields should be interpreted as local wall clock time. .SH "EXTENDED EXAMPLE" Here is an extended example of -.I zic +.B zic input, intended to illustrate many of its features. In this example, the EU rules are for the European Union and for its predecessor organization, the European Communities. @@ -539,8 +545,8 @@ Rule EU 1979 1995 \*- Sep lastSun 1:00u 0 \*- Rule EU 1981 max \*- Mar lastSun 1:00u 1:00 S Rule EU 1996 max \*- Oct lastSun 1:00u 0 \*- .sp -.ta \w'# Zone\0\0'u +\w'Europe/Zurich\0\0'u +\w'GMTOFF\0\0'u +\w'0:34:08\0\0'u +\w'FORMAT\0\0'u -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +.ta \w'# Zone\0\0'u +\w'Europe/Zurich\0\0'u +\w'0:34:08\0\0'u +\w'RULES\0\0'u +\w'FORMAT\0\0'u +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Zurich 0:34:08 \*- LMT 1853 Jul 16 0:29:46 \*- BMT 1894 Jun 1:00 Swiss CE%sT 1981 @@ -556,8 +562,9 @@ seconds east of UT until 1853-07-16 at 00:00, when the legal offset was changed to 7\(de\|26\(fm\|22.50\(sd; although this works out to 0:29:45.50, the input format cannot represent fractional seconds so it is rounded here. After 1894-06-01 at 00:00 the UT offset became one hour -and Swiss daylight saving rules (defined with lines beginning with "Rule -Swiss") apply. From 1981 to the present, EU daylight saving rules have +and Swiss daylight saving rules (defined with lines beginning with +.q "Rule Swiss") +apply. From 1981 to the present, EU daylight saving rules have applied, and the UTC offset has remained at one hour. .PP In 1941 and 1942, daylight saving time applied from the first Monday @@ -568,11 +575,21 @@ saving has begun on the last Sunday in March at 01:00 UTC. Until 1995 it ended the last Sunday in September at 01:00 UTC, but this changed to the last Sunday in October starting in 1996. .PP -For purposes of -display, "LMT" and "BMT" were initially used, respectively. Since +For purposes of display, +.q "LMT" +and +.q "BMT" +were initially used, respectively. Since Swiss rules and later EU rules were applied, the display name for the time zone has been CET for standard time and CEST for daylight saving time. +.SH FILES +.TP +.I /etc/localtime +Default local time zone file. +.TP +.I /usr/share/zoneinfo +Default time zone information directory. .SH NOTES For areas with more than two types of local time, you may need to use local standard time in the @@ -585,17 +602,14 @@ for a particular zone, a clock advance caused by the start of daylight saving coincides with and is equal to a clock retreat caused by a change in UT offset, -.IR zic +.B zic produces a single transition to daylight saving at the new UT offset (without any change in wall clock time). To get separate transitions use multiple zone continuation lines specifying transition instants using universal time. -.SH FILES -.ta \w'/usr/share/zoneinfo\0\0'u -/etc/localtime default local time zone file -/usr/share/zoneinfo default time zone information directory -.SH "SEE ALSO" -newctime(3), tzfile(5), zdump(8) +.SH SEE ALSO +.BR tzfile (5), +.BR zdump (8) .\" This file is in the public domain, so clarified as of .\" 2009-05-17 by Arthur David Olson. -- 2.17.1

1 0

[PROPOSED] Remove Big Bang hack
by Paul Eggert June 13, 2018

June 13, 2018

The Big Bang hack introduced in 2013d should no longer be needed, now that type 0 is the default type and types are reordered to make this happen. I.e., since we now have a better fix for the Macquarie Island problem reported by Alan Gutierrez in <https://mm.icann.org/pipermail/tz/2013-May/019368.html>, we can revert much of the 2013-05-23 12:19:13 -0700 change “Rework to avoid problem with Australia/Macquarie on 32-bit hosts” and the 2014-05-01 16:32:16 -0700 followup change “zic: improve handling of low-valued time stamps” which caused zic to insert a dummy transition. As a result, zic now generates TZif files that are typically a few bytes shorter, as they were in 2013c and earlier. * Makefile, zic.8: Remove mention of Big Bang. * NEWS: Mention. * zic.c (BIG_BANG, WORK_AROUND_CLIENT_OVERFLOW_BUGS, early_time): Remove. All uses removed. (writezone): New arg DEFAULTTYPE. All callers changed. Simplify by not inserting a dummy transition before the Big Bang. (outzone): Compute default type for use by writezone. (addtt): Don’t second-guess type 0. --- Makefile | 1 - NEWS | 6 +++ zic.8 | 6 --- zic.c | 151 ++++++++++++++++----------------------------------------------- 4 files changed, 44 insertions(+), 120 deletions(-) diff --git a/Makefile b/Makefile index 3705fc0..2289dff 100644 --- a/Makefile +++ b/Makefile @@ -173,7 +173,6 @@ LDLIBS= # Add the following to the end of the "CFLAGS=" line as needed to override # defaults specified in the source code. "-DFOO" is equivalent to "-DFOO=1". -# -DBIG_BANG=-9999999LL if the Big Bang occurred at time -9999999 (see zic.c) # -DDEPRECATE_TWO_DIGIT_YEARS for optional runtime warnings about strftime # formats that generate only the last two digits of year numbers # -DEPOCH_LOCAL if the 'time' function returns local time not UT diff --git a/NEWS b/NEWS index b90e68c..87f675e 100644 --- a/NEWS +++ b/NEWS @@ -27,6 +27,12 @@ Unreleased, experimental changes legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and EET, which previously used nonzero types for these timestamps. + Because of the type 0 change, zic no longer outputs a dummy + transition at time -2**59 (before the Big Bang), as clients should + no longer need this to handle historical timestamps correctly. + This reverts a change introduced in 2013d and shrinks most TZif + files by a few bytes. + localtime.c no longer requires at least one time type in TZif files that lack transitions or have a POSIX-style TZ string. This future-proofs the code against possible future extensions to the diff --git a/zic.8 b/zic.8 index ba4796e..00d4267 100644 --- a/zic.8 +++ b/zic.8 @@ -591,12 +591,6 @@ produces a single transition to daylight saving at the new UT offset To get separate transitions use multiple zone continuation lines specifying transition instants using universal time. -.PP -timestamps well before the Big Bang are silently omitted from the output. -This works around bugs in software that mishandles large negative time -stamps. Call it sour grapes, but pre-Big-Bang timestamps are -physically suspect anyway. The pre-Big-Bang cutoff time is -approximate and may change in future versions. .SH FILES .ta \w'/usr/share/zoneinfo\0\0'u /etc/localtime default local time zone file diff --git a/zic.c b/zic.c index fd73f66..88153db 100644 --- a/zic.c +++ b/zic.c @@ -948,48 +948,6 @@ dolink(char const *fromfield, char const *tofield, bool staysymlink) static zic_t const min_time = MINVAL(zic_t, TIME_T_BITS_IN_FILE); static zic_t const max_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); -/* Estimated time of the Big Bang, in seconds since the POSIX epoch. - rounded downward to the negation of a power of two that is - comfortably outside the error bounds. - - For the time of the Big Bang, see: - - Ade PAR, Aghanim N, Armitage-Caplan C et al. Planck 2013 results. - I. Overview of products and scientific results. - arXiv:1303.5062 2013-03-20 20:10:01 UTC - <https://arxiv.org/pdf/1303.5062v1> [PDF] - - Page 36, Table 9, row Age/Gyr, column Planck+WP+highL+BAO 68% limits - gives the value 13.798 plus-or-minus 0.037 billion years. - Multiplying this by 1000000000 and then by 31557600 (the number of - seconds in an astronomical year) gives a value that is comfortably - less than 2**59, so BIG_BANG is - 2**59. - - BIG_BANG is approximate, and may change in future versions. - Please do not rely on its exact value. */ - -#ifndef BIG_BANG -#define BIG_BANG (- (1LL << 59)) -#endif - -/* If true, work around GNOME glib bug 878 - <https://gitlab.gnome.org/GNOME/glib/issues/878> - by refusing to output timestamps before BIG_BANG. - Such timestamps are physically suspect anyway. - The glib bug is scheduled to be fixed in glib 2.58. - There is a similar bug in 32-bit glibc 2.27 and earlier - <https://sourceware.org/bugzilla/show_bug.cgi?id=19738> - that is scheduled to be fixed in glibc 2.28; - unfortunately a similar bug might persist in 64-bit glibc - though this has not been verified. With all this in mind, - let's hope that the workaround will no longer be needed - in the year 2025. */ -enum { WORK_AROUND_CLIENT_OVERFLOW_BUGS = true }; - -static const zic_t early_time = (WORK_AROUND_CLIENT_OVERFLOW_BUGS - ? BIG_BANG - : MINVAL(zic_t, TIME_T_BITS_IN_FILE)); - /* Return true if NAME is a directory. */ static bool itsdir(char const *name) @@ -1775,7 +1733,8 @@ swaptypes(int i, int j) } static void -writezone(const char *const name, const char *const string, char version) +writezone(const char *const name, const char *const string, char version, + int defaulttype) { register FILE * fp; register ptrdiff_t i, j; @@ -1805,13 +1764,11 @@ writezone(const char *const name, const char *const string, char version) toi = 0; fromi = 0; - while (fromi < timecnt && attypes[fromi].at < early_time) - ++fromi; for ( ; fromi < timecnt; ++fromi) { - if (toi > 1 && ((attypes[fromi].at + + if (toi != 0 && ((attypes[fromi].at + gmtoffs[attypes[toi - 1].type]) <= - (attypes[toi - 1].at + - gmtoffs[attypes[toi - 2].type]))) { + (attypes[toi - 1].at + gmtoffs[toi == 1 ? 0 + : attypes[toi - 2].type]))) { attypes[toi - 1].type = attypes[fromi].type; continue; @@ -1919,8 +1876,8 @@ writezone(const char *const name, const char *const string, char version) for (pass = 1; pass <= 2; ++pass) { register ptrdiff_t thistimei, thistimecnt, thistimelim; register int thisleapi, thisleapcnt, thisleaplim; - int old0, new0; - char omittype[TZ_MAX_TYPES + 1]; + int old0; + char omittype[TZ_MAX_TYPES]; int typemap[TZ_MAX_TYPES]; register int thistypecnt; char thischars[TZ_MAX_CHARS]; @@ -1945,45 +1902,17 @@ writezone(const char *const name, const char *const string, char version) error(_("too many transition times")); thistimelim = thistimei + thistimecnt; thisleaplim = thisleapi + thisleapcnt; - memset(omittype, thistimecnt != timecnt, typecnt); - if (thistimecnt == 0) { - /* - ** No transition times fall in the current - ** (32- or 64-bit) window. - */ - if (typecnt != 0) - omittype[typecnt - 1] = false; - } else { - for (i = thistimei - 1; i < thistimelim; ++i) - if (i >= 0) - omittype[types[i]] = false; - /* - ** For America/Godthab and Antarctica/Palmer - */ - if (thistimei == 0) - omittype[0] = false; - } - - /* Reorder types to make type 0 the first-used standard type - if one is used, otherwise the first-used DST type if one - is used, otherwise no reordering. Use TYPEMAP to swap - OLD0 and NEW0 so that NEW0 appears as type 0 in the output - instead of OLD0. TYPEMAP also omits unused types. */ - omittype[typecnt] = false; /* strlen sentinel */ + memset(omittype, true, typecnt); + omittype[defaulttype] = false; + for (i = thistimei; i < thistimelim; i++) + omittype[types[i]] = false; + + /* Reorder types to make DEFAULTTYPE type 0. + Use TYPEMAP to swap OLD0 and DEFAULTTYPE so that + DEFAULTTYPE appears as type 0 in the output instead + of OLD0. TYPEMAP also omits unused types. */ old0 = strlen(omittype); - new0 = -1; - for (i = 0; i < timecnt; i++) - if (!omittype[types[i]]) { - if (! isdsts[types[i]]) { - new0 = types[i]; - break; - } - if (new0 < 0) - new0 = types[i]; - } - if (new0 < 0) - new0 = old0; - swaptypes(old0, new0); + swaptypes(old0, defaulttype); #ifndef LEAVE_SOME_PRE_2011_SYSTEMS_IN_THE_LURCH /* @@ -2035,7 +1964,8 @@ writezone(const char *const name, const char *const string, char version) thistypecnt = 0; for (i = old0; i < typecnt; i++) if (!omittype[i]) - typemap[i == old0 ? new0 : i == new0 ? old0 : i] + typemap[i == old0 ? defaulttype + : i == defaulttype ? old0 : i] = thistypecnt++; for (i = 0; i < sizeof indmap / sizeof indmap[0]; ++i) @@ -2133,7 +2063,7 @@ writezone(const char *const name, const char *const string, char version) for (i = old0; i < typecnt; i++) if (!omittype[i]) putc(ttisgmts[i], fp); - swaptypes(old0, new0); + swaptypes(old0, defaulttype); } fprintf(fp, "\n%s\n", string); close_file(fp, directory, name); @@ -2487,6 +2417,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) zic_t one = 1; zic_t y2038_boundary = one << 31; zic_t max_year0; + int defaulttype = -1; max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; @@ -2595,9 +2526,9 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) */ stdoff = 0; zp = &zpfirst[i]; - usestart = i > 0 && (zp - 1)->z_untiltime > early_time; + usestart = i > 0 && (zp - 1)->z_untiltime > min_time; useuntil = i < (zonecount - 1); - if (useuntil && zp->z_untiltime <= early_time) + if (useuntil && zp->z_untiltime <= min_time) continue; gmtoff = zp->z_gmtoff; eat(zp->z_filename, zp->z_linenum); @@ -2612,7 +2543,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) if (usestart) { addtt(starttime, type); usestart = false; - } else addtt(early_time, type); + } else + defaulttype = type; } else for (year = min_year; year <= max_year; ++year) { if (useuntil && year > zp->z_untilrule.r_hiyear) break; @@ -2726,6 +2658,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) offset = oadd(zp->z_gmtoff, rp->r_stdoff); type = addtype(offset, ab, rp->r_isdst, rp->r_todisstd, rp->r_todisgmt); + if (defaulttype < 0 && !rp->r_isdst) + defaulttype = type; if (rp->r_hiyear == ZIC_MAX && ! (0 <= lastatmax && ktime < attypes[lastatmax].at)) @@ -2742,11 +2676,14 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) eat(zp->z_filename, zp->z_linenum); if (*startbuf == '\0') error(_("can't determine time zone abbreviation to use just after until time")); - else addtt(starttime, - addtype(startoff, startbuf, - startoff != zp->z_gmtoff, - startttisstd, - startttisgmt)); + else { + bool isdst = startoff != zp->z_gmtoff; + type = addtype(startoff, startbuf, isdst, + startttisstd, startttisgmt); + if (defaulttype < 0 && !isdst) + defaulttype = type; + addtt(starttime, type); + } } /* ** Now we may get to set starttime for the next zone line. @@ -2761,6 +2698,8 @@ error(_("can't determine time zone abbreviation to use just after until time")); starttime = tadd(starttime, -gmtoff); } } + if (defaulttype < 0) + defaulttype = 0; if (0 <= lastatmax) attypes[lastatmax].dontmerge = true; if (do_extend) { @@ -2788,7 +2727,7 @@ error(_("can't determine time zone abbreviation to use just after until time")); attypes[timecnt - 1].dontmerge = true; } } - writezone(zpfirst->z_name, envvar, version); + writezone(zpfirst->z_name, envvar, version, defaulttype); free(startbuf); free(ab); free(envvar); @@ -2797,20 +2736,6 @@ error(_("can't determine time zone abbreviation to use just after until time")); static void addtt(zic_t starttime, int type) { - if (starttime <= early_time - || (timecnt == 1 && attypes[0].at < early_time)) { - gmtoffs[0] = gmtoffs[type]; - isdsts[0] = isdsts[type]; - ttisstds[0] = ttisstds[type]; - ttisgmts[0] = ttisgmts[type]; - if (abbrinds[type] != 0) - strcpy(chars, &chars[abbrinds[type]]); - abbrinds[0] = 0; - charcnt = strlen(chars) + 1; - typecnt = 1; - timecnt = 0; - type = 0; - } attypes = growalloc(attypes, sizeof *attypes, timecnt, &timecnt_alloc); attypes[timecnt].at = starttime; attypes[timecnt].dontmerge = false; -- 2.7.4

1 0

[PROPOSED] GNOME glib bug fix installed
by Paul Eggert June 13, 2018

June 13, 2018

The bug fix was merged into glib master today. Since it’s four years after the fix was proposed (!), push back an estimate of when we can remove the workaround. Also, adjust to GNOME bug renumbering. * NEWS: Adjust bug number in history. * zic.c (WORK_AROUND_GLIB_BUG_878): Rename from WORK_AROUND_GNOME_BUG_730332. All uses changed. --- NEWS | 4 ++-- zic.c | 14 +++++++------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 34f7810..b90e68c 100644 --- a/NEWS +++ b/NEWS @@ -2106,8 +2106,8 @@ Release 2014d - 2014-05-27 21:34:40 -0700 Changes affecting code zic no longer generates files containing timestamps before the Big Bang. - This works around GNOME bug 730332 - <https://bugzilla.gnome.org/show_bug.cgi?id=730332>. + This works around GNOME glib bug 878 + <https://gitlab.gnome.org/GNOME/glib/issues/878> (Thanks to Leonardo Chiquitto for reporting the bug, and to Arthur David Olson and James Cloos for suggesting improvements to the fix.) diff --git a/zic.c b/zic.c index ce9ccaf..9e25b02 100644 --- a/zic.c +++ b/zic.c @@ -972,17 +972,17 @@ static zic_t const max_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); #define BIG_BANG (- (1LL << 59)) #endif -/* If true, work around GNOME bug 730332 - <https://bugzilla.gnome.org/show_bug.cgi?id=730332> +/* If true, work around GNOME glib bug 878 + <https://gitlab.gnome.org/GNOME/glib/issues/878> by refusing to output timestamps before BIG_BANG. Such timestamps are physically suspect anyway. - The GNOME bug is scheduled to be fixed in GNOME 3.22, and if so - this workaround will no longer be needed when GNOME 3.21 and - earlier are obsolete, say in the year 2021. */ -enum { WORK_AROUND_GNOME_BUG_730332 = true }; + The glib bug is scheduled to be fixed in glib 2.58, and if so + this workaround will no longer be needed when glib 2.57 and + earlier are obsolete, say in the year 2025. */ +enum { WORK_AROUND_GLIB_BUG_878 = true }; -static const zic_t early_time = (WORK_AROUND_GNOME_BUG_730332 +static const zic_t early_time = (WORK_AROUND_GLIB_BUG_878 ? BIG_BANG : MINVAL(zic_t, TIME_T_BITS_IN_FILE)); -- 2.17.1

2 2

Clarification on LMT entries
by Matt Johnson June 8, 2018

June 8, 2018

Quick question. The entry for Europe/Kiev has two solar mean time entries: Zone Europe/Kiev 2:02:04 - LMT 1880 2:02:04 - KMT 1924 May 2 # Kiev Mean Time While I know how to read this, I'm not sure why the abbreviation KMT exists. Is this another invented abbreviation, or is there a source? Also, why 1880 on the LMT line? What is special about 1880? Thanks, Matt

4 3

Secure FTP support for IANA downloads
by pbassey＠ups.com June 6, 2018

June 6, 2018

Hello, I am writing to inquire about your site's use of FTP and the possibility of migrating over to Secure FTP in order to comply with our company's security compliance requirements. Does your site offer Secure FTP for your IANA downloads and if not, what would it take to enable this protocol so our company could securely download your files? Currently, we use this URL to download the IANA time zone files which is not secure: ftp://ftp.iana.org/tz/ Thank you in advance for your help. Regards, Peter Bassey Peter A. Bassey Enterprise Business Intelligence UPS 340 MacArthur Blvd Mahwah, NJ 07430 Phone: 201-828-7847 Mobile: 845-662-3743 pbassey(a)ups.com<mailto:pbassey@ups.com>

6 6

On solving the tzdata changes problem
by Aldrin Martoq Ahumada June 5, 2018

June 5, 2018

Hello, I think we can semi-automate when a tzdata change occurs in software, given the following: 1. Your software stores all dates as unix timestamps (seconds since the epoch, “ignoring” leap seconds). 2. Your system (or users) choose a local representation using an oficial timezone, like ‘America/Santiago’. 3. Your system stores somewhere what version of tzdata is currently being used, like ‘2018e’. So, when a new version of tzdata is released (say ‘2018f’), the sysadmin updates their tzdata packages, and then runs a tool that checks for every timezone used (‘America/Santiago’ for ex) if there are changes that could affect users between 2018e and 2018f. The typical example: my dentist appointment is not correct anymore. So, your system may ask the user: “There have been changes in the timezone where you live, would you like to review this 3 appointments and check if they are still correct?" The problem is that there is no historical data of tzdata: when a sysadmin updates the system, it gets a new version 2018f, but there is no automatic way of knowing the differences. I didn’t find one, so I wrote it. A web app that demo this concept is here: https://a0.github.io/a0-tzmigration/demo/ <https://a0.github.io/a0-tzmigration/demo/> You can even share the url, for example here is the diff between America/Santiago 2016j and America/Punta_Arenas 2017a: https://a0.github.io/a0-tzmigration/demo/?ta=America%2FSantiago&va=2016j&tb… <https://a0.github.io/a0-tzmigration/demo/?ta=America/Santiago&va=2016j&tb=A…> This can automate many issues we all have when updating tzdata. For the link above, a whole region of my country switched so the new America/Punta_Arenas timezone was created. You can easily spot errors, too: the America/Punta_Arenas should be equal to America/Santiago up to 2017, but there are differences in the years 1890, 1946. And you can do this, in your own systems, using the same data, which is here: https://a0.github.io/a0-tzmigration-ruby/data/ <https://a0.github.io/a0-tzmigration-ruby/data/>. It’s not perfect. It probably has errors. I generated it from the ruby tzinfo-data gem, which has info only from 2013c onwards, and transitions up to ≈ 2068 (50 years from now). Use with caution, happy to accept corrections. I’m writing a ruby gem and an npm package, would love to see other language implementations: https://github.com/a0/a0-tzmigration-ruby <https://github.com/a0/a0-tzmigration-ruby> https://github.com/a0/a0-tzmigration-js <https://github.com/a0/a0-tzmigration-js> API is not really stable, will check and release documentation next week, but the core idea is there: grab the JSON files from our github page and get the changes that MAY have to be applied. I’m writing a medium blog post to cover all of this. Hope that this help all of you, and happy to listen any suggestions or corrections. Cheers, — Aldrin.

5 6

[PROPOSED 1/3] Don’t reject TZif TZ strings that lack DST
by Paul Eggert June 5, 2018

June 5, 2018

* NEWS: Mention this. * localtime.c (tzloadbody): Don’t require a TZif file’s POSIX TZ string to specify DST. That way, the TZ string consistently overrides the type of the TZif file’s last transition, instead of overriding only when specifying DST. Although this currently matters only for invalid TZif files where the TZ string disagrees with the last transition’s time type, it will become more important if we stop requiring at least one time type in the binary data, as the TZ string will then be the only source for time types. --- NEWS | 6 ++++++ localtime.c | 11 +++++------ 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index ce009e7..2e9bf99 100644 --- a/NEWS +++ b/NEWS @@ -27,6 +27,12 @@ Unreleased, experimental changes legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and EET, which previously used nonzero types for these timestamps. + localtime.c no longer ignores TZif POSIX-style TZ strings that + specify only standard time. Instead, these TZ strings now + override the default time type for timestamps after the last + transition (or for all time stamps if there are no transitions), + just as DST strings specifying DST have always done. + Changes to documentation New restrictions: A Rule name must start with a character that diff --git a/localtime.c b/localtime.c index 21160c0..5a3fe91 100644 --- a/localtime.c +++ b/localtime.c @@ -587,8 +587,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, struct state *ts = &lsp->u.st; up->buf[nread - 1] = '\0'; - if (tzparse(&up->buf[1], ts, false) - && ts->typecnt == 2) { + if (tzparse(&up->buf[1], ts, false)) { /* Attempt to reuse existing abbreviations. Without this, America/Anchorage would be right on @@ -599,7 +598,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, stay 40 in this example. */ int gotabbr = 0; int charcnt = sp->charcnt; - for (i = 0; i < 2; i++) { + for (i = 0; i < ts->typecnt; i++) { char *tsabbr = ts->chars + ts->ttis[i].tt_abbrind; int j; for (j = 0; j < charcnt; j++) @@ -618,7 +617,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, } } } - if (gotabbr == 2) { + if (gotabbr == ts->typecnt) { sp->charcnt = charcnt; /* Ignore any trailing, no-op transitions generated @@ -640,8 +639,8 @@ tzloadbody(char const *name, struct state *sp, bool doextend, sp->timecnt++; i++; } - sp->ttis[sp->typecnt++] = ts->ttis[0]; - sp->ttis[sp->typecnt++] = ts->ttis[1]; + for (i = 0; i < ts->typecnt; i++) + sp->ttis[sp->typecnt++] = ts->ttis[i]; } } } -- 2.17.1

1 2

UTC is enough for everyone, right?
by Philip Paeps June 4, 2018

June 4, 2018

I've just read this amusing introduction to the vagaries of dealing with time. A fun read. https://zachholman.com/talk/utc-is-enough-for-everyone-right I've not watched the accompanying presentations but the article is quite insightful. May merit inclusion in tz-link.html? Philip -- Philip Paeps Senior Reality Engineer Ministry of Information

1 0

[PROPOSED] Use type 0 for timestamps before first transition
by Paul Eggert June 3, 2018

June 3, 2018

I ran into this problem when helping to draft: https://tools.ietf.org/html/draft-murchison-tzdist-tzif-04 Its section 3.2 gives a complex four-step procedure for determining the type of timestamps before the first transition, derived from 2018e localtime.c. However, I just now checked, and glibc does only the last two steps. Furthermore, in practice nowadays only the last step is needed in almost all zones, because type 0 is almost always the right type to use; the only exceptions are the legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and EET. As the tzif-04 section 3.2 procedure is only for backward compatibility with older TZif files, now is a good time to clean up by specifying a simple way to deal with time stamps before the first transition, namely, to use time type 0. So, this patch changes zic so that the first-used standard time type (if there is one) is always time type 0. This is compatible with glibc and with any other program that uses the heuristic of using the lowest-numbered standard-time time type for timestamps before the first transition, since it merely changes zic to output a standard-time type 0. * NEWS, tzfile.5: Document this. * localtime.c (tzparse): Make standard time type 0, if standard time is in use. This should help future-proof this program if we ever get rid of the defaulttype member and just use 0. * zic.c (swaptypes): New function. (writezone): Reorder types to make type 0 the default type. Negate the local variable writetypes into omittypes, so that strlen can be used on it, and enlarge it by 1 to make room for a sentinel. Use memset where appropriate. --- NEWS | 13 +++++++++ localtime.c | 43 ++++++++++++++++++++++-------- tzfile.5 | 17 ++++++++---- zic.c | 77 +++++++++++++++++++++++++++++++++++++++-------------- 4 files changed, 114 insertions(+), 36 deletions(-) diff --git a/NEWS b/NEWS index 0ef70a1..ce009e7 100644 --- a/NEWS +++ b/NEWS @@ -17,6 +17,16 @@ Unreleased, experimental changes observed DST in 1942/79, not 1961/80, and there were several errors for transition times and dates. (Thanks to P Chan.) + Changes to code + + zic now always generates TZif files where time type 0 is used for + timestamps before the first transition. This simplifies the + reading of TZif files and should not affect behavior of existing + TZif readers because the same set of time types is used; only + their internal indexes may have changed. This affects only the + legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and + EET, which previously used nonzero types for these timestamps. + Changes to documentation New restrictions: A Rule name must start with a character that @@ -25,6 +35,9 @@ Unreleased, experimental changes The latter restriction makes room for future extensions (a possibility noted by Tom Lane). + tzfile.5 now documents what time types apply before the first and + after the last transition, if any. + The name "TZif" is now used for the tz binary data format. tz-link.htm now mentions the A0 TimeZone Migration utilities. diff --git a/localtime.c b/localtime.c index 5b5a5b1..21160c0 100644 --- a/localtime.c +++ b/localtime.c @@ -131,7 +131,11 @@ struct state { char chars[BIGGEST(BIGGEST(TZ_MAX_CHARS + 1, sizeof gmt), (2 * (MY_TZNAME_MAX + 1)))]; struct lsinfo lsis[TZ_MAX_LEAPS]; - int defaulttype; /* for early times or if no transitions */ + + /* The time type to use for early times or if no transitions. + It is always zero for recent tzdb releases. + It might be nonzero for data from tzdb 2018e or earlier. */ + int defaulttype; }; enum r_type { @@ -657,6 +661,17 @@ tzloadbody(char const *name, struct state *sp, bool doextend, break; } } + + /* Infer sp->defaulttype from the data. Although this default + type is always zero for data from recent tzdb releases, + things are trickier for data from tzdb 2018e or earlier. + + The first set of heuristics work around bugs in 32-bit data + generated by tzdb 2013c or earlier. The workaround is for + zones like Australia/Macquarie where timestamps before the + first transition have a time type that is not the earliest + standard-time type. See: + https://mm.icann.org/pipermail/tz/2013-May/019368.html */ /* ** If type 0 is unused in transitions, ** it's the type to use for early times. @@ -678,6 +693,9 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (!sp->ttis[i].tt_isdst) break; } + /* The next heuristics are for data generated by tzdb 2018e or + earlier, for zones like EST5EDT where the first transition + is to DST. */ /* ** If no result yet, find the first standard type. ** If there is none, punt to type zero. @@ -690,7 +708,12 @@ tzloadbody(char const *name, struct state *sp, bool doextend, break; } } + /* A simple 'sp->defaulttype = 0;' would suffice here if we + didn't have to worry about 2018e-or-earlier data. Even + simpler would be to remove the defaulttype member and just + use 0 in its place. */ sp->defaulttype = i; + return 0; } @@ -1115,8 +1138,8 @@ tzparse(const char *name, struct state *sp, bool lastditch) /* ** Two transitions per year, from EPOCH_YEAR forward. */ - init_ttinfo(&sp->ttis[0], -dstoffset, true, stdlen + 1); - init_ttinfo(&sp->ttis[1], -stdoffset, false, 0); + init_ttinfo(&sp->ttis[0], -stdoffset, false, 0); + init_ttinfo(&sp->ttis[1], -dstoffset, true, stdlen + 1); sp->defaulttype = 0; timecnt = 0; janfirst = 0; @@ -1157,17 +1180,14 @@ tzparse(const char *name, struct state *sp, bool lastditch) if (! increment_overflow_time (&sp->ats[timecnt], janoffset + starttime)) - sp->types[timecnt++] = reversed; - else if (janoffset) - sp->defaulttype = reversed; + sp->types[timecnt++] = !reversed; sp->ats[timecnt] = janfirst; if (! increment_overflow_time (&sp->ats[timecnt], janoffset + endtime)) { - sp->types[timecnt++] = !reversed; + sp->types[timecnt++] = reversed; yearlim = year + YEARSPERREPEAT + 1; - } else if (janoffset) - sp->defaulttype = !reversed; + } } if (increment_overflow_time (&janfirst, janoffset + yearsecs)) @@ -1175,9 +1195,10 @@ tzparse(const char *name, struct state *sp, bool lastditch) janoffset = 0; } sp->timecnt = timecnt; - if (! timecnt) + if (! timecnt) { + sp->ttis[0] = sp->ttis[1]; sp->typecnt = 1; /* Perpetual DST. */ - else if (YEARSPERREPEAT < year - yearbeg) + } else if (YEARSPERREPEAT < year - yearbeg) sp->goback = sp->goahead = true; } else { register int_fast32_t theirstdoffset; diff --git a/tzfile.5 b/tzfile.5 index 530397f..13213d2 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -70,7 +70,9 @@ at which the rules for computing local time change. one-byte unsigned integer values; each one tells which of the different types of local time types described in the file is associated with the time period -starting with the same-indexed transition time. +starting with the same-indexed transition time +and continuing up to but not including the next transition time +(or continuing for one second, if this is the last transition). These values serve as indices into the next field. .IP * .I tzh_typecnt @@ -159,15 +161,20 @@ eight bytes are used for each transition time or leap second time. After the second header and data comes a newline-enclosed, POSIX-TZ-environment-variable-style string for use in handling instants after the last transition time stored in the file -(with nothing between the newlines if there is no POSIX representation for -such instants). -The POSIX-style string must agree with the local time type after -both data's last transition times; for example, given the string +or for all instants if the file has no transitions. +The POSIX-style TZ string is empty (i.e., nothing between the newlines) +if there is no POSIX representation for such instants. +If nonempty, the POSIX-style TZ string must agree with the local time +type after both data's last transition times if present; +for example, given the string .q "WET0WEST,M3.5.0,M10.5.0/3" then if a last transition time is in July, the transition's local time type must specify a daylight-saving time abbreviated .q "WEST" that is one hour east of UT. +Also, if there is at least one transition, time type 0 is associated +with the time period from the indefinite past up to but not including +the earliest transition time. .SS Version 3 format For version-3-format time zone files, the POSIX-TZ-style string may use two minor extensions to the POSIX TZ format, as described in diff --git a/zic.c b/zic.c index 679b3e2..ce9ccaf 100644 --- a/zic.c +++ b/zic.c @@ -1759,6 +1759,17 @@ is32(const zic_t x) return INT32_MIN <= x && x <= INT32_MAX; } +static void +swaptypes(int i, int j) +{ + { zic_t t = gmtoffs[i]; gmtoffs[i] = gmtoffs[j]; gmtoffs[j] = t; } + { char t = isdsts[i]; isdsts[i] = isdsts[j]; isdsts[j] = t; } + { unsigned char t = abbrinds[i]; abbrinds[i] = abbrinds[j]; + abbrinds[j] = t; } + { bool t = ttisstds[i]; ttisstds[i] = ttisstds[j]; ttisstds[j] = t; } + { bool t = ttisgmts[i]; ttisgmts[i] = ttisgmts[j]; ttisgmts[j] = t; } +} + static void writezone(const char *const name, const char *const string, char version) { @@ -1904,7 +1915,8 @@ writezone(const char *const name, const char *const string, char version) for (pass = 1; pass <= 2; ++pass) { register ptrdiff_t thistimei, thistimecnt, thistimelim; register int thisleapi, thisleapcnt, thisleaplim; - int writetype[TZ_MAX_TYPES]; + int old0, new0; + char omittype[TZ_MAX_TYPES + 1]; int typemap[TZ_MAX_TYPES]; register int thistypecnt; char thischars[TZ_MAX_CHARS]; @@ -1929,25 +1941,46 @@ writezone(const char *const name, const char *const string, char version) error(_("too many transition times")); thistimelim = thistimei + thistimecnt; thisleaplim = thisleapi + thisleapcnt; - for (i = 0; i < typecnt; ++i) - writetype[i] = thistimecnt == timecnt; + memset(omittype, thistimecnt != timecnt, typecnt); if (thistimecnt == 0) { /* ** No transition times fall in the current ** (32- or 64-bit) window. */ if (typecnt != 0) - writetype[typecnt - 1] = true; + omittype[typecnt - 1] = false; } else { for (i = thistimei - 1; i < thistimelim; ++i) if (i >= 0) - writetype[types[i]] = true; + omittype[types[i]] = false; /* ** For America/Godthab and Antarctica/Palmer */ if (thistimei == 0) - writetype[0] = true; + omittype[0] = false; } + + /* Reorder types to make type 0 the first-used standard type + if one is used, otherwise the first-used DST type if one + is used, otherwise no reordering. Use TYPEMAP to swap + OLD0 and NEW0 so that NEW0 appears as type 0 in the output + instead of OLD0. TYPEMAP also omits unused types. */ + omittype[typecnt] = false; /* strlen sentinel */ + old0 = strlen(omittype); + new0 = -1; + for (i = 0; i < timecnt; i++) + if (!omittype[types[i]]) { + if (! isdsts[types[i]]) { + new0 = types[i]; + break; + } + if (new0 < 0) + new0 = types[i]; + } + if (new0 < 0) + new0 = old0; + swaptypes(old0, new0); + #ifndef LEAVE_SOME_PRE_2011_SYSTEMS_IN_THE_LURCH /* ** For some pre-2011 systems: if the last-to-be-written @@ -1965,8 +1998,8 @@ writezone(const char *const name, const char *const string, char version) if (isdsts[types[i]]) mrudst = types[i]; else mrustd = types[i]; - for (i = 0; i < typecnt; ++i) - if (writetype[i]) { + for (i = old0; i < typecnt; i++) + if (!omittype[i]) { if (isdsts[i]) hidst = i; else histd = i; @@ -1980,7 +2013,7 @@ writezone(const char *const name, const char *const string, char version) ttisstds[mrudst], ttisgmts[mrudst]); isdsts[mrudst] = 1; - writetype[type] = true; + omittype[type] = false; } if (histd >= 0 && mrustd >= 0 && histd != mrustd && gmtoffs[histd] != gmtoffs[mrustd]) { @@ -1991,20 +2024,23 @@ writezone(const char *const name, const char *const string, char version) ttisstds[mrustd], ttisgmts[mrustd]); isdsts[mrustd] = 0; - writetype[type] = true; + omittype[type] = false; } } #endif /* !defined LEAVE_SOME_PRE_2011_SYSTEMS_IN_THE_LURCH */ thistypecnt = 0; - for (i = 0; i < typecnt; ++i) - typemap[i] = writetype[i] ? thistypecnt++ : -1; + for (i = old0; i < typecnt; i++) + if (!omittype[i]) + typemap[i == old0 ? new0 : i == new0 ? old0 : i] + = thistypecnt++; + for (i = 0; i < sizeof indmap / sizeof indmap[0]; ++i) indmap[i] = -1; thischarcnt = 0; - for (i = 0; i < typecnt; ++i) { + for (i = old0; i < typecnt; i++) { register char * thisabbr; - if (!writetype[i]) + if (omittype[i]) continue; if (indmap[abbrinds[i]] >= 0) continue; @@ -2053,8 +2089,8 @@ writezone(const char *const name, const char *const string, char version) uc = typemap[types[i]]; fwrite(&uc, sizeof uc, 1, fp); } - for (i = 0; i < typecnt; ++i) - if (writetype[i]) { + for (i = old0; i < typecnt; i++) + if (!omittype[i]) { puttzcode(gmtoffs[i], fp); putc(isdsts[i], fp); putc((unsigned char) indmap[abbrinds[i]], fp); @@ -2087,12 +2123,13 @@ writezone(const char *const name, const char *const string, char version) else puttzcode64(todo, fp); puttzcode(corr[i], fp); } - for (i = 0; i < typecnt; ++i) - if (writetype[i]) + for (i = old0; i < typecnt; i++) + if (!omittype[i]) putc(ttisstds[i], fp); - for (i = 0; i < typecnt; ++i) - if (writetype[i]) + for (i = old0; i < typecnt; i++) + if (!omittype[i]) putc(ttisgmts[i], fp); + swaptypes(old0, new0); } fprintf(fp, "\n%s\n", string); close_file(fp, directory, name); -- 2.17.1

1 0

[PROPOSED] zic performance tweak for wide-ranging years
by Paul Eggert June 1, 2018

June 1, 2018

* zic.c (rpytime): Improve performance when the year is outlandishly small or large. --- zic.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/zic.c b/zic.c index 7c04435..679b3e2 100644 --- a/zic.c +++ b/zic.c @@ -3141,6 +3141,15 @@ rpytime(const struct rule *rp, zic_t wantedy) dayoff = 0; m = TM_JANUARY; y = EPOCH_YEAR; + if (y < wantedy) { + wantedy -= y; + dayoff = (wantedy / YEARSPERREPEAT) * (SECSPERREPEAT / SECSPERDAY); + wantedy %= YEARSPERREPEAT; + wantedy += y; + } else if (wantedy < 0) { + dayoff = (wantedy / YEARSPERREPEAT) * (SECSPERREPEAT / SECSPERDAY); + wantedy %= YEARSPERREPEAT; + } while (wantedy != y) { if (wantedy > y) { i = len_years[isleap(y)]; -- 2.17.0

1 0

[PROPOSED] * Makefile ($(ALL_ASC)): Switch to gpg2.
by Paul Eggert June 1, 2018

June 1, 2018

--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 389a6db..3705fc0 100644 --- a/Makefile +++ b/Makefile @@ -978,7 +978,7 @@ tzdata$(VERSION).tar.gz.asc: tzdata$(VERSION).tar.gz tzdata$(VERSION)-rearguard.tar.gz.asc: tzdata$(VERSION)-rearguard.tar.gz tzdb-$(VERSION).tar.lz.asc: tzdb-$(VERSION).tar.lz $(ALL_ASC): - gpg --armor --detach-sign $? + gpg2 --armor --detach-sign $? typecheck: $(MAKE) clean -- 2.17.0

1 0

wrong Europe/Dublin dst offset rule
by Vicky May 30, 2018

May 30, 2018

Hi, while parsing the data i found the issue in rule Europe/Dublin Negative DST.. Previous version or not in any other file there is no negative dst. DST either start and end . # The following is like GB-Eire and EU, except with standard time in # summer and negative daylight saving time in winter. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 GMT Rule Eire 1981 max - Mar lastSun 1:00u 0 IST Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 GMT Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 GMT Rule Eire 1996 max - Oct lastSun 1:00u -1:00 GMT Please explain why -ve dst offset compared with other files. Regards, Vaibhav

5 6

[PROPOSED 1/3] * tz-link.html: Macao → Macau
by Paul Eggert May 28, 2018

May 28, 2018

--- tz-link.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tz-link.html b/tz-link.html index 508a1f1..d307bf7 100644 --- a/tz-link.html +++ b/tz-link.html @@ -754,8 +754,8 @@ hreflang="he">announcements (in Hebrew)</a>.</dd> <dd>The National Institute of Metrological Research maintains a <a href="http://www.nanospin.eu/res/tf/ora_legale_i.shtml">table of civil time (in Italian)</a>.</dd> -<dt>Macao</dt> -<dd>The Macao Meteorological and Geophysical Bureau maintains a +<dt>Macau</dt> +<dd>The Meteorological and Geophysical Bureau maintains a <a href="http://www.smg.gov.mo/smg/geophysics/e_t_Summer%20Time.htm">history of summer time</a>. Unfortunately it is incomplete and has errors.</dd> <dt>Malaysia</dt> -- 2.17.0

1 2

Asia\Nicosia
by GsaTitanium May 26, 2018

May 26, 2018

Hello, i am writing to you about an issue with Nicosia the capital of Cyprus. Cyprus is an EU member since May 1st 2004 which makes it a European country but you have it as an Asia Continent Country. Before May 1st 2004 Cyprus had Asia Timezone but since then we have Eastern European Time and we have also adopted the Eastern European Summer Time. Basically you representation of Nicosia as UTC+2 and UTC+3 (in summer) time is correct but in the wrong Continent. Cyprus as a European Union Member: https://europa.eu/european-union/about-eu/countries/member-countries/cyprus… Map of Europe Union including Cyprus: https://europa.eu/european-union/about-eu/countries_en?country=CY#map Waiting for you reply Thank you GsaTitanium

9 11

[PROPOSED 1/2] * tz-link.html: Update tzdist URLs.
by Paul Eggert May 25, 2018

May 25, 2018

--- tz-link.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tz-link.html b/tz-link.html index 3017a5e..508a1f1 100644 --- a/tz-link.html +++ b/tz-link.html @@ -281,11 +281,11 @@ transferring time zone data by reference. The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis mailing list</a> discusses two Internet drafts: <a id="TZDIST-Geolocate" -href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-01">TZDIST +href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-02">TZDIST Geolocate Extension</a> lets a client determine its time zone region from its geographic location using a <a href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>, and -<a href="https://tools.ietf.org/html/draft-murchison-tzdist-tzif-00">The +<a href="https://tools.ietf.org/html/draft-murchison-tzdist-tzif-02">The Time Zone Information Format (<abbr>TZif</abbr>)</a> specifies the format of <abbr>TZif</abbr> data.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> -- 2.17.0

2 3

Thanks for the book recommendation
by Scott Kilpatrick May 25, 2018

May 25, 2018

Hi everyone, Recently I stumbled upon the tz database and mailing list when debugging some daylight saving issues at work. I'd just wanted to understand how political decisions about DST affect a Java program. Reading through the documentation about the database online, I noticed the link to the Dissent interview with Vanessa Ogle about her book, "The Global Transformation of Time, 1870-1950". (It was a bit jarring to see a link to Dissent in technical material like this, ha!) First I read that interview and then I picked up the book - and loved it! Many thanks to Paul E. or to whomever actually suggested the citation to the book in the "theory" page. It has helped me further go down this rabbit hole that I'd never expected to be so interested in. Best, Scott

1 0

[PATCH] Clarify that EST5EDT is problematic in POSIX
by Paul Eggert May 21, 2018

May 21, 2018

* theory.html: Don’t imply that EST5EDT is an OK POSIX TZ string, as POSIX does not specify the DST transitions in this case. Use past tense to describe the typical pre-POSIX behavior. Minor copyediting. --- theory.html | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/theory.html b/theory.html index 53f7cee..298972e 100644 --- a/theory.html +++ b/theory.html @@ -874,15 +874,15 @@ an older <code>zic</code>. <pre><code>TZ='Pacific/Auckland'</code></pre> </li> <li> - POSIX does not define the exact meaning of <code>TZ</code> values like + POSIX does not define the <abbr>DST</abbr> transitions + for <code>TZ</code> values like "<code>EST5EDT</code>". - Typically the current <abbr>US</abbr> <abbr>DST</abbr> rules - are used to interpret such values, but this means that the - <abbr>US</abbr> <abbr>DST</abbr> rules are compiled into each - program that does time conversion. - This means that when - <abbr>US</abbr> time conversion rules change (as in the United - States in 1987), all programs that do time conversion must be + Traditionally the current <abbr>US</abbr> <abbr>DST</abbr> rules + were used to interpret such values, but this meant that the + <abbr>US</abbr> <abbr>DST</abbr> rules were compiled into each + program that did time conversion. This meant that when + <abbr>US</abbr> time conversion rules changed (as in the United + States in 1987), all programs that did time conversion had to be recompiled to ensure proper results. </li> <li> @@ -893,14 +893,14 @@ an older <code>zic</code>. <li> In POSIX, there is no tamper-proof way for a process to learn the system's best idea of local wall clock. - (This is important for applications that an administrator wants + This is important for applications that an administrator wants used only at certain times – without regard to whether the user has fiddled the <code>TZ</code> environment variable. While an administrator can "do everything in <abbr>UT</abbr>" to get around the problem, doing so is inconvenient and precludes - handling daylight saving time shifts - as might be required to - limit phone calls to off-peak hours.) + handling daylight saving time shifts – as might be required to + limit phone calls to off-peak hours. </li> <li> POSIX provides no convenient and efficient way to determine @@ -923,7 +923,7 @@ an older <code>zic</code>. Unsigned 32-bit integers are used on one or two platforms, and 36-bit and 40-bit integers are also used occasionally. Although earlier POSIX versions allowed <code>time_t</code> to be a - floating-point type, this was not supported by any practical systems, + floating-point type, this was not supported by any practical system, and POSIX.1-2013 and the <code><abbr>tz</abbr></code> code both require <code>time_t</code> to be an integer type. </li> @@ -960,9 +960,9 @@ an older <code>zic</code>. separately maintaining both <code>TZ</code> and <code>TIMEZONE</code> seemed a nuisance; and systems where "new" forms of <code>TZ</code> might cause problems can simply - use <code>TZ</code> values such as "<code>EST5EDT</code>" which - can be used both by "new" programs (à la POSIX) and "old" - programs (as zone names and offsets). + use legacy <code>TZ</code> values such as "<code>EST5EDT</code>" which + can be used by "new" programs as well as by "old" programs that + assume pre-POSIX <code>TZ</code> values. </p> </li> <li> -- 2.17.0

1 0

[PROPOSED] Use “TZif” for binary files.
by Paul Eggert May 21, 2018

May 21, 2018

Also, mention tzdist-bis and draft-murchison-tzdist-tzif-00. --- Makefile | 8 +++++--- NEWS | 2 ++ theory.html | 15 ++++++++------- tz-link.html | 37 ++++++++++++++++++++++--------------- zic.c | 2 +- 5 files changed, 38 insertions(+), 26 deletions(-) diff --git a/Makefile b/Makefile index 91c30f7..06f7fd6 100644 --- a/Makefile +++ b/Makefile @@ -109,6 +109,8 @@ LIBDIR = $(TOPDIR)/$(USRDIR)/lib # Types to try, as an alternative to time_t. int64_t should be first. TIME_T_ALTERNATIVES = int64_t int32_t uint32_t uint64_t +# What kind of TZif data files to generate. +# (TZif is the binary time zone data format that zic generates.) # If you want only POSIX time, with time values interpreted as # seconds since the epoch (not counting leap seconds), use # REDO= posix_only @@ -129,7 +131,7 @@ TIME_T_ALTERNATIVES = int64_t int32_t uint32_t uint64_t REDO= posix_right -# To install data in text form that has all the information of the binary data, +# To install data in text form that has all the information of the TZif data, # (optionally incorporating leap second information), use # TZDATA_TEXT= tzdata.zi leapseconds # To install text data without leap second information (e.g., because @@ -357,7 +359,7 @@ ZIC= $(zic) $(ZFLAGS) ZFLAGS= -# How to use zic to install tz binary files. +# How to use zic to install TZif files. ZIC_INSTALL= $(ZIC) -d '$(DESTDIR)$(TZDIR)' $(LEAPSECONDS) @@ -605,7 +607,7 @@ INSTALLARGS = \ YEARISTYPE='$(YEARISTYPE)' \ ZIC='$(ZIC)' -# 'make install_data' installs one set of tz binary files. +# 'make install_data' installs one set of TZif files. install_data: zic leapseconds yearistype tzdata.zi $(ZIC_INSTALL) tzdata.zi diff --git a/NEWS b/NEWS index a91f00a..6bd89c2 100644 --- a/NEWS +++ b/NEWS @@ -25,6 +25,8 @@ Unreleased, experimental changes The latter restriction makes room for future extensions (a possibility noted by Tom Lane). + The name "TZif" is now used for the tz binary data format. + Changes to build procedure New 'make' target 'rearguard_tarballs' to build the rearguard diff --git a/theory.html b/theory.html index d5055b2..f2409f4 100644 --- a/theory.html +++ b/theory.html @@ -932,15 +932,16 @@ an older <code>zic</code>. <li> <p> The <code>TZ</code> environment variable is used in generating - the name of a binary file from which time-related information is read + the name of a file from which time-related information is read (or is interpreted à la POSIX); <code>TZ</code> is no longer - constrained to be a three-letter time zone - abbreviation followed by a number of hours and an optional three-letter - daylight time zone abbreviation. + constrained to be a string containing abbreviations + and numeric data as described <a href="#POSIX">above</a>. + The file's format is <dfn><abbr>TZif</abbr></dfn>, + a time zone information format that contains binary data. The daylight saving time rules to be used for a particular <code><abbr>tz</abbr></code> region are encoded in the - binary file; the format of the file - allows U.S., Australian, and other rules to be encoded, and + <abbr>TZif</abbr> file; the format of the file allows <abbr>US</abbr>, + Australian, and other rules to be encoded, and allows for situations where more than two time zone abbreviations are used. </p> @@ -950,7 +951,7 @@ an older <code>zic</code>. might cause "old" programs (that expect <code>TZ</code> to have a certain form) to operate incorrectly; consideration was given to using some other environment variable (for example, <code>TIMEZONE</code>) - to hold the string used to generate the binary file's name. + to hold the string used to generate the <abbr>TZif</abbr> file's name. In the end, however, it was decided to continue using <code>TZ</code>: it is widely used for time zone purposes; separately maintaining both <code>TZ</code> diff --git a/tz-link.html b/tz-link.html index b8b7944..77e06d2 100644 --- a/tz-link.html +++ b/tz-link.html @@ -143,8 +143,10 @@ more errors.</p> After obtaining the code and data files, see the <code>README</code> file for what to do next. The code lets you compile the <code><abbr>tz</abbr></code> source files into -machine-readable binary files, one for each location. It also lets -you read a <code><abbr>tz</abbr></code> binary file and interpret time stamps for that +machine-readable binary files, one for each location. The binary files +are in a special time zone information format (<dfn><abbr>TZif</abbr></dfn>). +The code also lets +you read a <abbr>TZif</abbr> file and interpret time stamps for that location.</p> <h2 id="changes">Changes to the <code><abbr>tz</abbr></code> database</h2> <p> @@ -272,12 +274,17 @@ href="https://tools.ietf.org/html/rfc7808">TZDIST</a> (Internet <abbr>RFC</abbr> 7808), a time zone data distribution service, along with <a href="https://tools.ietf.org/html/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for -transferring time zone data by reference. The draft <a +transferring time zone data by reference. +The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis +mailing list</a> discusses two Internet drafts: <a id="TZDIST-Geolocate" href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-01">TZDIST Geolocate Extension</a> lets a client determine its time zone region from its geographic location using a <a -href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>.</li> +href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>, and +<a href="https://tools.ietf.org/html/draft-murchison-tzdist-tzif-00">The +Time Zone Information Format (<abbr>TZif</abbr>)</a> specifies the format of +<abbr>TZif</abbr> data.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> Internet Calendaring and Scheduling Core Object Specification (iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) @@ -426,35 +433,35 @@ source into text files, along with a runtime that can read those files. Tcl is freely available under a <abbr>BSD</abbr>-style license.</li> </ul> -<h2 id="binary">Other <code><abbr>tz</abbr></code> binary file readers</h2> +<h2 id="TZif">Other <abbr>TZif</abbr> readers</h2> <ul> <li>The <a href="https://www.gnu.org/software/libc/"><abbr>GNU</abbr> C Library</a> has an independent, thread-safe implementation of -a <code><abbr>tz</abbr></code> binary file reader. +a <abbr>TZif</abbr> file reader. This library is freely available under the LGPL and is widely used in <abbr>GNU</abbr>/Linux systems.</li> <li><a href="https://www.gnome.org">GNOME</a>'s <a href="https://developer.gnome.org/glib/">GLib</a> has -a <code><abbr>tz</abbr></code> binary file reader written in C that +a <abbr>TZif</abbr> file reader written in C that creates a <code>GTimeZone</code> object representing sets of <abbr>UT</abbr> offsets. It is freely available under the <abbr>LGPL</abbr>.</li> <li>The <a href="https://github.com/bloomberg/bde/wiki">BDE Standard Library</a>'s <code>baltzo::TimeZoneUtil</code> component contains a C++ -implementation of a binary file reader. It is freely available under +implementation of a <abbr>TZif</abbr> file reader. It is freely available under the Apache License.</li> <li><a href="https://github.com/google/cctz">CCTZ</a> is a simple C++ library that translates between <abbr>UT</abbr> and civil time and -can read binary files. It is freely available under the Apache +can read <abbr>TZif</abbr> files. It is freely available under the Apache License.</li> <li><a href="http://bmsi.com/java/#TZ">ZoneInfo.java</a> -is a <code><abbr>tz</abbr></code> binary file reader written in Java. +is a <abbr>TZif</abbr> file reader written in Java. It is freely available under the <abbr>LGPL</abbr>.</li> <li><a href="https://github.com/derickr/timelib">Timelib</a> is a C -library that reads tz binary files and converts +library that reads <abbr>TZif</abbr> files and converts time stamps from one time zone or format to another. It is used by <a href="https://secure.php.net"><abbr title="PHP: Hypertext Preprocessor">PHP</abbr></a>, @@ -465,23 +472,23 @@ It is freely available under the <abbr>MIT</abbr> license.</li> JavaScript library that supports date arithmetic that is time zone aware. It is freely available under the <abbr>MIT</abbr> license.</li> <li>Tcl, mentioned <a href="#Tcl">above</a>, also contains a -<code><abbr>tz</abbr></code> binary file reader.</li> +<abbr>TZif</abbr> file reader.</li> <li><a href="http://search.cpan.org/perldoc?DateTime::TimeZone::Tzfile"> DateTime::TimeZone::Tzfile</a> -is a <code><abbr>tz</abbr></code> binary file reader written in Perl. +is a <abbr>TZif</abbr> file reader written in Perl. It is freely available under the same terms as Perl (dual <abbr>GPL</abbr> and Artistic license).</li> <li>The public-domain <a href="https://github.com/dbaron/tz.js">tz.js</a> library contains a Python tool that -converts <code><abbr>tz</abbr></code> binary data into +converts <abbr>TZif</abbr> data into <abbr>JSON</abbr>-format data suitable for use in its JavaScript library for time zone conversion. Dates before 1970 are not supported.</li> <li>The <a href="https://hackage.haskell.org/package/timezone-olson">timezone-olson</a> package contains <a href="https://www.haskell.org">Haskell</a> code that -parses and uses <code><abbr>tz</abbr></code> binary data. It is freely +parses and uses <abbr>TZif</abbr> data. It is freely available under a <abbr>BSD</abbr>-style license.</li> </ul> <h2 id="software">Other <code><abbr>tz</abbr></code>-based time zone software</h2> diff --git a/zic.c b/zic.c index 0c4c384..f1d0bf3 100644 --- a/zic.c +++ b/zic.c @@ -184,7 +184,7 @@ static bool yearistype(zic_t year, const char * type); enum { PERCENT_Z_LEN_BOUND = sizeof "+995959" - 1 }; /* If true, work around a bug in Qt 5.6.1 and earlier, which mishandles - tz binary files whose POSIX-TZ-style strings contain '<'; see + TZif files whose POSIX-TZ-style strings contain '<'; see QTBUG-53071 <https://bugreports.qt.io/browse/QTBUG-53071>. This workaround will no longer be needed when Qt 5.6.1 and earlier are obsolete, say in the year 2021. */ -- 2.7.4

1 0

[PROPOSED] ‘white-space: pre-wrap’ to avoid tiny fonts
by Paul Eggert May 16, 2018

May 16, 2018

* theory.html, tz-how-to.html, tz-link.html: Use ‘white-space: pre-wrap’ to avoid tiny font on Android mobile browsers. Migrate this style setting to a <style> element, and be consistent about it in the tz web pages. --- theory.html | 3 +++ tz-how-to.html | 3 +++ tz-link.html | 9 ++++++--- 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/theory.html b/theory.html index 0ada9e3..2d6e505 100644 --- a/theory.html +++ b/theory.html @@ -3,6 +3,9 @@ <head> <title>Theory and pragmatics of the tz code and data</title> <meta charset="UTF-8"> + <style> + pre {margin-left: 2em; white-space: pre-wrap;} + </style> </head> <body> diff --git a/tz-how-to.html b/tz-how-to.html index a54f54a..367c6ed 100644 --- a/tz-how-to.html +++ b/tz-how-to.html @@ -5,6 +5,9 @@ <head> <title>How to Read the tz Database</title> <meta http-equiv="Content-type" content='text/html; charset="UTF-8"'> +<style> +pre {margin-left: 2em; white-space: pre-wrap;} +</style> </head> <body> <h2>How to Read the <a href="https://en.wikipedia.org/wiki/Tz_database">tz diff --git a/tz-link.html b/tz-link.html index b8b7944..87241da 100644 --- a/tz-link.html +++ b/tz-link.html @@ -3,6 +3,9 @@ <head> <title>Sources for time zone and daylight saving time data</title> <meta charset="UTF-8"> +<style> +pre {margin-left: 2em; white-space: pre-wrap;} +</style> </head> <body> <h1>Sources for time zone and daylight saving time data</h1> @@ -97,7 +100,7 @@ href="https://en.wikipedia.org/wiki/Unix_shell">shell</a> commands download the latest release's two <a href="https://en.wikipedia.org/wiki/Tar_(computing)">tarballs</a> to a <abbr>GNU</abbr>/Linux or similar host.</p> -<pre style="margin-left: 2em"><code>mkdir tzdb +<pre><code>mkdir tzdb cd tzdb <a href="https://www.gnu.org/software/wget/">wget</a> https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz wget https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz @@ -107,7 +110,7 @@ gzip -dc tzdata-latest.tar.gz | tar -xf - <p>Alternatively, the following shell commands download the same release in a single-tarball format containing extra data useful for regression testing:</p> -<pre style="margin-left: 2em"><code>wget <a href="https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz">https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz</a> +<pre><code>wget <a href="https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz">https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz</a> <a href="https://www.nongnu.org/lzip/">lzip</a> -dc tzdb-latest.tar.lz | tar -xf - </code></pre> <p>These commands use convenience links to the latest release @@ -133,7 +136,7 @@ less-secure protocol.</p> <p>Alternatively, a development repository of code and data can be retrieved from <a href="https://github.com">GitHub</a> via the shell command:</p> -<pre style="margin-left: 2em"><code><a href="https://git-scm.com">git</a> clone <a href="https://github.com/eggert/tz">https://github.com/eggert/tz</a> +<pre><code><a href="https://git-scm.com">git</a> clone <a href="https://github.com/eggert/tz">https://github.com/eggert/tz</a> </code></pre> <p> Since version 2012e, each release has been tagged in development repositories. -- 2.17.0

1 0

Brazilian Timezone
by Christian Brackmann May 16, 2018

May 16, 2018

Hello! I wonder about the brazilian timezone you call as "America/Sao_Paulo". In Brazil, São Paulo is just a city (with a very large population indeed), but as oficial time in Brazil we use the capital of Brazil, called "Brasília". Why do you use the city of São Paulo as reference? Our legal local time is Brasilia and not São Paulo. Can you please explain it better? Thank you in advance. Best regards. *--* Prof. Dr. Christian Puhlmann Brackmann Coordenador Geral de Pós-Graduação Pró-Reitoria de Pesquisa, Pós-graduação e Inovação Instituto Federal de Educação, Ciência e Tecnologia Farroupilha (IFFAR) brackmann(a)iffarroupilha.edu.br +55 55 3226 6636 / 98100-1819 ** *“Education is the most powerful weapon which you can use to change the world”*Nelson Mandela

2 1

Gripe about compressed rule set names in tzdata.zi
by Tom Lane May 14, 2018

May 14, 2018

Reviewing the changes between 2018d and 2018e crystallized something that had not been clear to me before: the "compressed" ruleset names used in tzdata.zi are chosen as sequential ASCII characters, or pairs of ASCII letters after the single-character names run out. This means that addition or deletion of a ruleset near the beginning of the file creates semantically-insignificant changes throughout the rest of the file, making it hard to review the diffs to get a sense of what changed, or to eyeball-validate the .zi file. It probably also bloats one's repository if storing tzdata.zi in a source code control system. So I'm wondering if it'd be acceptable to change the compression rule to something that gives more stable results. I've not really experimented to see what would work well, but one simple idea is to take the shortest unique prefix of each original ruleset name. There are other options if shortness is prized well above readability. I wouldn't expect the results to be 100% stable in the face of ruleset additions/deletions, since conflicts could appear or disappear, but 99% would be fine. Regardless of the specifics, this would surely have the effect of making tzdata.zi a bit bigger (although compression would likely buy back much of the delta). So, if nobody but me is annoyed by the current behavior, I'd expect such a proposal to get rejected. I'm willing to do the legwork to develop a concrete patch if it'd be likely to get accepted. regards, tom lane

2 4

new mailing list: tzdist-bis@ietf.org
by Eliot Lear May 11, 2018

May 11, 2018

Hello everyone, I would like to bring to your attention two drafts that we have formed a mailing list around two drafts: draft-murchison-tzdist-geolocate-01 The Time Zone Data Distribution Service (TZDIST) Geolocate Extension The basic idea behind this draft is, given a geo: URI, please provide provide an appropriate TZID. And draft-murchison-tzdist-tzif-00 The Time Zone Information Format (TZif) This document is the one I've been waiting for a long time: it describes the format that those tz files have been using, and it features as co-authors Paul Eggert and Arthur David Olson. The intent is to do a sort of micro-wg to get both of these docs turned into RFCs. To do that, we need good reviewers, particularly ones who have previously cracked and parsed the tz files (bonus points if you were crazy enough to write out one!!). There is a mailing list for this purpose: tzdist-bis(a)ietf.org. You can join it by going to https://www.ietf.org/mailman/listinfo/tzdist-bis. I look forward to seeing a few of you over there (you know who you are). Eliot

1 0

Time in Macau
by P Chan May 10, 2018

May 10, 2018

Hi, I would like to share some information about the history of time in Macau. All the sources I used can be accessed online. LegisMac http://legismac.safp.gov.mo/legismac/descqry/Descqry.jsf?lang=pt A database for searching titles of legal documents of Macau in Chinese and Portuguese. The term "HORÁRIO DE VERÃO" can be used for searching decrees about summer time. Archives of Macao http://www.archives.gov.mo/en/bo/ It contains images of old official gazettes. The Macao Meteorological and Geophysical Bureau have a page listing the summer time history. But it is not complete and has some mistakes. <http://www.smg.gov.mo/smg/geophysics/c_t_Summer%20Time.htm>http://www.smg.gov.mo/smg/geophysics/e_t_Summer%20Time.htm Macau adopted GMT+8 on 30 Oct 1904 to follow Hong Kong. Clocks were advanced by 25 minutes and 50 seconds. Which means the LMT used was +7:34:10. As stated in the "Portaria N.º 204" dated 21 October 1904 and published in the Official Gazette on 29 October 1904. http://igallery.icm.gov.mo/Images/Archives/BO/MO_AH_PUB_BO_1904_10/MO_AH_PU… Therefore the 1911 decree of Portugal did not change time in Macau. >From LegisMac, here is a list of decrees that changed the time. Decree Gazette no. Gazette date Title DIL 732 BOCM 51 1941.12.20 adoptando medidas excepcionais que garantam o funcionamento de todos os serviços públicos e particulares e restringindo ao mínimo o consumo de alguns géneros e artigos essenciais à vida da colónia. DIL 764 BOCM 9S 1942.04.30 Determinando que sejam adiantadas de uma hora os relógios da colónia e regulando os horários das repartições públicas. DIL 781 BOCM 21 1942.10.10 Substituindo o corpo do artigo 3° do diploma legislativo n° 732 e suas alíneas a) e b), respeitantes às alterações da hora e horário das Repartições Públicas, e revogando o diploma legislativo n° 764. PT 3434 BOCM 8S 1943.04.17 determinando que às 23 horas do dia 30 do corrente mês sejam adiantadas de uma hora os relógios da colónia e regulando o horário das Repartições Públicas. PT 3504 BOCM 20 1943.09.25 regulando o horário das Repartições Públicas e determinando que no dia 30 do corrente, às 23 horas, os relógios sejam atrasados de uma hora. PT 3843 BOCM 39 1945.09.29 regulando o horário das Repartições Públicas e determinando que no dia 30 do corrente, às 24 horas, os relógios sejam atrasados de uma hora. PT 3961 BOCM 17 1946.04.27 Determinando que, a partir das 23 horas do dia 30 do corrente mês, sejam adiantados de uma hora os relógios da Colónia. PT 4026 BOCM 39 1946.09.28 estabelecendo o horário da Repartições Públicas e determinando que no dia 30 do corrente, às 24 horas, os relógios sejam atrasados de uma hora. PT 4153 BOCM 16 1947.04.10 Determinando que, a partir das 23 horas do dia 19 do corrente mês, sejam adiantados de uma hora os relógios da Colónia. PT 4271 BOCM 48 1947.11.29 Determinando que, a aprtir do dia 30 do corrente às 24 horas, os relógios sejam atrasados de uma hora. PT 4374 BOCM 18 1948.05.01 Determina que, a partir das 23 horas do dia 2 do corrente mês, sejam adiantados de uma hora os relógios de Colónia. PT 4465 BOCM 44 1948.10.30 Determina que no dia 31 do corrente mês, às 24 horas, os relógios sejam atrasados de uma hora. PT 4590 BOCM 14 1949.04.02 Determina que, a partir das 23 horas do dia 2 do corrente mês, sejam adiantados de uma hora os relógios da Colónia. PT 4666 BOCM 44 1949.10.29 Determina que no dia 30 do corrente, a 0 hora, os relógios sejam atrasados de uma hora. PT 4771 BOCM 12 1950.03.25 Determina que, a partir das 23 horas do dia 1 do próximo mês de Abril, serão adiantados de uma horas os relógios da Colónia. PT 4838 BOCM 43 1950.10.28 Determina que no dia 28 do corrente, às 24 horas, os relógios sejam atrasados de uma hora. PT 4946 BOCM 12 1951.03.24 Determina que, a partir das 23 horas do dia 31 de Março do corrente ano, serão adiantados de uma hora os relógios desta colónia. PT 5025 BO 43 1951.10.27 Manda que no dia 29 do corrente, às zero horas, os relógios sejam atrasados de uma hora. PT 5149 BO 14 1952.04.05 Determina que a partir das 23 horas do dia 5 de Abril corrente serão adiantados de uma hora os relógios desta província. PT 5251 BO 43 1952.10.25 Determina que no dia 2 do próximo mês de Novembro, às zero horas, os relógios serão atrasados de uma hora. PT 5366 BO 13 1953.03.28 Determina que a partir das 23 horas do dia 4 do próximo mês de Abril serão adiantados de uma hora os relógios desta província. PT 5444 BO 44 1953.10.31 Determina que no dia 31 do corrente, às 24 horas, os relógios sejam atrasados de uma hora. PT 5540 BO 12 1954.03.20 Determina que, a partir das 23 horas de hoje, serão adiantados de uma hora os relógios da Província. PT 5589 BO 44 1954.10.30 Determina que, a partir das 24,00 horas de hoje, 30 do corrente, os relógios sejam atrasados de uma hora. PT 5676 BO 12 1955.03.19 Manda adiantar de uma hora os relógios da Província, a partir das 23 horas de hoje, 19 do corrente. PT 5739 BO 45 1955.11.05 Determina que às 24,00 horas de hoje, 5 de corrente, os relógios sejam atrasados de uma hora. PT 5823 BO 11 1956.03.17 Determina que a partir das 23 horas de hoje, 17 do corrente, serão adiantados de uma hora os relógios da Província. PT 5891 BO 44 1956.11.03 Determina que no dia 4 do corrente mês, às 3 horas e 30 minutos, os relógios sejam atrasados de uma hora. PT 5981 BO 12 1957.03.23 Determina que, a partir das 3,30 horas do dia 24 do corrente mês, sejam adiantados de uma hora os relógios da Província. PT 6064 BO 43 1957.10.26 Determina que no dia 3 do próximo mês do Novembro, às 3 horas e 30 minutos, os relógios sejam atrasados de uma hora. PT 6172 BO 12 1958.03.22 Determina que, a partir das 3,30 horas do dia 23 do corrente mês, sejam adiantados de uma hora os relógios da Província. PT 6243 BO 43 1958.10.25 Determina que no dia 2 do próximo mês do Novembro, às 3 horas e 30 minutos, os relógios sejam atrasados de uma hora. PT 6341 BO 12 1959.03.21 Determina que, a partir das 3,30 horas do dia 22 do corrente, sejam adiantados de uma hora os relógios da Província. PT 6411 BO 43 1959.10.24 Determina que no dia 1 do próximo mês de Novembro, às 3 horas e 30 minutos, os relógios sejam atrasados de uma hora. PT 6514 BO 11 1960.03.12 Determina que, a partir das 3,30 horas do dia 20 do corrente, sejam adiantados de uma hora os relógios da Província. PT 6584 BO 44 1960.10.29 Determina que no dia 6 do próximo mês de Novembro, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 6721 BO 10 1961.03.11 Determina que, a partir das 3,30 horas do dia 19 do corrente, sejam adiantados os relógios da Província. PT 6815 BO 43 1961.10.28 Determina que no dia 5 do próximo mês de Novembro, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 6947 BO 10 1962.03.10 Determina que a partir das 3,30 horas do dia 18 do corrente, sejam adiantados de uma hora os relógios da província. PT 7080 BO 43 1962.10.27 Determina que no dia 4 do próximo mês de Novembro, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 7218 BO 12 1963.03.23 Determina que a partir das 3,30 horas do dia 24 do corrente, sejam adiantados de uma hora os relógios de província. PT 7340 BO 43 1963.10.26 Detremina que a partir da 3,30 horas do dia 3 do próximo mês de Novembro, sejam atrasados de uma hora os relógios da província. PT 7491 BO 11 1964.03.14 Determina que a partir das 3,30 horas do dia 22 do corrente, os relógios sejam adiantados uma hora. PT 7664 BO 43 1964.10.24 Determina que a partir das 3,30 horas do dia 1 do próximo mês de Novembro, sejam atrasados de uma hora os relógios da província. PT 7846 BO 15 1965.04.10 Determina que a partir das 3,30 horas do dia 18 do corrente, os relógios sejam adiantados de uma hora. PT 7979 BO 42 1965.10.16 Determina que, a partir das 2,30 horas do próximo dia 17 do corrente, sejam atrasados de uma hora os relógios da província. PT 8146 BO 15 1966.04.09 Determina que os relógios da província sejam adiantados de uma hora, a partir das 3,30 horas do dia 17 do corrente. PT 8252 BO 41 1966.10.08 Determina que, às 2,30 horas do dia 16 do corrente, os relógios sejam atrasados de uma hora. PT 8429 BO 15 1967.04.15 Manda que no dia 16 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 8540 BO 41 1967.10.14 Manda que, no próximo dis 22 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 8735 BO 15 1968.04.13 Manda que no dia 21 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 8860 BO 41 1968.10.12 Manda que, no próximo dia 20 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 9035 BO 16 1969.04.19 Manda que no dia 20 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 9156 BO 42 1969.10.18 Manda que no dia 19 do corrente, às relógios sejam atrasados de uma hora. PT 9328 BO 15 1970.04.11 Manda que no dia 19 do corrente às 3,30 horas, os relógios sejam adiantados de uma hora. PT 9418 BO 41 1970.10.10 Manda que no dia 18 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 9587 BO 14 1971.04.03 Manda que no dia 18 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 9702 BO 41 1971.10.09 Manda que no dia 17 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 38-A/72 BO 14 1972.04.01 Manda que no dia 16 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 126-A/72 BO 41 1972.10.07 Manda que no dia 22 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 61/73 BO 14 1973.04.07 Manda que no dia 22 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 182/73 BO 40 1973.10.06 Manda que no dia 21 do corrente, às 3.30 horas, os relógios sejam atrasados de uma hora. PT 282/73 BO 51 1973.12.22 Manda que no dia 30 do corrente mês de Dezembro, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 177/74 BO 41 1974.10.12 Manda que no dia 20 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 51/75 BO 15 1975.04.12 Manda que no dia 20 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 173/75 BO 41 1975.10.11 Manda que no dia 19 do corrente mês, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 67/76/M BO 14 1976.04.03 Manda que no dia 18 de Abril do corrente ano, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 169/76/M BO 41 1976.10.09 Manda que, no dia 17 de Outubro corrente, às 3,30 horas, os relógios, sejam atrasados de uma hora. PT 78/79/M BO 19 1979.05.12 Manda que, no dia 13 de Maio de 1979, os relógios sejam adiantados de uma hora. PT 166/79/M BO 42 1979.10.20 Manda que, no dia 21 de Outubro de 1979, os relógios sejam atrasados de uma hora. Note that DIL 732 does not belong to "HORÁRIO DE VERÃO" according to LegisMac. Here is a list of time change according to the decrees, each change corresponds to each decree. Date Time Change 1941-12-21 Sun 2300 +1 1942-04-30 Thu 2300 +1 1942-11-17 Tue 2300 -1 1943-04-30 Fri 2300 +1 1943-09-30 Thu 2300 -1 1945-09-30 Sun 2400 -1 1946-04-30 Tue 2300 +1 1946-09-30 Mon 2400 -1 1947-04-19 Sat 2300 +1 1947-11-30 Sun 2400 -1 1948-05-02 Sun 2300 +1 1948-10-31 Sun 2400 -1 1949-04-02 Sat 2300 +1 1949-10-30 Sun 0000 -1 1950-04-01 Sat 2300 +1 1950-10-28 Sat 2400 -1 1951-03-31 Sat 2300 +1 1951-10-29 Mon 0000 -1 1952-04-05 Sat 2300 +1 1952-11-02 Sun 0000 -1 1953-04-04 Sat 2300 +1 1953-10-31 Sat 2400 -1 1954-03-20 Sat 2300 +1 1954-10-30 Sat 2400 -1 1955-03-19 Sat 2300 +1 1955-11-05 Sat 2400 -1 1956-03-17 Sat 2300 +1 1956-11-04 Sun 0330 -1 1957-03-24 Sun 0330 +1 1957-11-03 Sun 0330 -1 1958-03-23 Sun 0330 +1 1958-11-02 Sun 0330 -1 1959-03-22 Sun 0330 +1 1959-11-01 Sun 0330 -1 1960-03-20 Sun 0330 +1 1960-11-06 Sun 0330 -1 1961-03-19 Sun 0330 +1 1961-11-05 Sun 0330 -1 1962-03-18 Sun 0330 +1 1962-11-04 Sun 0330 -1 1963-03-24 Sun 0330 +1 1963-11-03 Sun 0330 -1 1964-03-22 Sun 0330 +1 1964-11-01 Sun 0330 -1 1965-04-18 Sun 0330 +1 1965-10-17 Sun 0230 -1 1966-04-17 Sun 0330 +1 1966-10-16 Sun 0230 -1 1967-04-16 Sun 0330 +1 1967-10-22 Sun 0330 -1 1968-04-21 Sun 0330 +1 1968-10-20 Sun 0330 -1 1969-04-20 Sun 0330 +1 1969-10-19 Sun 0330 -1 1970-04-19 Sun 0330 +1 1970-10-18 Sun 0330 -1 1971-04-18 Sun 0330 +1 1971-10-17 Sun 0330 -1 1972-04-16 Sun 0330 +1 1972-10-22 Sun 0330 -1 1973-04-22 Sun 0330 +1 1973-10-21 Sun 0330 -1 1973-12-30 Sun 0330 +1 1974-10-20 Sun 0330 -1 1975-04-20 Sun 0330 +1 1975-10-19 Sun 0330 -1 1976-04-18 Sun 0330 +1 1976-10-17 Sun 0330 -1 1979-05-13 Sun 0330 +1 1979-10-21 Sun 0330 -1 Note that between 1942 and 1945, the time switched between GMT+9 and GMT+10. Also in 1965 and 1965 the DST ended at 2:30am. I actually don't speak Portuguese, please correct me if I'm wrong. Regards, P Chan

2 1

'Pyongyang Time' scrapped as North Korea synchronises clocks with the South
by Kim Sungwoo May 9, 2018

May 9, 2018

Hello, I am Sungwoo Kim, leave in Seoul, Republic of Korea. (South Korea) Since 5. 5. 2018, Pyongyang Time - North Korea time - had synchronized with South. We should discussion how we can synchronize PYT to KST with less side-effect. Here is articles include more information and backgrounds. https://www.telegraph.co.uk/news/2018/05/05/pyongyang-time-scrapped-north-k… http://www.xinhuanet.com/english/2018-05/05/c_137158132.htm http://calgarysun.com/news/world/no-more-pyongyang-time-north-korea-changes… https://qz.com/1265352/north-korea-will-reunifying-its-time-zone-with-south…

4 3

China DST
by chan jason May 7, 2018

May 7, 2018

Hi, There are some mistakes in the rules of PRC. The start and end time of DST in China should be 2:00 (i.e. 2:00 to 3:00 at the start and 2:00 to 1:00 at the end). Also in 1988, the start date should be 17 May instead of 10 May. Government notices about summer time: 1986-04-12 http://www.zj.gov.cn/attach/zfgb/198608.pdf p.21-22 (To establish summer time from 1986. On 4 May, set the clocks ahead one hour at 2 am. On 14 September, set the clocks backward one hour at 2 am.) 1987-02-15 http://www.gov.cn/gongbao/shuju/1987/gwyb198703.pdf p.114 (Summer time in 1987 to start from 12 April until 13 September) 1987-09-09 http://www.gov.cn/gongbao/shuju/1987/gwyb198721.pdf p.709 (From 1988, summer time to start from 2 am of the first Sunday of mid-April until 2 am of the first Sunday of mid-September) 1992-03-03 http://www.gov.cn/gongbao/shuju/1992/gwyb199205.pdf p.152 (To suspend summer time from 1992) The first page of People's Daily on 12 April 1988 stating that summer time to begin on 17 April. http://data.people.com.cn/pic/101p/1988/04/1988041201.jpg Proposed rules: Rule PRC 1986 only - May 4 2:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 2:00 0 S Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D Regards, P Chan

4 4