- tz - lists.iana.org

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

Missing pacificnew data file
by Kerry Shetline Jan. 17, 2018

Jan. 17, 2018

Hi, I just downloaded the 2018a distribution of the tz database, with code. I tried to do a “make” and the make failed due to the missing pacificnew file. Copying that file from 2017c fixed the problem. The Java tool tzupdater also fails because of this missing file. I realize it might be that you are deliberately getting rid of this file, but your own make process is broken with the file missing, and I imagine other tools for updating time zone data besides tzupdater will also fail due to this file being gone. If you accidentally left pacificnew out, you might need to re-release the distribution. If getting rid of it was intentional, you’ll have to update your make process, or perhaps include a blank or commented-out copy of pacificnew. I also didn’t notice any changes in Brazil or Ireland as I expected to see from the release notes, which possibly is another problem. -Kerry

2 1