- tz - lists.iana.org

[tz-announce] 2018c release of tz code and data available
by Paul Eggert Jan. 23, 2018

Jan. 23, 2018

The 2018c release of the tz code and data is available. It follows on the 2018a and 2018b releases, which were published but were not announced until now, due to problems discovered late in their release processes. 2018a had a build-failure typo, and 2018a and 2018b both had problems with ICU and Java, downstream packages which do not support a feature (negative DST offsets) used in 2018a and 2018b. The typo has been fixed, and data changes using negative DST offsets have been reverted pending development of a mechanism to export data to platforms lacking support for such data. The 2018a through 2018c releases reflect the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes. This announcement has merged the set of changes made by the three releases, to make it easier to see the difference between 2017c and 2018c; please see the 2018c NEWS file for more details about intermediate versions. Release 2018c - 2018-01-22 23:00:44 -0800 Release 2018b - 2018-01-17 23:24:48 -0800 Release 2018a - 2018-01-12 22:29:21 -0800 Briefly: São Tomé and Príncipe switched from +00 to +01. Brazil's DST will now start on November's first Sunday. Use Debian-style installation locations, instead of 4.3BSD-style. New zic option -t. Changes to past and future time stamps São Tomé and Príncipe switched from +00 to +01 on 2018-01-01 at 01:00. (Thanks to Steffen Thorsen and Michael Deckers.) Changes to future time stamps Starting in 2018 southern Brazil will begin DST on November's first Sunday instead of October's third Sunday. (Thanks to Steffen Thorsen.) Changes to past time stamps Japanese DST transitions (1948-1951) were Sundays at 00:00, not Saturdays or Sundays at 02:00. (Thanks to Takayuki Nikai.) A discrepancy of 4 s in timestamps before 1931 in South Sudan has been corrected. The 'backzone' and 'zone.tab' files did not agree with the 'africa' and 'zone1970.tab' files. (Problem reported by Michael Deckers.) The abbreviation invented for Bolivia Summer Time (1931-2) is now BST instead of BOST, to be more consistent with the convention used for Latvian Summer Time (1918-9) and for British Summer Time. Changes to build procedure The default installation locations have been changed to mostly match Debian circa 2017, instead of being designed as an add-on to 4.3BSD circa 1986. This affects the Makefile macros TOPDIR, TZDIR, MANDIR, and LIBDIR. New Makefile macros TZDEFAULT, USRDIR, USRSHAREDIR, BINDIR, ZDUMPDIR, and ZICDIR let installers tailor locations more precisely. (This responds to suggestions from Brian Inglis and from Steve Summit.) The default installation procedure no longer creates the backward-compatibility link US/Pacific-New, which causes confusion during user setup (e.g., see Debian bug 815200). Use 'make BACKWARD="backward pacificnew"' to create the link anyway, for now. Eventually we plan to remove the link entirely. tzdata.zi now contains a version-number comment. (Suggested by Tom Lane.) The Makefile now quotes values like BACKWARD more carefully when passing them to the shell. (Problem reported by Zefram.) Builders no longer need to specify -DHAVE_SNPRINTF on platforms that have snprintf and use pre-C99 compilers. (Problem reported by Jon Skeet.) The build procedure now works around mawk 1.3.3's lack of support for character class expressions. (Problem reported by Ohyama.) Changes to code zic has a new option -t FILE that specifies the location of the file that determines local time when TZ is unset. The default for this location can be configured via the new TZDEFAULT makefile macro, which defaults to /etc/localtime. Diagnostics and commentary now distinguish UT from UTC more carefully; see theory.html for more information about UT vs UTC. zic has been ported to GCC 8's -Wstringop-truncation option. (Problem reported by Martin Sebor.) Changes to documentation and commentary The zic man page now documents the longstanding behavior that times and years can be out of the usual range, with negative times counting backwards from midnight and with year 0 preceding year 1. (Problem reported by Michael Deckers.) The theory.html file now mentions the POSIX limit of six chars per abbreviation, and lists alphabetic abbreviations used. The files tz-art.htm and tz-link.htm have been renamed to tz-art.html and tz-link.html, respectively, for consistency with other file names and to simplify web server configuration. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2018c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2018c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2018c.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 fromftp://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 ef4db72f1cbe1f7141f8aa012a624abb0a8d8059 dated 2018-01-22 23:00:44 -0800 and tagged '2018c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 21988e876479e38661d41ea4c7b5218ba14b979739d7ba8d49a2d343bb9f37c654056ab21c046a6652715f012e4ca33c4aa109b1ec3ac5d0244dd3a7ea9ed6d2 tzcode2018c.tar.gz 0575c87c9ffcde7b7f62b0df928d8a0e8d93f832b5ef7227b3d8431686f851f1fd5372c7e768f2979830352433b31df7f3979a00c28ea3973a3a0987ebbfb835 tzdata2018c.tar.gz a1686902f81b4aceba494797e4eb8cdb8c1037ab7a27df9635b7a45ecfd90b8cf7b605a252ad1a8c67394a578f95aa9dff03071bc871120a98328de437c19b4f tzdb-2018c.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJaZuAMAAoJEO2X6Q5iqn40NNsP/i+4WUmbLMMZnnR9FTvRUILo UAHYZRqC1KbdMppKeeyTL6thANvjpMjeYM8V54tzndzrMhBaPc8SpiwVgTevRtKZ wG9BSb8Hx/RDQeBWOjRwFx5/WQ+ha4aK0IFB8KB5gNFLOuyMn+9ZaxSzoEXmNWX0 Ddoizk516lpfGuhZCnPMVtDorebaAby0d3WMCxzEJ2w3gLOI4Aj8WVR2Cl5eTlA/ cpQ+bzLog5lnf+mzs/bJeMlfxPSskAlvIBYk905uPTAT/LDeod+T+BLBfcGEUb5J D64veBERj01NDwVLDRqHG0hdw8aPdMQyTLje6fI7sVh2cu4lGgA7QxHC+aTnmYjt 862/wX7dx2HtfuaIr+6eulAIR3+rix0CMndEXUGLtqnx4WySh5rT++V4crGcgzSH eRl2TOkBBxpYLIK6KtHd31V5WhJfTN2NQOZEFdrxy+Z2pPWZJrhcB9+0tYGoRVs0 ARQdm5I1w5JwiHO7sI0YHWCPZCVhDC2+/Izg668OUIdmFpqXanMAADkT5Qo9frlu 72cnL0MFMB4JCQwbqE1Xa1AOzz6bUG7zUfRDyAH6wZyHIxZgr5PmbbfUfoagOD0J /psdEJNsOUdg+wDou23UVRyt9/WIiZbXKWVTs14DMuqrHLUQAcFQtpYwb/U3z5mR 0I0syyatHweHMeftotgJ =gt0T -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJaZuAMAAoJEO2X6Q5iqn40WkcP/3/QD5VP4YT5/zLPqTE4hLMB iuNFJelf1Iv4hFXYCMhfnU+0MlUfvSBBKLI5uu1vTl48ms33Ku+CL6fKI8uIlwMG v0yTCOxRozMofUcjsm2IfGRlJgAajMPWDOGsD3jocX0Vf14m9siycy4xdBk7vNrs QUKL3zl0XOBQY51ivnYvEK/f8LJZzn7NHizL0VwI0rxO/Oj6o0Q2wWkE61tBS27r znn9lFRWH1Nh+TJ7Yh1mNAd4UOYGL9Q3eoWkl5MzPM3ujjVSdsEXhNLGemPrfE50 RzuvsLgiKqahBpC9Zxy39pqiO+riRKHLlNjxNcCeHw6M5w8/FuBwwozSmdchWaZn gD50k7az4F5nojUgzYTNGV6nW2CGflLLgOeUWMmYUyF999KpOJzLXNFqMuBYqOOu ODI7CJweT0/Ff9jjoKMSqg1rMMDEox/E127ms8uf6qGyjWvp0AQlA5O06bStfpjH HDJog9BcDXb64oiJsIg0K4UqqF1n7jMqiufhz4WhrqPqaTP9qJuorSn5yar/UsGc V2l2C+BdJhmsvQ9vkLrYJNWXks+oQSFJ1dYYpv+zp/MsiBV1/pKaYEXgurRfQBCW eHO57ovm2Pf59dghTnm7SyoiZeqCK/89MWxpX4YbDgzP4ZyBhS2g1/bk7toPajUa idAZsIgmZDmw77UHpPJu =nVJg -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJaZuAMAAoJEO2X6Q5iqn40rDcP/3cxJ0Ri2s3WNCnu1woSJ3KU zRc5lvC4YZRo8/4yqEjzcq8M2eiYs540WqE4kPm9dFSefCOWX6nw5imrU2cM9EfJ XPyrZho+r85uH5KMCgQ9J+AC1HBya4TPdaTPikEYVARBMmkwLtM34FxJz2VnFRhT ZQjDG+ncZNhOBXWu6Mughb6I38Cl19/Dn2iQJ9p0XTay6uytCMceZ+o52bugeWCL HlRkGqZgW9cxFygq3EBEGWN/IcsdFSZqpHLVslD5xeZP294tCW0LsgE/SZ0YP1c3 Dd0KWeC4iYbrETda57XA9+27siXwhT9hVQnXVeykmsmn+TftZHh89A+bVYlglhIi QXRH2pi9OX/8DgsTox3mswAM2OPFiUgdOthwVdnrdHjhWc74SFr7AARSmoIVZHve gKIQXCuTV+mcVKZ6ibHZHs86QQ/jevcLivlQdOO9MMHVNMu5ZjBR6E3QjY5TTwcW 2UT/JEMMluYA+b5xVrGOwWa2g2vU/K1nvOVX73vT3n552djrZ6NholegrVVbcVjO GySPxMwjm1MMlmvXnN0cr4eWzFamVdMMSBkn8X/aBjbHAIvnqiqoxK/9JQf0wEZV lgGETcAvxr540LUuY0R95SO3qy4MXrT5USMDUSnif8BsNoLe5MEExAmVJ3A7W1sP 3/xQouSXzl63eYI3Rvam =WEKZ -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Reason for removal of several TZ
by Thomas M Steenholdt Jan. 23, 2018

Jan. 23, 2018

Hi guys, Almost a year ago, commit 2999bb5bee719acbba8b9dd50fb9fb00c7788623 removed several TZ abbreviations and I'm trying to understand this. For my own use, what I'm after is WGT/WGST which are now "simply -03". WGT/WGST has been in tzdata for a long time, so the removal causes certain things to go belly up. The change was only implemented in Ubuntu recently, which is why this only turned into a problem for me now. WGT/WGST seems to be a widely accepted abbreviation for the West Greenland Time zone. So can someone explain to me the reason behind the removal and what would needed to get it re-implemented? Thanks. /Thomas

40 174

Irish Standard Time vs Irish Summer Time
by Neil Fuller Jan. 22, 2018

Jan. 22, 2018

Just to weigh in from an Android OS perspective: the Europe/Dublin DST convention change is also problematic for the Android platform. Most of what I would want to say has been said. Like many, I missed the discussion in December about this change and I'm not sure I would have grasped the full impact if I had. I monitor the announcements list so it would have been most useful to me if this change had been flagged ahead of time there. I started looking at 2018a when I saw discussion internally to Google and I was surprised I hadn't seen an official announcement. It might help to understand the impact of this change and the indirect influence and interactions that the tzdata has in Android so I've included some information below on my ongoing assessment as an FYI. The NITZ standard[1] is probably the worst interaction I've seen so far. In the meantime Android will probably have to take the same approach that ICU has and patch the IANA data, or wait for 2018c to hopefully reverse the convention back to what it was before. As always, thanks to all of you for keeping the world turning! Neil. ------------- The latest Android code is downstream from both OpenJDK and ICU, with some of it's own time zone code on the side. There is a custom implementation of classes like java.util.TimeZone, but also code for time zone detection used in smartphone devices. Android will be exposed to any problems that the ICU/OpenJDK maintainers mentioned, plus any in other OS libraries used that I haven't looked at yet. Android uses tzdata in some places for transition calculations, but refers to ICU for things like names. There may be other interactions. If the tzdata had one interpretation, and ICU had another, Android's formatting code might return (for example) Irish Standard Time in Winter. I found a long-standing bug in the Android java.util.TimeZone code that forces the DST adjustment to always be >= 0 and another elsewhere that (obviously incorrectly) assumes DST always means +1 hour. The time zone detection code on Android can use the time zone offset data it has available on device and compare it against information sent by the carrier via NITZ[1] to see if it can identify the user's time zone. The NITZ documentation says: "When the LTZ is compensated for DST (summertime), the serving PLMN shall provide a DST parameter to indicate this. The adjustment for DST can be +1h or +2h." I'm looking into whether carriers / networks in Ireland have made the same interpretation as the new IANA data. I suspect their hands are tied by the NITZ standard which would probably prevent them passing a negative number. There's probably a feedback loop here between the NITZ standard, what carriers will send and what devices can accept that might take a while to stabilize on any new convention, if it happens at all. >From a support perspective, Android has three cohorts to deal with: 1) Devices running older versions of Android for which OEMs are still providing over-the-air (OTA) system image updates. These can potentially take code patches to correct issues. 2) Devices running older versions of Android that have the ability to receive time zone rules data updates but not code. 3) Latest code under development for future Android releases. If the Europe/Dublin change "sticks" in tzdata, the likely course for supporting existing devices would be to patch the Android tzdata and pretend the Europe/Dublin shift hasn't happened. Future devices could potentially support negative DST adjustments if all the problems are caught in advance. [1] https://en.wikipedia.org/wiki/NITZ , see reference 1 for the standard I quoted -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902

4 4

Changing times
by Arthur David Olson Jan. 22, 2018

Jan. 22, 2018

In days of old, there was only one consumer of the time zone data files: the time zone compiler that's part of the IANA package. Today there are multiple consumers. My sense: that multiplication predominates over any change in maintenance approach as a complicating factor. @dashdashado

1 0

The Japanese time zone rule is wrong.
by 二階隆幸 Jan. 22, 2018

Jan. 22, 2018

Hello, I'm Takayuki Nikai. I will report mistakes in Japanese time zone rules. Under Japanese law the daylight savings time boundary is written as 0:00, but tzdata is defined as 2:00. Also, the end of daylight saving time is Sunday, not Saturday. The source of information is Japanese law. http://www.shugiin.go.jp/internet/itdb_housei.nsf/html/houritsu/00219480428… http://www.shugiin.go.jp/internet/itdb_housei.nsf/html/houritsu/00719500331… > 四月の第一土曜日の午後十二時から九月の第二土曜日の翌日の午前零時までの間 > 第一条及び第二条第一項中「四月」を「五月」に改める。 In summary, it is written as follows. From 24:00 on the first Saturday in May, Until 0:00 on the day after the second Saturday in September. However, in Time Zone Database (2018a (Released 2018-01-12) which is currently distributed, it is starting from 2:00 as follows and it is wrong. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER / S Rule Japan 1948 only - May Sun>=1 2:00 1:00 D Rule Japan 1948 1951 - Sep Sat>=8 2:00 0 S Rule Japan 1949 only - Apr Sun>=1 2:00 1:00 D Rule Japan 1950 1951 - May Sun>=1 2:00 1:00 D I think that it will be correct as follows. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER / S Rule Japan 1948 only - May Sun>=1 0:00 1:00 D Rule Japan 1948 1951 - Sep Sun>=8 0:00 0 S Rule Japan 1949 only - Apr Sun>=1 0:00 1:00 D Rule Japan 1950 1951 - May Sun>=1 0:00 1:00 D An error will occur in past date time analysis. Please consider modification. -- +--------------------------------------------------------+ HealthCare Relations Co., Ltd. 二階隆幸 Nikai Takayuki 〒101-0054 東京都千代田区神田錦町3-13−7 名古路ビル本館1F TEL 042-485-7130 +--------------------------------------------------------+

2 2

tzdb-2018b does not work after make clean
by 大山俊成 Jan. 22, 2018

Jan. 22, 2018

Hello, I'm Ohyama. I downloaded tzdb-2018b.tar.lz and did as followings make TOPDIR=$HOME/tzdir install $HOME/tzdir/usr/bin/zdump -v America/Los_Angeles it works good ! But once I do clean by make clean And again make TOPDIR=$HOME/tzdir install $HOME/tzdir/usr/bin/zdump -v America/Los_Angeles it does not works.(error message "America/Los_Angeles: No such file or directory") Something wrong with me?

2 4

cppcheck in-efficiencies
by Khamit Ardashev Jan. 21, 2018

Jan. 21, 2018

I use cppcheck to scan my code, and it found these in-efficiencies, Could somebody fix them ? date/tz.cpp:755: performance: Variable 'u' is assigned in constructor body. Consider performing initialization in initialization list. date/date.h:7218: performance: Function parameter 'format' should be passed by reference. date/tz.cpp:220: performance: Function parameter 'path' should be passed by reference. date/tz.cpp:2417: performance: Function parameter 'format' should be passed by reference. Khamit Ardashev Flextrade Systems

2 1

The Y2038 problem is 20 years away
by Tim Parenti Jan. 19, 2018

Jan. 19, 2018

It is now 03:14 UTC on 19 January 2018. Twenty years from now, POSIX and POSIX-based timestamps, which have more-or-less been counting seconds since 1970, will reach 2^31 and thus overflow signed 32-bit integers. Since all sorts of forward-looking date arithmetic abounds, it is inevitable that there are still active applications that will mishandle this. Twenty years out is an interesting point when more of those seams might start to show, and left unpatched, that would only increase as we approach 2038. It's much like Y2K, but in binary… and with seconds. So keep your eyes peeled in the near future for anything suddenly thinking it'll somehow be December 1901 in the slightly-more-distant future. You have some insight into just why that'll be happening. -- Tim Parenti

6 7

Re: [tz] Irish Standard Time vs Irish Summer Time
by Patsy Franklin Jan. 19, 2018

Jan. 19, 2018

Hi, Will a resolution/patch be available for this soon? Thanks, Patsy

1 0

video about Samoa's 2011 timezone switch
by Zefram Jan. 19, 2018

Jan. 19, 2018

An entertaining video about timezones, with particular reference to Samoa's 2011 move across the International Date Line: https://www.youtube.com/watch?v=rARMsjh4Zu0 -zefram

1 0