November 2016 - tz - lists.iana.org

tzdata2016g missing version information
by Howard Hinnant Nov. 12, 2016

Nov. 12, 2016

As is known, the version number no longer appears in the Makefile. The release notes in NEWS say: > To support the more-accurate version number, its > specification has moved from a line in the Makefile to a new > source file 'version’. The version file does not appear in the uncompressed tzdata2016g database. This is hurting my ability to report the version of the database to my clients. Can we please put a version file in the database? Howard

18 49

"impossible" glitch right at the DST changeover: it had to happen
by scs＠eskimo.com Nov. 11, 2016

Nov. 11, 2016

The mother in this story says she had a hard time "wrapping her head around it", but readers of this list will have little trouble: "Twins' Daylight Saving Time Birth Results in Bizarre Age Twist" http://abcnews.go.com/Lifestyle/twins-daylight-saving-time-birth-results-bi… Yes, one twin was born on the early morning of November 6 at 1:39, and his little brother was born 31 minutes later, at 1:10.

1 0

[PROPOSED] * CONTRIBUTING: Call the GitHub repository "development"
by Paul Eggert Nov. 11, 2016

Nov. 11, 2016

Instead of the old adjective "experimental". --- CONTRIBUTING | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING b/CONTRIBUTING index e40102e..22addd2 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -18,10 +18,10 @@ data should contain commentary citing reliable sources as justification. Please submit changes against either the latest release in -<ftp://ftp.iana.org/tz/> or the master branch of the experimental -Git repository. If you use Git the following workflow may be helpful: +<ftp://ftp.iana.org/tz/> or the master branch of the development +repository. If you use Git the following workflow may be helpful: - * Copy the experimental repository. + * Copy the development repository. git clone https://github.com/eggert/tz.git cd tz -- 2.7.4

1 0

Re: [tz] tzdata2016g missing version information
by Dempsey, Peter Nov. 10, 2016

Nov. 10, 2016

Hi, On 09/29/2016 08:590 AM, Eggert, Paul wrote: >Yes, it appears that the Oracle software assumed that the Makefile would have a VERSION line that specifies the version number. That assumption was never documented or guaranteed and is no longer valid. >Perhaps you can work around the problem by modifying the Makefile to say "VERSION = 2016g" (I don't have the Oracle software and so can't easily test this). >We are discussing a better way to address this problem in the future. @Paul Eggert: The Oracle Timezone Update Tool can be downloaded from here: http://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readm…. This tool has two ways of updating the timezone database: 1. Online where the timezone database is downloaded from: -l http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz 2. Offline where the timezone database is loaded locally: -l file:///tmp/tzdata2016g.tar.gz The tzdata file published on the IANA site needs to include the VERSION information so that this tool can work. When do you think this can be provided? I need to test the Oracle Timezone Updater Tool as soon as possible because I have customers with critical systems dependent on the time zone database. @Susan Abraham: I don't know if you are involved with the Timezone Updater Tool but this tool currently can't update the timezone because the database doesn't contain the VERSION information. @Kim Davies: I am adding you to keep you directly in the loop. Best regards, Pete -- This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.

7 15

Danish Time not UTC
by Brian Inglis Nov. 10, 2016

Nov. 10, 2016

According to the DK NMI DANIAmet: https://daniamet.dk/en/nmi/time-and-frequency/ "The law on time (Law No 83, 29/03/1893) prescribe that the time in Denmark is determined by mean solar time and not the UTC time." -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

6 10

Failed to update tzdata2016g and higer with tzupdater
by Sawadee.Prakayphetchara＠thomsonreuters.com Nov. 9, 2016

Nov. 9, 2016

Hi, We found an issue when try to update timezone with the tzdata2016g.tar.gz - tzdata2016i.tar.gz The problem is that VERSION in the Makefile is not correct, the correct value should match with tz version i.e. 2016i not unknown. # Version number for the distribution, overridden in the 'tarballs' rule below. VERSION= unknown The workaround has been mention in, http://stackoverflow.com/questions/39832866/tzupdater-failing-with-tzdata20… * Update Makefile of http://www.iana.org/time-zones/repository/releases/tzdata2016g.tar.gz: Original value of VERSION variable is unknown and you need to update it to 2016g. * Regenerate tzdata2016g.tar.gz.sha512 file So far we need to apply the workaround on each release. It would be great if you can correct the version in next release? Regards, Sawadee M.

2 1

Timezones - what's so hard?
by Michael Douglass Nov. 7, 2016

Nov. 7, 2016

http://www.gocomics.com/pearlsbeforeswine#mutable_1511244

3 2

[PROPOSED] Port ar usage to POSIX
by Paul Eggert Nov. 7, 2016

Nov. 7, 2016

* Makefile (libtz.a): Use 'ar -rc' instead of 'ar ru', as 'ar -rc' is standardized by POSIX and GNU 'ar' 2.26.1 (Ubuntu 16.04.1) warns about the obsolete form 'ar ru'. --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 74b950c..1b714a8 100644 --- a/Makefile +++ b/Makefile @@ -542,7 +542,8 @@ force_tzs: $(TZS_NEW) cp $(TZS_NEW) $(TZS) libtz.a: $(LIBOBJS) - $(AR) ru $@ $(LIBOBJS) + rm -f $@ + $(AR) -rc $@ $(LIBOBJS) $(RANLIB) $@ date: $(DATEOBJS) -- 2.7.4

1 0

Compiler warning in tzcode2016g about SIZE_MAX being wider than int
by Tom Lane Nov. 6, 2016

Nov. 6, 2016

When trying to build 2016g using macOS's current compiler (or, probably, any reasonably late-model version of clang), I get cc -DTZDIR=\"/usr/local/etc/zoneinfo\" -c -o zic.o zic.c zic.c:434:51: warning: implicit conversion from 'unsigned long long' to 'int' changes value from 18446744073709551615 to -1 [-Wconstant-conversion] int amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX; ~~~~ ^~~~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/stdint.h:153:20: note: expanded from macro 'SIZE_MAX' #define SIZE_MAX UINT64_MAX ^~~~~~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/stdint.h:87:27: note: expanded from macro 'UINT64_MAX' #define UINT64_MAX 18446744073709551615ULL ^~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. Or in other words, clang is pointing out, quite correctly, that SIZE_MAX won't fit in an int. This doesn't represent a runtime bug because the condition "nitems_max < SIZE_MAX" can never fail, but that just begs the question why have it. I am not aware of any C implementation that has ever had INT_MAX > SIZE_MAX, and surely there are none in use today. I suggest, therefore, a fix along the lines of $ diff -u zic.c~ zic.c --- zic.c~ 2016-09-06 00:39:50.000000000 -0400 +++ zic.c 2016-10-20 13:06:39.000000000 -0400 @@ -431,8 +431,7 @@ return ptr; else { int nitems_max = INT_MAX - WORK_AROUND_QTBUG_53071; - int amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX; - if ((amax - 1) / 3 * 2 < *nitems_alloc) + if ((nitems_max - 1) / 3 * 2 < *nitems_alloc) memory_exhausted(_("int overflow")); *nitems_alloc = *nitems_alloc + (*nitems_alloc >> 1) + 1; return erealloc(ptr, size_product(*nitems_alloc, itemsize)); Alternatively one might think of changing the types of nitems_max and amax to size_t --- but that would just make it even more crystal clear that the "nitems_max < SIZE_MAX" conditional is useless. And if, somewhere, one did find a C implementation in which size_t is narrower than int, that coding wouldn't work at all. Basically I don't see a way of dealing with this that is superior to just assuming that INT_MAX is less than or equal to SIZE_MAX. regards, tom lane

4 8

Daylight saving in Trkey problem
by Caner Aydinbey Nov. 6, 2016

Nov. 6, 2016

Hello. We have linux machine and we have app in there. FOr date command, it shows true date but in spring boot application, we cant get true date. It iss 1 hour later. So we follow guides to update but we cant manage. for example here http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html#… Please suggest us something to do. -- Caner Aydin Software Developer Infoowl Software Solutions & Consultancy +90 542 788 62 64 <%2B90%20530%20960%2035%2053> www.infoowl.net

3 4