January 2018 - tz - lists.iana.org

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

Fwd: Issue with tzdata2018a.tar.gz Europe/Dublin Rule
by Vicky Jan. 18, 2018

Jan. 18, 2018

Hi, while parsing the data i found the issue in rule Europe/Dublin Negative DST.. Previous version or not in any other file there is no negative dst. DST either start and end . # The following is like GB-Eire and EU, except with standard time in # summer and negative daylight saving time in winter. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 GMT Rule Eire 1981 max - Mar lastSun 1:00u 0 IST Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 GMT Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 GMT Rule Eire 1996 max - Oct lastSun 1:00u -1:00 GMT Please explain why -ve dst offset compared with other files. Regards, Vaibhav

1 0

Re: [tz] Build error on tzdb-2018a
by Paul Eggert Jan. 17, 2018

Jan. 17, 2018

Matias Fonzo wrote: > I can't update tzdb-2018a, I am getting this error: > > make: *** No rule to make target 'pacificnew', needed by 'version'. Thanks for reporting this packaging problem, which was not detected by the checks that I do before making a distribution. I have installed the attached patch to the development version; please give it a try. Because this problem was caught before I announced 2018a, I will hold off on making an announcement. Instead, I plan to wait a day or so for review of this patch, and then release 2018b with this patch.

2 3

tzdata2018a released
by Seán Coffey Jan. 17, 2018

Jan. 17, 2018

It looks like 2018a has been released with a typo on the release date stamp : (Released 2010-01-12) [1] No announcement was sent to the announcement mailing list. Can the administration of such releases be made more transparent please ? The same type of admin issue happened during 2017. regards, Sean. [1] https://www.iana.org/time-zones

2 1