- tz - lists.iana.org

Binary File Format
by Bill Seymour Sept. 10, 2015

Sept. 10, 2015

I have three questions about the format of the binary files. 1. Re the array of tzh_timecnt transitions: my kneejerk reaction was to think that these were similar to the values in the UNTIL column in the source files, in which case they'd be open upper bounds (in other words, the struct ttinfo that they eventually link to would be for the period immediately before the transition); but it occurs to me that they might be closed lower bounds instead (the corresponding ttinfo is for the period after the transition). tzfile(5) doesn't say explicitly. 2. Basically the same question for the array of leap seconds. The reason it occurs to me that the time_t value could be the point after the leap second is that that's the way that the USNO’s list of leap seconds works. 3. Re the version-'2' array of leap seconds: each array element is a time_t value followed by a count of the number of leap seconds after that time. tzfile(5) says that eight bytes are used for each "transition time" and "leap second time"; but since the count of leap seconds is neither of those, is the count still just four bytes? (I'm thinking that I can't just have a two-dimensional array of int64_t, but rather need a one-dimensional array of struct { int64_t, int32_t }. Is that right?) Thanks, --Bill Seymour

2 1

Sumer Time Paraguay
by Juan Carlos YJ. Lin Sept. 9, 2015

Sept. 9, 2015

Paraguay will change to summer time 60+ on octuber 4, keeping valid the Decreto Nº 1264/2014 Juan Carlos Lin Unisoft S.A. +595-993-288330 --------------------------------------------------- "Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente" "Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisión del contenido no está autorizada fuera del contexto de su envío y a quien corresponde. El uso no autorizado de la información en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bórrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias."

2 1

question regarding 'timezone' variable
by Kees Dekker Sept. 2, 2015

Sept. 2, 2015

Hi, When USG_COMPAT is set, in localtime.c a long timezone (and int daylight) is declared. In strftime.c, also timezone is used, but no reference to 'extern long timezone' is define, neither do any of the provided header files. On most *NIX platforms, a system 'timezone' variable exists (see e.g. man tzset). My concerns are: a. The provided variable in localtime.c may conflict with the system one. b. The used variable in strftime.c may not related to the variable in localtime.c I think that compilers/linkers may complain about duplicate 'timezone' variables, or probably silently map the local timezone variable to the same one. Question: Is behavior intended? Or do I miss something? Regards, Kees

5 15

Fiji DST 2015/16
by Ken Rylander Sept. 2, 2015

Sept. 2, 2015

Hi Paul, Some changes to the Fiji DST 2015/16 were communicated to us. See attached order from Fiji Government. There is nothing yet on their website, http://www.fiji.gov.fj, so I can't provide a link yet. The attached order states: "the daylight saving period is 1 hour in advance of the standard time commencing at 2.00 am on Sunday 1st November, 2015 and ending at 3.00 am on Sunday 17th January, 2016." Fiji rules in tzdata2015f: Rule Fiji 2014 max - Nov Sun>=1 2:00 1:00 S Rule Fiji 2015 max - Jan Sun>=18 3:00 0 - I guess that means that the start of DST on Nov 1, will work fine. But the second rule need to be changed, so DST will on Jan 17, 2016. Regards, Ken Rylander | Solution Development and BI Manager - Digicel Pacific | Digicel (Fiji) Ltd | P.O.Box 13811, Suva, Fiji | Ground Floor, Kadavu House, Victoria Parade, Suva, Fiji | Mobile (679) 701 5353 | Fax (679) 334 3733 | ken.rylander(a)digicelgroup.com<mailto:ken.rylander@digicelgroup.com> | www.digicelpacific.com<http://www.digicelpacific.com/> ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.

2 2

[PROPOSED PATCH] Fix localtime bug with Anchorage after 2037
by Paul Eggert Aug. 28, 2015

Aug. 28, 2015

* NEWS: Document this. * localtime.c (tzloadbody): Handle America/Anchorage after 2037, even though the sum of the abbreviations' sizes (42) plus the sum of the extended abbreviations' sizes (10) exceeds TZ_MAX_CHARS (50). Do this by reusing existing abbreviations. Thanks to Bradley White for reporting the bug. Perhaps we should also consider increasing TZ_MAX_CHARS from its currently-low value. --- NEWS | 8 +++++++ localtime.c | 71 +++++++++++++++++++++++++++++++++++++++---------------------- 2 files changed, 54 insertions(+), 25 deletions(-) diff --git a/NEWS b/NEWS index b477250..ffe3fb2 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,13 @@ News for the tz database +Unreleased, experimental changes + + Changes affecting code + + localtime no longer mishandles America/Anchorage after 2037. + (Thanks to Bradley White for reporting the bug.) + + Release 2015f - 2015-08-10 18:06:56 -0700 Changes affecting future time stamps diff --git a/localtime.c b/localtime.c index ded8f7b..ac34e5d 100644 --- a/localtime.c +++ b/localtime.c @@ -569,31 +569,52 @@ tzloadbody(char const *name, struct state *sp, bool doextend, up->buf[nread - 1] = '\0'; if (tzparse(&up->buf[1], ts, false) - && ts->typecnt == 2 - && sp->charcnt + ts->charcnt <= TZ_MAX_CHARS) { - for (i = 0; i < 2; ++i) - ts->ttis[i].tt_abbrind += - sp->charcnt; - for (i = 0; i < ts->charcnt; ++i) - sp->chars[sp->charcnt++] = - ts->chars[i]; - i = 0; - while (i < ts->timecnt && - ts->ats[i] <= - sp->ats[sp->timecnt - 1]) - ++i; - while (i < ts->timecnt && - sp->timecnt < TZ_MAX_TIMES) { - sp->ats[sp->timecnt] = - ts->ats[i]; - sp->types[sp->timecnt] = - sp->typecnt + - ts->types[i]; - ++sp->timecnt; - ++i; - } - sp->ttis[sp->typecnt++] = ts->ttis[0]; - sp->ttis[sp->typecnt++] = ts->ttis[1]; + && ts->typecnt == 2) { + + /* Attempt to reuse existing abbreviations. + Without this, America/Anchorage would stop + working after 2037 when TZ_MAX_CHARS is 50, as + sp->charcnt equals 42 (for LMT CAT CAWT CAPT AHST + AHDT YST AKDT AKST) and ts->charcnt equals 10 + (for AKST AKDT). Reusing means sp->charcnt can + stay 42 in this example. */ + int gotabbr = 0; + int charcnt = sp->charcnt; + for (i = 0; i < 2; i++) { + char *tsabbr = ts->chars + ts->ttis[i].tt_abbrind; + int j; + for (j = 0; j < charcnt; j++) + if (strcmp(sp->chars + j, tsabbr) == 0) { + ts->ttis[i].tt_abbrind = j; + gotabbr++; + break; + } + if (! (j < charcnt)) { + int tsabbrlen = strlen(tsabbr); + if (j + tsabbrlen < TZ_MAX_CHARS) { + strcpy(sp->chars + j, tsabbr); + charcnt = j + tsabbrlen + 1; + ts->ttis[i].tt_abbrind = j; + gotabbr++; + } + } + } + if (gotabbr == 2) { + sp->charcnt = charcnt; + for (i = 0; i < ts->timecnt; i++) + if (sp->ats[sp->timecnt - 1] < ts->ats[i]) + break; + while (i < ts->timecnt + && sp->timecnt < TZ_MAX_TIMES) { + sp->ats[sp->timecnt] = ts->ats[i]; + sp->types[sp->timecnt] = (sp->typecnt + + ts->types[i]); + sp->timecnt++; + i++; + } + sp->ttis[sp->typecnt++] = ts->ttis[0]; + sp->ttis[sp->typecnt++] = ts->ttis[1]; + } } } if (sp->timecnt > 1) { -- 2.1.4

1 0

North Korea ultimatum deadline time confusion
by Paul Eggert Aug. 22, 2015

Aug. 22, 2015

North Korea has delivered a 48-hour ultimatum to the South Korean Defense Ministry, saying that it will respond militarily unless South Korea stops broadcasting propaganda via loudspeakers over the border. There seems to be some confusion about the ultimatum's exact deadline. Ju-Min Park and James Person of Reuters report that although the ultimatum is "uncharacteristically specific", the deadline is "around 5 p.m. (0800 GMT) on Saturday in Seoul". Could the time confusion be due to the recent time zone change in North Korea? Park JM, Pearson J. North Korea goes on war footing against South Korea as deadline looms. Reuters 2015-08-21 12:53 -0400. http://www.reuters.com/article/2015/08/21/us-northkorea-southkorea-border-i… $ date -u; TZ=Asia/Pyongyang date; TZ=Asia/Seoul date Fri Aug 21 17:12:37 UTC 2015 Sat Aug 22 01:42:37 KST 2015 Sat Aug 22 02:12:37 KST 2015

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

tzfiles contain Unix epoch for the first transition time
by Eric Erhardt Aug. 15, 2015

Aug. 15, 2015

I am working on enabling the .NET TimeZoneInfo class to read time zone information from tzfiles. I've hit a snag with the latest tzdata 2015f. (I'm not sure when this change started, but the problem doesn't occur with the tzfiles that are shipped with an Ubuntu 14.04 distribution.) The problem is that the 2015f version of the tzdata contains an initial "Transition Time" that is out of order. The beginning of the America/Chicago tzfile looks like the following: Transition Time Transition Offset 01/01/1970 00:00:00 -05:50:36 11/18/1883 18:00:00 -06:00:00 03/31/1918 08:00:00 -05:00:00 DST 10/27/1918 07:00:00 -06:00:00 Notice the first entry is for 1970, and then the next entry is for 1883. This breaks the documentation in 'man tzfile': The above header is followed by tzh_timecnt four-byte values of type long, sorted in ascending order. These values are written in "standard" byte order. Each is used as a transition time (as returned by time(2)) at which the rules for computing local time change. This causes the TimeZoneInfo parsing code to throw an exception because it is assuming these transitions are sorted in ascending order. Is this an intentional change in the tzfiles? If so, will the tzfile man page be updated for this change? Eric Erhardt

8 18

[PROPOSED PATCH] Fix comments re NK transition time, abbreviation
by Paul Eggert Aug. 15, 2015

Aug. 15, 2015

* asia (Asia/Pyongyang): Confirm 00:00 as transition time. Fix commentary about abbreviation. --- asia | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/asia b/asia index 4f8756b..78eed56 100644 --- a/asia +++ b/asia @@ -1717,11 +1717,12 @@ Rule ROK 1987 1988 - Oct Sun>=8 3:00 0 S # the 8:30 time zone on August 15, one example: # http://www.bbc.com/news/world-asia-33815049 # -# From Paul Eggert (2015-08-07): -# No transition time is specified; assume 00:00. +# From Paul Eggert (2015-08-15): +# Bells rang out midnight (00:00) Friday as part of the celebrations. See: +# Talmadge E. North Korea celebrates new time zone, 'Pyongyang Time' +# http://news.yahoo.com/north-korea-celebrates-time-zone-pyongyang-time-16403… # There is no common English-language abbreviation for this time zone. -# Use %z rather than invent one. We can't assume %z works everywhere yet, -# so for now substitute its output manually. +# Use KST, as that's what we already use for 1954-1961 in ROK. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Seoul 8:27:52 - LMT 1908 Apr 1 @@ -1735,7 +1736,7 @@ Zone Asia/Pyongyang 8:23:00 - LMT 1908 Apr 1 8:30 - KST 1912 Jan 1 9:00 - JCST 1937 Oct 1 9:00 - JST 1945 Aug 24 - 9:00 - KST 2015 Aug 15 + 9:00 - KST 2015 Aug 15 00:00 8:30 - KST ############################################################################### -- 2.1.4

1 0

Is there a zip archive withe the TZ zoneinfo data available ?
by Dave Sweeney Aug. 14, 2015

Aug. 14, 2015

Hello, I was wondering if IANA or a trusted partner provides a zip format of the TZ data and source file? Thank You and Regards, Dave Sweeney +1 (978) 451-0895 VMS Software Inc.

2 2