October 2015 - tz - lists.iana.org

Asia/Nicosia
by Steven Nicolaou Oct. 3, 2015

Oct. 3, 2015

Hi, I would like to propose that Asia/Nicosia move to Europe/Nicosia. The Asia file makes this statement: # Classically, Cyprus belongs to Asia; e.g. see Herodotus, Histories, I.72. # However, for various reasons many users expect to find it under Europe. While I appreciate the nod to classical antiquity, its classification under Asia is wholly irrelevant today. This statement appears to trivialize the "various reasons" why "many users" tend to expect it under Europe. . Cyprus is a European country . The culture is decidedly Europe-facing . It is a member state of the European Union . Its currency is the Euro . It has participated in the Eurovision Song Contest since 1981 . Its time zone is Eastern European Time (EET) . The predominant culture and language is Greek . The earliest historical reference to Cyprus in the 15th century BC was in Mycenaean Greek . The Asia file itself even mentions this: "# IATA SSIM (1998-09) has Cyprus using EU rules for the first time." There is nothing Asian about Cyprus today. Nobody in the country attempting to set the local time zone is going to look for it under Asia. If we don't find it under Europe, we assume it was erroneously omitted. Steven

3 2

Last weekend's daylight-saving confusion in Morocco
by Paul Eggert Oct. 1, 2015

Oct. 1, 2015

Thomas Savage reports confusion in Morocco last weekend involving daylight saving time. See: Savage T. Quelle heure est-il vraiment au Maroc? Telquel.ma 2015-09-30. http://telquel.ma/2015/09/30/quelle-heure-il-vraiment-au-maroc_1464578 Savage quotes last month's confusion on the tz mailing list over whether Morocco's fallback transition this year would be Sept. 27 (as an incorrect news report would have it) or Oct. 25 (the official date), and speculates that this confusion led to many electronic devices in Morocco to misbehave on Sept. 27. In thinking about the failure symptoms, though, I guess a more plausible explanation is that the malfunctioning devices were using the equivalent of a tz release somewhere from tzdata 2012c (dated 2012-03-07) through 2013g (dated 2013-09-30), as these older releases predicted that Morocco would fall back the last Sunday in September -- a prediction that was correct in 2012 but incorrect in 2013 through 2015.

1 0

[tz-announce] 2015g release of tz code and data available
by Paul Eggert Oct. 1, 2015

Oct. 1, 2015

The 2015g 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 Turkey's 2015 fall-back transition is scheduled for Nov. 8, not Oct. 25. (Thanks to Fatih.) Norfolk moves from +1130 to +1100 on 2015-10-04 at 02:00 local time. (Thanks to Alexander Krivenyshev.) Fiji's 2016 fall-back transition is scheduled for January 17, not 24. (Thanks to Ken Rylander.) Fort Nelson, British Columbia will not fall back on 2015-11-01. It has effectively been on MST (-0700) since it advanced its clocks on 2015-03-08. New zone America/Fort_Nelson. (Thanks to Matt Johnson.) Changes affecting past time stamps Norfolk observed DST from 1974-10-27 02:00 to 1975-03-02 02:00. Changes affecting code localtime no longer mishandles America/Anchorage after 2037. (Thanks to Bradley White for reporting the bug.) On hosts with signed 32-bit time_t, localtime no longer mishandles Pacific/Fiji after 2038-01-16 14:00 UTC. The localtime module allows the variables 'timezone', 'daylight', and 'altzone' to be in common storage shared with other modules, and declares them in case the system <time.h> does not. (Problems reported by Kees Dekker.) On platforms with tm_zone, strftime.c now assumes it is not NULL. This simplifies the code and is consistent with zdump.c. (Problem reported by Christos Zoulas.) Changes affecting documentation The tzfile man page now documents that transition times denote the starts (not the ends) of the corresponding time periods. (Ambiguity reported by Bill Seymour.) Here are links to the release files: ftp://ftp.iana.org/tz/releases/tzcode2015g.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2015g.tar.gz The files are also available via HTTP as follows: http://www.iana.org/time-zones/repository/releases/tzcode2015g.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2015g.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 6d00980f1ff2ac665f3de027c79faacf4f26d1b0 dated Thu Oct 1 01:43:59 2015 -0700 and tagged '2015g' in the experimental github repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 44da833da3afdb82636a953785372bb4c765e61e40d700da40b46ab70007ebdbde4d480e10b87cbb36c45eaaffcaa6b9894375e2f553b7d16655dc167cd4a11f tzcode2015g.tar.gz ad7de0e3e8753861d260f0fcbcbca327516a4dc826f7659370a7fb979e6154f1a26b23d2609acf6e1790c8c59da0b76c42f4a94bf361409c1460f6a8ffa6f879 tzdata2015g.tar.gz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJWDP2cAAoJEO2X6Q5iqn40XHkP/2QXgHEJuj0XQaMy0Wy5RZQT vrWN0z8zfO5J5LBv03cjNmeYsmQvN2Sy2f2wNESo0GUm4qunujQW/Y0qKRn1Hnwz +nRNrWFmGqYFANapR9emUorucl+l24VQUkBc7piAkVZU1ouEsksHss3uYnNfCwyl L/2Vc7KY07/N6QyAmdiSp3AKWu0CnItsdzRyy99amj/7d3QKOrMvAxiGeAe7V1P7 W0Ath56JxTnuHMCOawHTUtzBt13qjZ7cFBHsOb4xclrZ3ryNnu3Pzd94bxeP3NGp 4AkfTcgo0mYrIMAuf/b40xbZJBcZNzkbCbZ5iE2XMVPToMPL/I2e4C+rZP+Ot7fv TkChGvv9ridmeEqTIVCtOXyR8AQGgGCNpMKsEE1Py5Lkx63gMBtxkdSXOZXi+QZ5 UljSY8RT2vQ81eailUGQRjtLyTGlhmel3yioD+aXbJyiYVrkSOfQ/En5wcIMtWqm DwgTsaIX70gT+1CUVLixdEdUSKhd9p+Voypvf14xIcAYqii08jlvd8AeR1IY5+Uz yr09gX7esp3B+9HgRgkH82R5nqstWbuc/5sVlnreM+7obnc5/QWPHoDUWgJQO7sk R/Cb6Kc32UrfZwAmy4rRoOA4uTsYvIazqoaiuE/sfNSRUD3R4rOQPDxXMx6m/kbf bGwkIeBRSuC9nmVI40G+ =U0wm -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJWDP2cAAoJEO2X6Q5iqn40AUcQAJQI8NTDYuLOHrsnnbpdmmF4 DG91kmznvXK+S5AjXbeUtSyoLL/XJwq2Io25u7OKaH5O+9/HgcN1Y1afHtSHAhEB i8Mg0sfvV6IJRpIKA/++6VILRqgKCOLzxyggk7dZbdAQQdvl4z2qmWR/5m5nJ7K/ seE+sTsJ1j6ra77APK+ffauoN7ArFweMmpVC3tBSkBpCXYPPuGToBfGxFo3gnpni Kqv/ahjlRNUcmyw/ALbCdBEL40k7bxftL6uM0BbapV2GYVU+UTz+isVStHmg3P5V TS1gpgmjKMDBh4P0UEiaVhtsI+EBNU1YW/o8c2xdoGuz6qgbxeeMyrPxUQu2qb0w LDHovfsIhoB2YNTGK2M+1aio2lkhcV+AX7241RuGxiP/n92c+6SPGlY7o69XQqaC i58/AjS3a6E7yYgb+birN+/Yi0KzxWwI6nJMxlLSfc9yFZREf9nCd+7YPcSSJJIO 3fbsFNJPoPa36hfMH83L0rmyphpQEU2+46+BboqQhL9ULV4QhYiNCeXXyZm1ptDl BMyjxh2mO+sPDE47xyI7tsl94dzbgmWMSQp74SlFLDPaK065x5U+Z8437oiMip5K rhVXzr/vyrzX/Anyok05i3lmY3iAFyBIFuv7s93nr0SnrZDjCDq6FafLSOnvIhD7 4R6azOsK4h1HbCxswUCK =yiad -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Fiji change exposed Y2038 bug in localtime.c
by Paul Eggert Oct. 1, 2015

Oct. 1, 2015

The recent change to the Pacific/Fiji data added a transition from +1300 to +1200 at 2018-01-17 03:00 local time, which is just before the maximum 32-bit signed time_t value. Previously, that transition was just after the 32-bit boundary. This change exposed a curious bug in the interaction between zic and localtime.c on platforms with signed 32-bit time_t. For the benefit of older systems, zic outputs explicit transitions for years in the range 1900 through 2037, relying on the POSIX-TZ-style string (for Pacific/Fiji, "FJT-12FJST,M11.1.0,M1.3.0/3") at the end of the tzfile for transitions outside that range. Although newer versions of localtime.c should use the POSIX-TZ-style string for time stamps in the year 2038, if time_t is a signed 32-bit integer these localtime.c versions mishandle Fijian time stamps from 2038-01-16 14:00:00 through 2038-01-19 03:14:07 UTC. This bug is fixed by the attached patch. I discovered this bug during release testing, and will squeeze the attached patch into the next tz release which I plan to make shortly. It strikes me, though, that perhaps zic should be changed too, to better accommodate buggy localtime implementations. If the zic cutoff for old-style transitions is at 2038-01-19 03:14:08 UTC, rather than at 2038-01-01, buggy localtime code should do the right thing. I don't want to install such a change into zic without some thought and/or discussion and/or testing, though; it can wait until a later release.

2 2