Luis Martinez Villa | 3 May 01:08 2016
Picon

[tz] TZ Changing in Chile on May, 14th.

  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


Paul Eggert | 1 May 10:56 2016

[tz] [PROPOSED PATCH 1/2] Mostly work around Qt bug 53071 by inserting dummy

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
 <at>  <at>  -14,6 +14,13  <at>  <at>  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
 <at>  <at>  -143,6 +143,13  <at>  <at>  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;
 <at>  <at>  -420,7 +427,8  <at>  <at>  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;
 <at>  <at>  -1616,8 +1624,11  <at>  <at>  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;

 	/*
 <at>  <at>  -1661,6 +1672,19  <at>  <at>  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

WorldTimeServer.com Support | 29 Apr 15:06 2016

Re: [tz] Egypt to have DST again

We have seen similar reports. This one with an Oct date, but nothing official. Chasing down sources now.

SUMMER TIME IN A.R.E (UTC +3 HOURS) SHALL BE APPLIED THIS YEAR

WEF 0001 LOCAL TIME ON 08 JUL 2016 AND END AT 2100 UTC ON 27 OCT

2016.



--
Thanks,
Chris

On Fri, Apr 29, 2016 at 1:24 AM, Steffen Thorsen <thorsen <at> timeanddate.com> wrote:
Several of our users have reported on new DST plans in Egypt, which is confirmed by
several sources that all say Egypt will have DST from July 7 until the end of October.

Unfortunately, "end of October" is very vague, but we at timeanddate.com would assume a rule like this for it, based on their historic end dates:
Rule    Egypt    2016    max    -    Oct    lastThu    23:00s 0    -
We also assume it will start at the end of July 7 (midnight between Thursday and Friday).

http://english.ahram.org.eg/NewsContentP/1/204655/Egypt/Daylight-savings-time-returning-to-Egypt-on--July.aspx
http://www.nileinternational.net/en/?p=25806

I found it interesting that EgyptAir seems to have assumed DST to start in April (like it previously did in 2010), and therefore this obviously causes problems with the schedules:

http://www.egyptair.com/en/about-egyptair/news-and-press/Pages/CANCELLATION%20OF%20DAYLIGHT%20SAVING%20TIME.aspx

Best regards,
Steffen Thorsen - timeanddate.com

Zhanibek Adilbekov | 28 Apr 19:41 2016
Picon
Gravatar

Re: [tz] Issue in Time Zone Database for Kazakhstan's zones

I looked at this commit, which adjusts some transitions for KZ. After looking closer to diffs I found out that 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.


On 28.04.2016 22:48, Paul Eggert wrote:
On 04/28/2016 04:15 AM, Zhanibek Adilbekov wrote:
After upgrading tzdata to 2016d version some of applications unable to determine right timezone for all zones which belong to Kazakhstan. I personally use Asia/Almaty (which is +06:00 and no DST) on my machine (Arch Linux with Plasma 5.6), and it leads some programs to produce unexpected results. E.g.: Digital Clock applet shows -12 hours from current time and Plasma Lockscreen shows time in UTC.


I'm not observing this problem on Fedora 23 (2016d-1.fc23) with gnome-clocks (3.18.0-1.fc23).

Other users have reported problems with the Plasma Digital Clock applet after earlier tzdata upgrades. See for example:

https://bbs.archlinux.org/viewtopic.php?id=193233

https://bugs.kde.org/show_bug.cgi?id=343610

https://www.kubuntuforums.net/showthread.php?69655-Issues-with-Plasma-Digital-Clock-Widget

The first thread says that a relevant bug was fixed in plasma 5.5; are you running that version? If not, I suggest upgrading. If so, perhaps there are other, similar bugs that haven't been fixed yet.


-- Best regards, Zhanibek Adilbekov. Tel: +7 707 817 5253 Skype: zhanibek.adilbekov Email: zhanibek.adilbekov <at> gmail.com zhanibek.adilbekov <at> live.com liljay.it <at> gmail.com
Paul Eggert | 1 May 02:41 2016

[tz] [PROPOSED PATCH] Fix minor glitches in Morocco rule formatting

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
 <at>  <at>  -944,11 +944,11  <at>  <at>  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

Jon Skeet | 30 Apr 09:39 2016
Picon
Gravatar

[tz] Programmatic way of determining the latest release number?

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

Howard Hinnant | 29 Apr 18:25 2016
Picon
Gravatar

Re: [tz] Proposal: validation text file with releases

How do you feel about putting the version number at the top of the validation file?  This more tightly couples
the version number with the validation data, making the name of the validation file less relevant.

Howard

On Apr 29, 2016, at 12:09 PM, Jon Skeet <skeet <at> pobox.com> wrote:
> 
> Right. Will modify my code and docs, then update the web site. Will probably add hashes on the web site at the
same time.
> 
> Jon
> 
> 
> On 29 April 2016 at 17:05, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Jon Skeet wrote:
> > As one point I suspect we could all agree on: assuming there is to be a
> > canonical format, should we use "\n" as the line separator?
> 
> Oh, yes.
> 
> 

Zhanibek Adilbekov | 28 Apr 13:15 2016
Picon
Gravatar

[tz] Issue in Time Zone Database for Kazakhstan's zones

After upgrading tzdata to 2016d version some of applications unable to determine right timezone for all zones which belong to Kazakhstan. I personally use Asia/Almaty (which is +06:00 and no DST) on my machine (Arch Linux with Plasma 5.6), and it leads some programs to produce unexpected results. E.g.: Digital Clock applet shows -12 hours from current time and Plasma Lockscreen shows time in UTC.
I tried downgrade to 2016c and it works just fine.

Please fix the issue, or at least return to previous state (which worked fine). Thanks!

-- Best regards, Zhanibek Adilbekov. Tel: +7 707 817 5253 Skype: zhanibek.adilbekov Email: zhanibek.adilbekov <at> gmail.com zhanibek.adilbekov <at> live.com liljay.it <at> gmail.com
Matt Johnson | 24 Apr 01:15 2016
Picon
Gravatar

[tz] Blog Post: On the Timing of Time Zone Changes

I've written a blog post describing the chaos that ensues when governments don't provide enough notice of their changes to time zones.

http://codeofmatt.com/2016/04/23/on-the-timing-of-time-zone-changes/


Enjoy!

-Matt

Alexander Krivenyshev | 23 Apr 02:01 2016

[tz] Tomsk to change time zone on May 29, 2016

Just to reconfirm Stepan Golosunov about Tomsk time change:

The bill passed its 3rd reading by the State Duma on April 15, 2016 and 

was approved by the Federation Council on April 20, 2016.

Waiting to be officially sign by the President.

Ref. links:

http://asozd2.duma.gov.ru/main.nsf/%28SpravkaNew%29?OpenAgent&RN=1006865-
6&02

http://asozd2.duma.gov.ru/work/dz.nsf/ByID/1243C6FFC37C451143257F94004BE6D8/
$File/%D0%A2%D0%B5%D0%BA%D1%81%D1%82%20%D0%B7%D0%B0%D0%BA%D0%BE%D0%BD%D0%B0%
20-%203%20%D1%87%D1%82%D0%B5%D0%BD%D0%B8%D0%B5.doc?OpenElement

with 99.99% certainty, Tomsk will move from UTC+6 to UTC+7 time zone

on May 29, 2016 at 2 o'clock 00 minutes.

Alexander Krivenyshev

http://www.worldtimezone.com

New York, NY

Paul Eggert | 18 Apr 18:55 2016

[tz] [tz-announce] 2016d release of tz code and data available

The 2016d release of the tz code and data is available. It reflects the 
following changes, which were either circulated on the tz mailing list 
or are relatively minor technical or administrative changes:

   Changes affecting future time stamps

     America/Caracas switches from -0430 to -04 on 2016-05-01 at 02:30.
     (Thanks to Alexander Krivenyshev for the heads-up.)

     Asia/Magadan switches from +10 to +11 on 2016-04-24 at 02:00.
     (Thanks to Alexander Krivenyshev and Matt Johnson.)

     New zone Asia/Tomsk, split off from Asia/Novosibirsk. It covers
     Tomsk Oblast, Russia, which switches from +06 to +07 on 2016-05-29
     at 02:00.  (Thanks to Stepan Golosunov.)

   Changes affecting past time stamps

     New zone Europe/Kirov, split off from Europe/Volgograd.  It covers
     Kirov Oblast, Russia, which switched from +04/+05 to +03/+04 on
     1989-03-26 at 02:00, roughly a year after Europe/Volgograd made
     the same change.  (Thanks to Stepan Golosunov.)

     Russia and nearby locations had daylight-saving transitions on
     1992-03-29 at 02:00 and 1992-09-27 at 03:00, instead of on
     1992-03-28 at 23:00 and 1992-09-26 at 23:00.  (Thanks to Stepan
     Golosunov.)

     Many corrections to historical time in Kazakhstan from 1991
     through 2005.  (Thanks to Stepan Golosunov.)  Replace Kazakhstan's
     invented time zone abbreviations with numeric abbreviations.

Here are links to the release files:

   ftp://ftp.iana.org/tz/releases/tzcode2016d.tar.gz
   ftp://ftp.iana.org/tz/releases/tzdata2016d.tar.gz

The files are also available via HTTP as follows:

http://www.iana.org/time-zones/repository/releases/tzcode2016d.tar.gz
http://www.iana.org/time-zones/repository/releases/tzdata2016d.tar.gz

As usual, links to the latest release files are here:

http://www.iana.org/time-zones/repository/tzcode-latest.tar.gz
http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz

   ftp://ftp.iana.org/tz/tzcode-latest.tar.gz
   ftp://ftp.iana.org/tz/tzdata-latest.tar.gz

Each release file has a GPG signature, which can be retrieved by 
appending ".asc" to the above URLs.  Copies of these signatures are 
appended to this message.

This release corresponds to commit 
8af4367f30c176794a0d283d3efaeaa80db676fa dated 2016-04-17 22:50:29 -0700 
and tagged '2016d' in the experimental github repository at 
<https://github.com/eggert/tz>.

Here are the SHA-512 checksums for the release
files:

c6f6259a78fadaab293be0a4123c226d1a327588639cfa8dadb5a74bd58552892a0c87cfd3a33888f886f51aff34465c89505f0892e6bcbe24247a9160e7328c

tzcode2016d.tar.gz
f1beb1793c4c7d18f2dadaf4a928b1476f66b400bda0c87b06155c0dd1c4b4a26bb2f37dc17a3676a2bbe9c1e71a5d8b27a171c797a86464b0bc0d13abfb2f99 
tzdata2016d.tar.gz

Here are the GPG checksums for the release files:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJXFHY7AAoJEO2X6Q5iqn40xFwP/jJKqrqmcaZWBcEhIYQyzBxR
VX0hCaPhkz1f0gqJF8ViwDi99VWewpMqk/Xo3aB3UVKEyZM3q/w8CrHUE8vfQb39
BlCMlkqKP9M+8L8qWRiLRcZQcZdrOn0oFUPKnvXwKLq9UCuYAvveHSr4eHt4cqlZ
XhBUnPplqY05PmhJzHz+ir5MqMihV/p075YafU4bXfquqOyGbwxe+EYzkg6E7Yxj
d2nVpMYbS6NLE59EjsOt5GKi2SJA8S+6DFHX30GXpzMgREK2knbic2FkiLpfEWNc
6r13h+UOYPIREWH3jFoFe5YOAwOkkj+bLKSkDMdt2roEafOYtHp89lC/OGtnKkUK
cvwJcjOy5Ijp55w2Goa/HrUtcXFW7RuCe+kknMbjxo6II9hi8h43eOkZ8I6CRneS
FT9ZEhor/rek45yY7O7sGRXleRD1pmL14XOlNoM80KPwJ9t1QxxzxQu9oFl3UQ1d
Gf/zJe5BuW9P3jkijPj0IQfKDOlYEduYEodFKuqPinEj7ojw8QmF2DvhfXQYXQVq
Ld1SM0wZiR4CUn6t66v0ySYs5RJ7gheMujbDckWsL+b7MyCJBQG4fWNoKdjAWcf9
QKtlLDHIFu+7LkGXoSbQSwgRgSYof33YSZ2uBd5zulyE/tKOStSvUaCHTqA4w3yA
EcKP3whBf89FqxlYGidk
=decU
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJXFHZEAAoJEO2X6Q5iqn40/7oP/1iCUfTrL+ZSgp4wnWIXLnkS
cxWWd43CaHW82JpupOHAsp/DcnfL5s5xLAbSLHV1kjb2Gx+NesUKxvqpW9kFYBoX
HIIYke1Q4w7tj5wIqFy4X1Fl6fJ+2oEFv4Rmj6d0P6m/9ZVHxOlTY7Wf7f8mSDP5
noC/moGNq/UA6em0t667yxPY2HhvHExSedLD82ktFNZkGVp22npVhz2ZD4M4aYzj
lFSKSG4bmM6bOA2Wny7REd5+O1CGyuT1gIxziEA8aW+eaovqWVb7u6yX6hefpUdk
Vd1p9BE6e/q7Q7F+fXozuHGlFont9iKpYes2lYp3T7idU88MFqdCuDrXUaQ/eyJe
LNlhOBNupRGrtSQeNWfriLfBslOmsFXUdu8vG7HwjYRNJKa/sqtf//apkP42oUEB
j49DrkC7Wo4kn59XPvBohb6ZCHQ7Lh+vk9kLLEC3QisBB0qM5rTjH4VWDHtpu830
u3W77k4MAIRYT2k4Xfl/kCfHFzdGEuPDEcxfEbMJYf9jbzU9PGiO3wMq7sdaDnDj
+EQShM3td9nNViiCXuI3By4mkN0jwIO/DUAyDRM+3n0NehtOSPpISVUPl4q/Ng5v
tT9ICFHwrr53NkpFB0AKsbjZ883uHJFrdzIHxhc2P0O9tj7uUnP4WlIaR/C8D4+d
timbEfko5hFhc4WZWdqv
=+50X
-----END PGP SIGNATURE-----

Gmane