- tz - lists.iana.org

Time Zone Database Update
by sherif.atef＠hsbc.com May 18, 2016

May 18, 2016

3 4

some info for you
by support＠anuko.com May 17, 2016

May 17, 2016

Hello, Isn't it the information you were looking for? Read about it here <http://fospathopy.kissmecait.com/yield.php?7u> Sincerely yours, support(a)anuko.com

1 0

DST changes for year 2016 not getting reflected for Asia Region
by AJAY SETHUMADHAVAN May 13, 2016

May 13, 2016

Hello Below is the time zone version used in my Linux machine. ======================================================== Name : tzdata Relocations: (not relocatable) Version : 2016d Vendor: CentOS Release : 1.el5 Build Date: Fri 22 Apr 2016 10:07:55 AM PDT Install Date: Thu 12 May 2016 09:14:18 AM PDT Build Host: builder17.centos.org Group : System Environment/Base Source RPM: tzdata-2016d-1.el5.src.rpm Size : 1803555 License: Public Domain Signature : DSA/SHA1, Fri 22 Apr 2016 10:36:20 AM PDT, Key ID a8a447dce8562897 URL : https://www.iana.org/time-zones Summary : Timezone data Description : This package contains data files with rules for various time zones around the world ======================================================== Asia/Tijuana has DST started on 13 Mar 2016 and will End on 6 Nov 2016. On 13 Mar 2016 if i keep time as 02:00:00 it should ideally jump to 03:00:00 Similarly On 6 Nov 2016 if i keep time as 02:00:00 it should jump to 01:00:00 The same is not happening on my machine. ========================================================= . Please Help me out for resolving this Thanks and Regards Ajay

2 1

Chile time changed early?
by Matt Johnson May 13, 2016

May 13, 2016

http://www.wsj.com/articles/what-time-is-it-in-chile-theres-no-telling-1463… Since the change isn't scheduled until Sunday, the only way I can think that this happened is that the cell towers were updated prematurely. Can anyone confirm or comment? -Matt

3 4

America/ Santiago possible Correction
by Gretchen Gottsacker May 11, 2016

May 11, 2016

Greetings, I noticed there may be a discrepancy for the time zone America/ Santiago. As mentioned in the document NEWS "Also, call the period from 2014-09-07 through 2016-05-14 daylight saving time instead of standard time, as that seems more appropriate now." I believe is an incorrect statement as the link provided on the southamerica document provides these two links http://www.diariooficial.interior.gob.cl/versiones-anteriores/do/20160318/ and http://www.leychile.cl/Navegar?idNorma=1088502 which states that "as amended by Presidential Decree Nº106, 2015, both the Ministry of the Interior and Public Security, will be extended, as regards the year 2016, until 24 pm the second Saturday of May. Also, starting from the 24 hours of the second Saturday in August 2016 and until 24 pm the second Saturday in May 2017, the official time will advance in 60 minutes" Meaning daylight savings is not active until August 2016. Thank you, http://www.oracle.com/ Gretchen Gottsacker | BDE Support - BDE Engineer - Special Forces Oracle +1.800.806.6592 Oracle Service Cloud Support - USA - 45.6778° N, 111.0472° W http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment.

3 2

TZ Changing in Chile on May, 14th.
by Luis Martinez Villa May 3, 2016

May 3, 2016

Dear IANA TZ, Since the last time change Chile has been in GMT-3 (i.e. Chile is right now in GMT-3). Chile is going to GMT-4 in May,14th midnight and returning to GMT-3 in August, 13th midnight. That means clocks will go back 1 hour at 00:00 May 15th (jumping back to May 14th); and will go forward by 1 hour on 00:00, August 14th. In tzdata2016c I can see this new rules for Chile: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 2016 max - May Sun>=9 3:00u 0 - Rule Chile 2016 max - Aug Sun>=9 4:00u 1:00 S And I can see this Chile zone definition: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Santiago -4:42:46 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - CLT 1916 Jul 1 # Chile Time -4:42:46 - SMT 1918 Sep 10 -4:00 - CLT 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile CL%sT 1932 Sep 1 -4:00 - CLT 1942 Jun 1 -5:00 - CLT 1942 Aug 1 -4:00 - CLT 1946 Jul 15 -4:00 1:00 CLST 1946 Sep 1 # central Chile -4:00 - CLT 1947 Apr 1 -5:00 - CLT 1947 May 21 23:00 -4:00 Chile CL%sT But with these two information I'm not sure that in the midnight of May, 14th this tzdata2016c will change the TZ of Chile from GMT-3 to GMT-4. Can you please explain me how these structures in tzdata2016c work to accomplish the necessary TZ change in Chile. Thank you very much, best regards. Luis

3 2

[PROPOSED PATCH 1/2] Mostly work around Qt bug 53071 by inserting dummy
by Paul Eggert May 1, 2016

May 1, 2016

Problem reported by Zhanibek Adilbekov in: http://mm.icann.org/pipermail/tz/2016-April/023605.html Also see the Qt bug report in: https://bugreports.qt.io/browse/QTBUG-53071 * NEWS: Document this. * zic.c (WORK_AROUND_QTBUG_53071): New constant. (growalloc): Don't grow past INT_MAX - 1 if the bug is present, since we add 1 at the end. (writezone) [WORK_AROUND_QTBUG_53071]: Work around most of QTBUG-53071, by inserting a dummy transition at time 2**31 - 1. --- NEWS | 7 +++++++ zic.c | 30 +++++++++++++++++++++++++++--- 2 files changed, 34 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index e16f489..b5fb182 100644 --- a/NEWS +++ b/NEWS @@ -14,6 +14,13 @@ Unreleased, experimental changes Asia/Baku's 1992-09-27 transition from +04 (DST) to +04 (non-DST) was at 03:00, not 23:00 the previous day. (Thanks to Michael Deckers.) + Changes to code + + zic now outputs a dummy transition at time 2**31 - 1 in zones + whose POSIX-style TZ strings contain a '<'. This mostly works + around Qt bug 53071 <https://bugreports.qt.io/browse/QTBUG-53071>. + (Thanks to Zhanibek Adilbekov for reporting the Qt bug.) + Changes affecting documentation and commentary tz-link.htm says why governments should give plenty of notice for diff --git a/zic.c b/zic.c index 0ec3359..3b32f9b 100644 --- a/zic.c +++ b/zic.c @@ -143,6 +143,13 @@ static bool yearistype(int year, const char * type); /* Bound on length of what %z can expand to. */ enum { PERCENT_Z_LEN_BOUND = sizeof "+995959" - 1 }; +/* If true, work around a bug in Qt 5.6 and earlier, which mishandles + tzdata binary 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 is obsolete, say in + the year 2021. */ +enum { WORK_AROUND_QTBUG_53071 = true }; + static int charcnt; static bool errors; static bool warnings; @@ -420,7 +427,8 @@ growalloc(void *ptr, size_t itemsize, int nitems, int *nitems_alloc) if (nitems < *nitems_alloc) return ptr; else { - int amax = INT_MAX < SIZE_MAX ? INT_MAX : SIZE_MAX; + int nitems_max = INT_MAX - WORK_AROUND_QTBUG_53071; + int amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX; if ((amax - 1) / 3 * 2 < *nitems_alloc) memory_exhausted(_("int overflow")); *nitems_alloc = *nitems_alloc + (*nitems_alloc >> 1) + 1; @@ -1616,8 +1624,11 @@ writezone(const char *const name, const char *const string, char version) char * fullname; static const struct tzhead tzh0; static struct tzhead tzh; - zic_t *ats = emalloc(size_product(timecnt, sizeof *ats + 1)); - void *typesptr = ats + timecnt; + zic_t one = 1; + zic_t y2038_boundary = one << 31; + int nats = timecnt + WORK_AROUND_QTBUG_53071; + zic_t *ats = emalloc(size_product(nats, sizeof *ats + 1)); + void *typesptr = ats + nats; unsigned char *types = typesptr; /* @@ -1661,6 +1672,19 @@ writezone(const char *const name, const char *const string, char version) ats[i] = attypes[i].at; types[i] = attypes[i].type; } + + /* Work around QTBUG-53071 for time stamps less than y2038_boundary - 1, + by inserting a no-op transition at time y2038_boundary - 1. + This works only for timestamps before the boundary, which + should be good enough in practice as QTBUG-53071 should be + long-dead by 2038. */ + if (WORK_AROUND_QTBUG_53071 && timecnt != 0 + && ats[timecnt - 1] < y2038_boundary - 1 && strchr(string, '<')) { + ats[timecnt] = y2038_boundary - 1; + types[timecnt] = types[timecnt - 1]; + timecnt++; + } + /* ** Correct for leap seconds. */ -- 2.7.4

1 1

[PROPOSED PATCH] Fix minor glitches in Morocco rule formatting
by Paul Eggert April 30, 2016

April 30, 2016

These changes do not affect the data per se, only how it is formatted in the source. (Thanks to Corey Danielson.) * africa (Morocco): Use "0:00" for time, not "0". Sort 2012 transitions by date. --- africa | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/africa b/africa index 442b326..547e215 100644 --- a/africa +++ b/africa @@ -944,11 +944,11 @@ Rule Morocco 2009 only - Aug 21 0:00 0 - Rule Morocco 2010 only - May 2 0:00 1:00 S Rule Morocco 2010 only - Aug 8 0:00 0 - Rule Morocco 2011 only - Apr 3 0:00 1:00 S -Rule Morocco 2011 only - Jul 31 0 0 - +Rule Morocco 2011 only - Jul 31 0:00 0 - Rule Morocco 2012 2013 - Apr lastSun 2:00 1:00 S -Rule Morocco 2012 only - Sep 30 3:00 0 - Rule Morocco 2012 only - Jul 20 3:00 0 - Rule Morocco 2012 only - Aug 20 2:00 1:00 S +Rule Morocco 2012 only - Sep 30 3:00 0 - Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S Rule Morocco 2013 max - Oct lastSun 3:00 0 - -- 2.7.4

1 0

Programmatic way of determining the latest release number?
by Jon Skeet April 30, 2016

April 30, 2016

Hi folks, I'm aware of the ability to use ftp://ftp.iana.org/tz/tzcode-latest.tar.gz and the similar data URL to get the latest actual files, but is there a URL which either serves an HTTP redirect to the latest version, or gives the latest version number in some other easily-retrievable machine-readable format? I could parse the content of http://www.iana.org/time-zones, but that doesn't feel like a very robust approach :) Presumably this might all drop out of the tzdist work, but I was wondering whether there was a low-tech way at the moment. Jon

6 6

Re: [tz] Issue in Time Zone Database for Kazakhstan's zones
by Paul Eggert April 29, 2016

April 29, 2016

On 04/28/2016 10:27 AM, Zhanibek Adilbekov wrote: > > formats of zones are changed, e.g. for Asia/Almaty it changed from > ALMT to +06. I'm not familiar with TZ files, but I suppose this > changes are the reason of incompatibility for some apps. > Yes, I think that's relevant to the Plasma Digital Clock bug. I found what appears to be a related bug in the way that Qt handles data from tz 2016b, so the problem is not limited to tz 2016d. I can reproduce the problem by using just the Qt base, without involving KDE or Plasma. The Qt base parses tz data directly (!), and appears to do so incorrectly. I have filed a Qt bug report here: https://bugreports.qt.io/browse/QTBUG-53071 zic.c already has workarounds for buggy programs that misparse tzdata files containing time stamps far in the past, by putting in a no-change transition before the Big Bang. Perhaps there could be a similar workaround for this Qt bug, as Qt appears to mishandle tzdata files where the predicted future uses a POSIX TZ string that assumes POSIX.1-2001 or later. That is, perhaps we can work around the Qt bug by appending to the binary data some sort of no-change transition far enough in the future that we can expect Qt to be fixed in the field before most users care about those future time stamps. The year 2116, say?

1 1