- tz - lists.iana.org

Haiti on DST again
by Steffen Thorsen March 12, 2017

March 12, 2017

We have received 4 mails from different people telling that Haiti has started DST again today, and this source seems to confirm that, I have not been able to find a more authoritative source: https://www.haitilibre.com/en/news-20319-haiti-notices-time-change-in-haiti… Best regards, Steffen Thorsen - timeanddate.com

2 1

Regarding mktime issue
by Gopesh Kumar Chaudhary March 9, 2017

March 9, 2017

Hello Everyone, This is Gopesh Kumar Chaudhary from India. I have couple of queries regarding mktime function. e.g. TZ=Europe/Berlin (Olson) struct tm prnt_time; prnt_time.tm_wday = 0; prnt_time.tm_mon = 10 - 1; prnt_time.tm_mday = 30; prnt_time.tm_hour = 2; prnt_time.tm_min = 0; prnt_time.tm_sec = 0; prnt_time.tm_year = 116; prnt_time.tm_isdst = -1; Above tm structure represent 30th OCT 2:30 2016 for Europe/Berlin in Olson . For Europe/Berlin DST fallback will happen on 30th Oct at 3 , so clock will show 2 to 3 time period twice. I have set the dst flag to -1 , for mktime to decide whether the given time in tm structure is DST time or non DST time. Now coming to my query : 1) In above mentioned scenario does mktime has the intelligence to decide whether above mentioned time in tm structure is in DST or not as dst flag is set to -1 ? 2) I have a sample code Sample code :- ----------------------- # cat gops.c #include<stdio.h> #include<time.h> int main(int argc,char **argv){ struct tm *at; time_t when,now; now=atoi(argv[1]); at=localtime(&now); at->tm_isdst = -1; when=mktime(at); printf("now=%d when=%d\n",now,when); return 0; } OS: Linux (RHEL 7.2) Platform:x86 TZ:Europe/Berlin (Olson) # ./gops 1477787940 ==============>This epoch is for 2:39 30th Oct 2016 DST now=1477787940 when=1477791540 ====>Here mktime is giving me the epoch for 2:39 30th Oct 2016 non-DST # ./gops 1477791540 ==============>This epoch is for 2:39 30th Oct 2016 non DST now=1477791540 when=1477791540 ====>Here mktime is giving me the epoch for 2:39 30th Oct 2016 non-DST With the above example it can be seen that irrespective of the DST/non-DST window , it is always giving non DST epoch only ---- Is this standard behavior or is this bug in mktime ? Thanks. Regards, Gopesh Kumar Chaudhary

2 3

USNO web site down
by Arthur David Olson March 9, 2017

March 9, 2017

Just in time for this weekend's winter forward in the US, as noted by Neal Augenstein on Twitter: "Hmph, wanna see when spring starts? US Naval Observatory site and master clock are down." https://twitter.com/AugensteinWTOP/status/839900149375774720 http://www.usno.navy.mil/USNO/time/display-clocks/simpletime @dashdashado

2 1

Re: [tz] tz abbr too long in 2017a Africa/Monrovia [was: zic throws warning for 2007a]
by Brian Inglis March 3, 2017

March 3, 2017

On 2017-03-02 18:47, Jonathan Leffler wrote: > On Wed, Mar 1, 2017 at 2:16 PM, Brian Inglis wrote: >On 2017-03-01 14:48, Tim Parenti wrote: >> On 1 March 2017 at 16:42, Brian Inglis wrote: >> Looks like it stores the over long abbreviation. >> So should probably patch: >> --- tz/releases/tzdata2017a/africa 2017-02-23 00:37:19.000000000 -0700 >> +++ tz/releases/tzdata2017b/africa 2017-03-01 14:36:43.479882200 -0700 >> @@ -431,7 +431,7 @@ Link Africa/Nairobi Indian/Mayotte >> # Zone NAME GMTOFF RULES FORMAT [UNTIL] >> Zone Africa/Monrovia -0:43:08 - LMT 1882 >> -0:43:08 - MMT 1919 Mar # Monrovia Mean Time >> - -0:44:30 - -004430 1972 May >> + -0:44:30 - -0044 1972 May >> 0:00 - GMT >> The above patch would be incorrect, though. It would be more correct >> to increase the allowed max abbreviation length. (Even better, >> numerical "abbreviations" like this should just be exempted from the >> caps, since they can technically be of almost any length, even though >> this is the longest they'll be in practice.) >POSIX limit in limits.h: >http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag… >under TZ definition for std and dst (abbrs) >"The interpretation of these fields is unspecified if either field is >less than three bytes (except for the case when dst is missing), more >than {TZNAME_MAX} bytes, or if they contain characters other than those >specified." >http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html#tag_… >"{_POSIX_TZNAME_MAX} >Maximum number of bytes supported for the name of a timezone (not of >the TZ variable). >Value: 6" > Note that the spiel above the entry for {_POSIX_TZNAME_MAX} says: > The /<limits.h>/ header shall define the following symbolic constants > with the values shown. These are the most restrictive values for > certain features on an implementation conforming to this volume of > POSIX.1-2008. Related symbolic constants are defined elsewhere in > this volume of POSIX.1-2008 which reflect the actual implementation > and which need not be as restrictive. For each of these limits, a > conforming implementation shall provide a value at least this large > or shall have no limit. A strictly conforming application must not > require a larger value for correct operation. > Is the code in tzcode intended to be a strictly conforming > application? From: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html#tag… the application is not a Strictly Conforming POSIX Application as it does not #define _POSIX_C_SOURCE 200809L, and is not a Conforming POSIX Application as it does not include a "statement of conformance that documents all options and limit dependencies, and all other ISO or IEC standards used", although commentary indicates POSIX compliance where notable. AFAICT like many packages, it is intended to be POSIX compliant and provide POSIX compliant implementations, to be portable to POSIX compliant and some non-POSIX systems. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

1 0

Problem with historical Asia/Manila?
by Paul Goyette March 3, 2017

March 3, 2017

According to the asia file, the Philippines jumped 24 hours on May 11, 1899, from -15:56:00 to +8:04:00 (they moved the international date line?) # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Manila -15:56:00 - LMT 1844 Dec 31 8:04:00 - LMT 1899 May 11 8:00 Phil +08/+09 1942 May 9:00 - +09 1944 Nov 8:00 Phil +08/+09 Yet zdump shows only a 4-minute step in local time, rather than the expected 24-hour step: # zdump -c 1815,2018 -v Asia/Manila Asia/Manila -9223372036854775808 = NULL Asia/Manila -9223372036854689408 = NULL Asia/Manila Tue Dec 31 15:55:59 1844 UT = Mon Dec 30 23:59:59 1844 LMT isdst=0 gmtoff=-57360 Asia/Manila Tue Dec 31 15:56:00 1844 UT = Wed Jan 1 00:00:00 1845 LMT isdst=0 gmtoff=29040 Asia/Manila Wed May 10 15:55:59 1899 UT = Wed May 10 23:59:59 1899 LMT isdst=0 gmtoff=29040 Asia/Manila Wed May 10 15:56:00 1899 UT = Wed May 10 23:56:00 1899 +08 isdst=0 gmtoff=28800 Asia/Manila Sat Oct 31 15:59:59 1936 UT = Sat Oct 31 23:59:59 1936 +08 isdst=0 gmtoff=28800 ... Obviously a low-priority issue, since it's more than 100 years ago, but still would be nice to know why we have a problem. It's not totally out of the realm of probability that someone will move the dateline again, perhaps if the UTC+14 parts of Kiribati were to separate from the rest of the country? :) Data gathered on a NetBSD 7.99.64 system running on amd64 hardware, and using the 2017a tzdata. I think we're still running 2016i version of tzcode. So the question(s): * is zdump wrong? * is the compiled data file wrong? * (most likely) am I just misinterpreting the data? * is this something that has already been fixed in a more recent tzcode release? +------------------+--------------------------+------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +------------------+--------------------------+------------------------+

3 3

zic throws warning for 2007a
by Derick Rethans March 1, 2017

March 1, 2017

Hi, I've just updated the PHP version of the TZ database, and while compiling with the current zic, I see: warning: "standard input", line 434: time zone abbreviation has too many characters (-004430) This is because of: 24 #ifndef ZIC_MAX_ABBR_LEN_WO_WARN 25 #define ZIC_MAX_ABBR_LEN_WO_WARN 6 26 #endif /* !defined ZIC_MAX_ABBR_LEN_WO_WARN */ 3108 if (cp - string > ZIC_MAX_ABBR_LEN_WO_WARN) 3109 mp = _("time zone abbreviation has too many characters"); That check was introduced in 2012j as per NEWS: Release 2012j - 2012-11-12 18:34:49 -0800 ... zic -v now complains about abbreviations that are less than 3 or more than 6 characters, as per Posix. Formerly, it checked for abbreviations that were more than 3. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug

6 6

TZ changes
by Igor Trud Feb. 28, 2017

Feb. 28, 2017

Hi. Europe/Volgograd is not in MSK ( GMT+3) since 03 Dec 2016 Now, its MSK + 1 (GMT +4). Should tzinfo database accept this change ? Thanks. Igor.

2 1

[PATCH] Fix warnings if !ALL_STATE: address of gmtmem always, evaluates as true
by Andreas Stieger Feb. 28, 2017

Feb. 28, 2017

Hello, fixes some compiler warnings: If ALL_STATE is not defined, the address of gmtcheck always evaluates to true. Andreas -- Andreas Stieger <astieger(a)suse.com> Project Manager Security SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

2 3

[tz-announce] 2017a release of tz code and data available
by Paul Eggert Feb. 28, 2017

Feb. 28, 2017

The 2017a 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: Briefly: Southern Chile moves from -04/-03 to -03, and Mongolia discontinues DST. Changes to future time stamps Mongolia no longer observes DST. (Thanks to Ganbold Tsagaankhuu.) Chile's Region of Magallanes moves from -04/-03 to -03 year-round. Its clocks diverge from America/Santiago starting 2017-05-13 at 23:00, hiving off a new zone America/Punta_Arenas. Although the Chilean government says this change expires in May 2019, for now assume it's permanent. (Thanks to Juan Correa and Deborah Goldsmith.) This also affects Antarctica/Palmer. Changes to past time stamps Fix many entries for historical time stamps for Europe/Madrid before 1979, to agree with tables compiled by Pere Planesas of the National Astronomical Observatory of Spain. As a side effect, this changes some time stamps for Africa/Ceuta before 1929, which are probably guesswork anyway. (Thanks to Steve Allen and Pierpaolo Bernardi for the heads-ups, and to Michael Deckers for correcting the 1901 transition.) Ecuador observed DST from 1992-11-28 to 1993-02-05. (Thanks to Alois Treindl.) Asia/Atyrau and Asia/Oral were at +03 (not +04) before 1930-06-21. (Thanks to Stepan Golosunov.) Changes to past and future time zone abbreviations Switch to numeric time zone abbreviations for South America, as part of the ongoing project of removing invented abbreviations. This avoids the need to invent an abbreviation for the new Chilean new zone. Similarly, switch from invented to numeric time zone abbreviations for Afghanistan, American Samoa, the Azores, Bangladesh, Bhutan, the British Indian Ocean Territory, Brunei, Cape Verde, Chatham Is, Christmas I, Cocos (Keeling) Is, Cook Is, Dubai, East Timor, Eucla, Fiji, French Polynesia, Greenland, Indochina, Iran, Iraq, Kiribati, Lord Howe, Macquarie, Malaysia, the Maldives, Marshall Is, Mauritius, Micronesia, Mongolia, Myanmar, Nauru, Nepal, New Caledonia, Niue, Norfolk I, Palau, Papua New Guinea, the Philippines, Pitcairn, Qatar, Réunion, St Pierre & Miquelon, Samoa, Saudi Arabia, Seychelles, Singapore, Solomon Is, Tokelau, Tuvalu, Wake, Vanuatu, Wallis & Futuna, and Xinjiang; for 20-minute daylight saving time in Ghana before 1943; for half-hour daylight saving time in Belize before 1944 and in the Dominican Republic before 1975; and for Canary Islands before 1946, for Guinea-Bissau before 1975, for Iceland before 1969, for Indian Summer Time before 1942, for Indonesia before around 1964, for Kenya before 1960, for Liberia before 1973, for Madeira before 1967, for Namibia before 1943, for the Netherlands in 1937-9, for Pakistan before 1971, for Western Sahara before 1977, and for Zaporozhye in 1880-1924. For Alaska time from 1900 through 1967, instead of "CAT" use the abbreviation "AST", the abbreviation commonly used at the time (Atlantic Standard Time had not been standardized yet). Use "AWT" and "APT" instead of the invented abbreviations "CAWT" and "CAPT". Use "CST" and "CDT" instead of invented abbreviations for Macau before 1999 and Taiwan before 1938, and use "JST" instead of the invented abbreviation "JCST" for Japan and Korea before 1938. Change to database entry category Move the Pacific/Johnston link from 'australasia' to 'backward', since Johnston is now uninhabited. Changes to code zic no longer mishandles some transitions in January 2038 when it attempts to work around Qt bug 53071. This fixes a bug affecting Pacific/Tongatapu that was introduced in zic 2016e. localtime.c now contains a workaround, useful when loading a file generated by a buggy zic. (Problem and localtime.c fix reported by Bradley White.) zdump -i now outputs non-hour numeric time zone abbreviations without a colon, e.g., "+0530" rather than "+05:30". This agrees with zic %z and with common practice, and simplifies auditing of zdump output. zdump is now buildable again with -DUSE_LTZ=0. (Problem reported by Joseph Myers.) zdump.c now always includes private.h, to avoid code duplication with private.h. (Problem reported by Kees Dekker.) localtime.c no longer mishandles early or late timestamps when TZ is set to a POSIX-style string that specifies DST. (Problem reported by Kees Dekker.) date and strftime now cause %z to generate "-0000" instead of "+0000" when the UT offset is zero and the time zone abbreviation begins with "-". Changes to documentation and commentary The 'Theory' file now better documents choice of historical time zone abbreviations. (Problems reported by Michael Deckers.) tz-link.htm now covers leap smearing, which is popular in clouds. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2017a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2017a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2017a.tar.lz As usual, links to the latest release files are here: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. 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 8beaf3b064b8edcb09babb62e530993808003802 dated 2017-02-28 00:05:36 -0800 and tagged '2017a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 36d744debd5263b6be39b3a9a146b7db1876f216a4bfc62b46631745861a9c03eda3220f213def86c724d3a11c41398c65c2e5d013ff2c1900e7bfc5e7844025 tzcode2017a.tar.gz fe57930711998a0755749a2bf1b32fdbc9e6ee249762017beea52eae7e521236396300fe2d79298fd81eb6d73fb7567884c35995ed248be06188329d937e3873 tzdata2017a.tar.gz 9004e74718455e8199f4dc301a7e3f74dfa37b5ed9de4a41f2cd88a97e759f8f2aea7bb92c0c022515eab88a2169f08606c47c621479374f884130a34bfc188c tzdb-2017a.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYtTBSAAoJEO2X6Q5iqn40sWUQAJ8XTHkp/BXYPfwQf3SXJkog e2jXeW4U5CtmBvo5SmENeWVd69piEBsbgVYmzfIIQy9kXt/jJcHIuBAIUVF6UqSx 4MOeogfrM0+cqXNWZMza26aHivOf8ypqnyekVtrHf0z3oC7EhwPcfZWIeVqgS0Oc 5PAja8V/jewcq1vaIk8lp7cJ2eUGJRNQSco4Vd0jsoltrb52Vn7WJ/sf/EYS+gTs B/iEiSN+SFHhnkNLUlm5xoJib0+wBrZzEqowoPel54h0XT9pA+sUdbeW+w6VeQPz JiJbFQwKvZIdADcPseGyYaexEiSHuUokwGOGsoB14kEUwlIjvSgUq7l2CuIvmLFA fH7edetBYmedN9sbO1Sa2dJAiL4W0kbERW9EtKZ1G5ixOEVz/dtTEMznj2JTi3bl yTs1rSBMeZogjo0nySZeK4KpoL5VOxdze05g+DQ/jbeksCOwPPTtHtNf9tK1fwgy GyBt5R0U6j/Hjm0mQgiK4enmVxa55HVCCXnbyo/A08u0x7U5g16ebiSax/q5bW5I IAgYRBYzanccBVjIg0bW0pQXzJ5fmPnHo20dxkRlIqTAkoVTF62fOio5LCN4XQRK dt57WuvEHj4MIwj/12dipcCY1qFlqxOx3BegEQNvVd67z0Z4cBVW/Ng2RmjSGtEl 0DBAIPPrMvZ5pwWJZiJF =EVYD -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYtTBSAAoJEO2X6Q5iqn40qlgP/i6xLqi7ojaiKm9x7ZmYDVxh ggMmRyR8YDE8/eSSZB03fayVCIdVNj96J2t9beJXnyRISZbhOj3vPrlSziCBNR29 QjX6Sbh3N7y2QlWvgdExqqKCM69zV3Q9Zz51cFz4kiACue0dvmPYWPjUqvV1m42W BiqL9oVwhvbnp14kJVcLOQINrlhWOTY4/MDfBQAVMPpvntJSpitOnC4y30xLsie2 1MR6/oHVuEhmrfk8ePhgwVm64lg6o8sVl26kO/baNeqo0ST/LAP2CJqhM+54YB+c 0IK7kXk4Te97Hq0/0G7ZHugySjVIQGvrcI7bIcam9pXVRCveRJvdGH5OZpY1MD09 RF66Y4n9E1iD4MlQEgaizjAIjy8JrwJUc0W9m/GHSJecwYZXKbZYkqQpgQGfpA4/ fz3+BUr0AaUh/JGtdyXTm9v/JEwvJsJvu77wtSNLyA4+XR3cZOfhgJ5syw7tDCXy tBHIl74845Ky/FrheXp7vfOUayEn623r7RyLEOt65v7Qn2AwDwc+u73qpVW/e25r bD7mWDLXOyFgERhTLZafRahMxugFTl1mFikygI12TvDPvsgcBwAEDUDdu8e3MU1+ HdoBu6aGIMP8OLqN3cqrJlUF/dqn/JeeGnUAVQZlXHb7oWu7mf7OOrIzjQC5xG8y KDL+94hpsq/thK712LfA =+3fY -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJYtTBSAAoJEO2X6Q5iqn40xF0P/33nPe1C0P4EGhqzkXce/Bee iKYHWfeYXzXdRoQrjLGWuzUP2hJhZVq0Sw6ylYXwHwf0lVs2PfkFnkDfeV+5z7Fw cABcJO35B9GeSxXFhYvznvK2Azes0YYQ1ltBcNxaLeDTyi/a+vVexvzxrkbh+Vx7 wDf5ZS0Xn7Jtq+fTG1K7WVSzETw39Bw29E2K/ITWSEg83WJ8Db3IuhlC6hmu6lyF C6cMY+6qY7XylvOLqZkF2b1+l6d+TNI+5s+wNchq/tZQzShGKsjCPAx4xj7ebUtt JJAJzWuw6OHkXsor2dKpcRuqhrTQx6Oybfj85WA3+kNWaTTdDa2oxWOXGDzK5ySU hFxJFD1Q1U5nUkxMBdEKsuG2P3JPLEH0sVJX9TwMnyAlZM3mI9sJMGnP9ssOearG 0mF+kL7fQB3Y2+y67i9cFNJRNchK6O4/FiBe+PdNYXwSrlPqt+9VlEdqq6B3jkJe /gBJCi1lMpk9tVAntxtMWCvYr9pZn6eQnyBGW8urdUMdNcsr1w1SxGf1bPT5zpKM zhPfHlVJxS0lP6aTwxEMUKhM5WXZcw10kR3oabLZOmQUGuZPG7JUWL1T7hie6FAf Wso1rz/Pw08dMvLsU8R0lSj5IQFCioOm0NP/seo/dG032CY2AGh32PpPfegziiA5 N0j4ihRNDSRAKySyK1WY =TwWB -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

ISO 3166 (GB): United Kingdom
by Andreas Stieger Feb. 28, 2017

Feb. 28, 2017

Hello, the attached corrects the ISO 3166 short name from "Britain (UK)" to "United Kingdom". Andreas -- Andreas Stieger <astieger(a)suse.com> Project Manager Security SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

5 4