- tz - lists.iana.org

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

broken compression in archive
by Zefram Jan. 18, 2018

Jan. 18, 2018

I'm doing some work on how to access historical tzdb versions, and I noticed that tz{code,data}94d.tar.Z are, despite their names, uncompressed tar files. To be precise, I refer to the files with these SHA-512 hashes: 9872b757ee3a8bf0ed3de1f0875f878b977b34bd2b60440b23a8c7308a7514d12a5d5d283387973e61b75e1a8eebd27009aab78eee4e12f1f1a5593f71941328 tzcode94d.tar.Z e1524951a5c261cc8eef1f3adadf5ebf8143293745fda9411a0090d6bb6e19f899dd7a6e55fe2f8f490a167a3da392020e49b369984bc1f5cbed87d664eb58de tzdata94d.tar.Z They're unique, in the present archive <ftp://ftp.iana.org/tz/releases/>, in having a mismatch between format and filename suffix. I think these files should be replaced, in the archive, with actual compressed (with compress(1)) versions of these tars, under the same name, so that the names are no longer misleading and they are in the same format as the surrounding files. The other way to make the names no longer misleading is to rename these files, dropping the ".Z" suffix, but this approach has the problem that these files would (still) have a different format from all the other tarballs. Note that this mismatch is not a mistake made in the original release of 94d, and the replacement that I'm proposing would not erase a record of the original release files. The original 94d release was of *gzipped* tar files, which are not in the present archive. Actual releases switched from .Z to .gz at 93g, but the archive files switch at tzdata95c and tzcode95d. Obviously someone recompressed the intervening tarballs somewhere along the chain of custody that led to the present archive, and it appears that the failure to (re)compress 94d happened in that process. -zefram

4 6