- tz - lists.iana.org

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

Brazil moves DST start to November
by Steffen Thorsen Jan. 17, 2018

Jan. 17, 2018

According to many media sources, next year's DST start in Brazil will move to the first Sunday of November, and it will stay like that for the years after. Some examples in Portugese: https://noticias.r7.com/economia/por-eleicao-temer-reduz-periodo-de-horario… https://exame.abril.com.br/brasil/por-eleicao-temer-reduz-periodo-de-horari… We have made a brief English summary: https://www.timeanddate.com/news/time/brazil-delays-dst-2018.html Best regards, Steffen Thorsen - timeanddate.com

4 7

Canada/East-Saskatchewan
by Derick Rethans Jan. 16, 2018

Jan. 16, 2018

Hi, I saw that the PHP build with the new timezone database (2017.3) failed due to Canada/East-Saskatchewan suddenly being gone. What's up with that? https://travis-ci.org/php/php-src/jobs/291636544#L1280 cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug

6 9

leap-seconds.list file is out of date
by R. Bonomi Jan. 15, 2018

Jan. 15, 2018

The iana.org file only contains info through Bulletin C54, but Bulletin C55 is out. Reference: the leap-seconds.list file at usno.mil

3 2

Mongolian time zone.
by Phake Nick Jan. 13, 2018

Jan. 13, 2018

Currently, tz database say Mongolia use UTC+7/8/9 as timezone. However, after quick google search, I found a question about time of Mongolia in a Mongolia question and answer time at [1]. The page itself is facing technical problem to me so I accessed it via Google cache which I subsequently thrown the cache into Google translate and archived the result at [2]. According to the page from 2016, three different users of the site answered the question with same answer, and all of them are saying Mongolia have three different timezone: 6, 7, 8. This is different from the information recorded in tz database. So, is the information in tz database incorrect? And then, another question on the site [3] (archived in [4]) asked about when did Mongolia start officially using the world time and someone answered since 1997. What does that mean? (On the other hand, another answer to a similar question say 1961... [5][6] or is that an error in machine translation?) [1]: http://acyy.mn/3379/монгол-улс-хэд-хэддүгээр-цагын-бүсэд-оршдог-вэ [2]: http://archive.is/y3jpH [3]: http://acyy.mn/8620/монгол-хэдэн-оноос-дэлхийн-бүсийн-цагийг-хэрэглэж-эхлэс… [4]: http://archive.is/PQBVk [5]: http://acyy.mn/7379/му-хэдэн-оноос-дэлхийн-цагийг-баримтлах-болсон-бэ [6]: http://archive.is/e39nW

2 1

Sao Tome Principe change of time zone
by Steffen Thorsen Jan. 9, 2018

Jan. 9, 2018

Multiple sources tell that Sao Tome changed from UTC to UTC+1 as they entered the year 2018: https://www.dn.pt/lusa/interior/relogios-avancam-uma-hora-em-sao-tome-e-pri… http://pt.rfi.fr/sao-tome-e-principe/20180101-sao-tome-e-principe-muda-de-h… http://www.stp-press.st/2017/12/23/sao-tome-e-principe-vai-mudar-hora-a-par… So it seems the Africa/Sao_Tome zone needs to activated again! Our English summary: https://www.timeanddate.com/news/time/sao-tome-principe-time-zone-change.ht… Best regards, Steffen Thorsen - timeanddate.com

3 3

[PATCH] * northamerica: Add note re Chicago time before 1883.
by Paul Eggert Jan. 8, 2018

Jan. 8, 2018

--- northamerica | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/northamerica b/northamerica index 505300a..a014126 100644 --- a/northamerica +++ b/northamerica @@ -348,6 +348,18 @@ Zone America/New_York -4:56:02 - LMT 1883 Nov 18 12:03:58 # Nebraska, eastern North Dakota, Oklahoma, eastern South Dakota, # western Tennessee, most of Texas, Wisconsin +# From Paul Eggert (2018-01-07): +# In 1869 the Chicago Astronomical Society contracted with the city to keep +# time. Though delayed by the Great Fire, by 1880 a wire ran from the +# Dearborn Observatory (on the University of Chicago campus) to City Hall, +# which then sent signals to police and fire stations. However, railroads got +# their time signals from the Allegheny Observatory, the Madison Observatory, +# the Ann Arbor Observatory, etc., so their clocks did not agree with each +# other or with the city's official time. The confusion took some years to +# clear up. See: +# Moser M. How Chicago gave America its time zones. Chicago. 2018-01-04. +# http://www.chicagomag.com/city-life/January-2018/How-Chicago-Gave-America-I… + # From Larry M. Smith (2006-04-26) re Wisconsin: # https://docs.legis.wisconsin.gov/statutes/statutes/175.pdf # is currently enforced at the 01:00 time of change. Because the local -- 2.7.4

1 0

Three time zones meeting at one location
by Paul Eggert Dec. 29, 2017

Dec. 29, 2017

In yesterday's My Modern Met, Jessica Stewart says that in over 20 locations in the world, three different time zones converge. Surveyor Generals Corner in Australia and Treriksrøysa (for the point where Finland, Norway, and Russia meet) are two examples. For time zone hounds it may be an amusing read, if only to spot the mistakes. Stewart J. Places around the world where three time zones meet in the same spot. My Modern Met. 2017-12-28. https://mymodernmet.com/three-different-time-zones-facts/

1 0

Lithuania calls on EU to stop adjusting clocks for daylight savings
by Lord Buddha Dec. 23, 2017

Dec. 23, 2017

https://www.theguardian.com/world/2017/dec/22/lithuania-calls-on-eu-to-stop…

1 0

Transitions after those included in zoneinfo binaries?
by Paul G Dec. 21, 2017

Dec. 21, 2017

I recently noticed a discrepancy between the python-dateutil and pytz libraries when calculating offsets for dates after the last included transition in the zonefile binaries. What it boils down to is that when it runs out of transitions, python-dateutil selects the "standard" offset and pytz assumes that after the last transition the value "holds". In the southern hemisphere, this produces two different behaviors. Obviously there's no "right" answer here, since these are predictions about what time zones will be applied 20 years in the future (and even if the rules stayed the same, the "end date" is entirely artificial). Still, I wonder if it might be worth a bit of discussion and possibly a note in the Theory file? Barring a representation of the data that exposes the rules directly (in which case no such artificial limitation would be necessary), I think either fallback is defensible. Best, Paul

7 10

Complexities of time rendered graphically
by Steve Jones Dec. 19, 2017

Dec. 19, 2017

Folks: Today's XKCD comic is amusing: https://xkcd.com/1930/ Steve Jones [image: Emacs!]

3 5

default value of TZDEFAULT
by scs＠eskimo.com Dec. 18, 2017

Dec. 18, 2017

[This is a tzcode issue, not tzdata. Your regular discussion of zone definition and naming issues will resume shortly. :-) ] Consider this simple little program: #include <stdio.h> #include <time.h> int main() { time_t t = time(NULL); struct tm *tmp = localtime(&t); puts(asctime(tmp)); return 0; } There's nothing special about this program (that's the point). But suppose I download tzcode or tzdb and then compile the little program (call it lt.c) along with a just-built localtime(), like this: make localtime.o cc -o lt lt.c localtime.o But if I then run 'lt', it is likely not to work -- there's a pretty good chance it will print the current time in UTC, not my local time zone. If it fails, one reason is that it didn't successfully find my system's already-installed tz files. (That is, I made no attempt to build or install any new tz files.) The reason it didn't find them is obvious enough, and the Makefile contains all the hints I need: TOPDIR= /usr/local # "Compiled" time zone information is placed in the "TZDIR" directory # (and subdirectories). # Use an absolute path name for TZDIR unless you're just testing the software. # TZDIR_BASENAME should not contain "/" and should not be ".", ".." or empty. TZDIR_BASENAME= zoneinfo TZDIR= $(TOPDIR)/etc/$(TZDIR_BASENAME) And, sure enough, on my system, the already-installed tz files are not in /usr/local, they're in /usr/share. So it looks like if I change TOPDIR to /usr/share, or TZDIR to /usr/share/zoneinfo, I should be able to fix it. But no! It still doesn't work, and the reason is, my user environment doesn't have the TZ environment variable set; I'm assuming that the system's default time zone will be used. And, out of the box, the tzcode distribution assumes that the local time zone is defined by a file 'localtime' *in TZDIR*; that is, it essentially assumes that TZDEFAULT is $TZDIR/localtime. But some (perhaps even many) systems put it in /etc/localtime. That's where my (MacOS) system puts it, and a lot of Linux systems put it there, too. The upshot is that on such a system, if you compile and use localtime.c straight out of the tzcode distribution, it won't find your localtime file, and will end up falling back to UTC unless TZ is set. Since the Makefile already lets you set your own version of TZDIR (overriding the setting in tzfile.h), I think it makes sense to do the same thing for TZDEFAULT. Patch attached. With this patch in place, and with the Makefile edited to say TZDEFAULT = "/etc/localtime" fresh compiles of localtime.o correctly find my system's localtime file, and the lt program finally prints local time, as expected. (This tweak to TZDEFAULT's usage helps the extraction case -- that is, when the code tries to fetch the default zone, but not necessarily the tz file building case. I'm not sure whether 'make install' will do the right thing when TZDEFAULT is set, but it definitely doesn't do the right thing if DESTDIR and TZDEFAULT are both set. Is using DESTDIR supported? The Makefile should probably document it if so.) Diagnosing problems involving misconfigured TZDIR and TZDEFAULT variables can be surprisingly difficult. The localtime code doesn't have any way of telling you it's having trouble finding tz files in general, or the localtime file in particular. I'll address that issue in a separate thread. Steve Summit scs(a)eskimo.com

4 10

setting TZ and calling localtime_r
by scs＠eskimo.com Dec. 18, 2017

Dec. 18, 2017

There's code in tzcode (and, I suspect not coincidentally, glibc's localtime implementation as well) to not call the internal version of tzset on calls to localtime_r, but rather only on calls to localtime. The justification is that Posix says localtime_r doesn't need to update the global tzname variable. I don't have a copy of the Posix spec handy, so I can't check: does Posix also say that localtime_r doesn't need to check for and make use of a possibly-changed value of TZ? As implemented (both in tzcode and glibc), it doesn't. If a program calls localtime, then calls setenv to set a new value of TZ, then calls localtime again, it works as expected, but if it calls localtime_r, setenv, localtime_r, it doesn't. (The workaround, of course, is to call localtime_r, setenv, tzset, localtime_r.)

5 4

Kyiv
by gocdoms gocdoms Dec. 18, 2017

Dec. 18, 2017

Hello! City Kyiv is not Kiev. The *founder* of Kyiv is *Kyi*. Not Kie! Please see attached picture.

14 24

Asia/Shanghai (was: Re: Kyiv)
by Phake Nick Dec. 15, 2017

Dec. 15, 2017

Speaking of which, after reading naming convention of zones, wouldn't it still be better to rename the zone to Asia/Beijing mowadays? As almost all users are referring to the zone as "Beijing Time", if in any case there are different time standard emerge that caused Beijing and Shamghai to use different tome standard instead, then it would be more likely for the zone's user to think the Beijing time is a time being continued while Shanghai time would be another new time. In order to reflect the line of thinking and thus when future communication or ammendment easier when things really do change, would such renaming make sense? 2017年12月16日 03:20 於 "Garrett Wollman" <wollman(a)csail.mit.edu> 寫道： > > Contrast the case (which thankfully we do not have to deal with) of > the capital city of the People's Republic of China. In English, it > used to be called "Peking", and in fact in the name of the university > and of the duck dish it still is. The PRC government made a concerted > campaign to change the name used by English speakers to be "Beijing", > which is a phonetic representation of the name of the city in Mandarin > (putonghua). This has to a very large extent worked, and now most > English texts say "Beijing" and not "Peking" (although many people > still don't pronounce it "correctly" because the letters in hanyu > pinyin don't have the same sound values as they do in English). > However, in many languages *other than English*, the name of the city > has not changed -- AFAIK it's still "Pékin" in French, for example.

3 2

tzdata gpg key
by Zura Kutchava Dec. 8, 2017

Dec. 8, 2017

Dear Friends, On https://data.iana.org/time-zones/releases/ I found packages and signatures, but cannot find gpg key to veryfing them. Can you be so kind to tell me where is gpg key for verifying? I am building linux from scratch and writing script for downloading and verifying main packages, so your help will be very important. Thanks beforehand, Regards.

2 1

Europe/Kiev
by Bohdan Vovchuk Dec. 7, 2017

Dec. 7, 2017

Hello. Please change timezone *Europe/Kiev* to *Europe/Kyiv* because first variation is wrong. Ukrainian timezone should be changed to Europe/Kyiv. Kyiv - is a one and only correct international transliteration. -- *Regards, Bohdan Vovchuk*

2 1

Filling the gaps ...
by Lester Caine Dec. 5, 2017

Dec. 5, 2017

The main problem that everybody seems to be skirting around is that the tz database has NO interest in exactly where someone is located and there is no remit TO manage that. Even tzdist which was the latest attempt to plug a major distribution hole has no remit on supplying the correct data for a particular location! Both are simply managing the set of rules that anybody can use where ever they are. Importantly allowing third parts to work out a local time for some elsewhere in the world. Some other data source is really needed to serve up the CURRENT set of rules for a location, and that is probably only currently possible using geonames.org which uses the current timezone_id and it's own simplified timeZone.txt table! What is missing is any historic (or ongoing) changes to that information, such as a location that was using one tz rule set but moved to another. In addition any pre-1970 material can not be identified. tzdist has the remit and tools to fill one of the holes that tz on it's own can not and that is historic changes TO the rule sets. My interest in the tz database came from a major problem with material that had been normalised to UTC time but there was no record as to what rules had been used TO normalise the data, so one could not verify if the CURRENT tz rules were appropriate for establishing the then local times. As Paul has quite rightly pointed out, much historic data was invented, so CORRECTING the data when more accurate information is established is perfectly correct, but one needs to be able to also establish just which rules have changed and one can then adjust the material that is now suspect ( - IF APPROPRIATE ;) ) The whole point of tzdist was to sort current day problems, so if a mobile device with a stored calendar lands in a new location where there has been an 'unscheduled' change of tz rules that change CAN be propagated quickly without needing a full tz update but that will only work if someone is actually running the primary tzdist source. Moving forward, that primary tzdist source needs to maintain a full historic record prior to 1970 since it also provides the base from which rules for historic data normalization can be managed. It allows for the tz timezone_id's to be used to identify the base rule sets, but allows new rule sets to be created ... just without any rules on just how THAT is managed :( Potentially any geonameid could have it's own individual tzdist dataset and track the history of changes as a location moves from one political jurisdiction to another and show it's simple solar time as appropriate. Something that neither tzdist or tz is actually mandated to supply? Merging geonames.org with openstreetmap.org one gets graphic displays of the area that timezones CURRENTLY cover, but one can not establish if the same offsets applied back in the 1960's when DST local times are well documented. And both databases throw away the historic data to those mappings along with a whole load of other historic material. While the vast majority of users probably could not care less, the annoyance here is that the material existed so it's not as if we are asking for extra work, just a mechanism that remembers that say in 2014 the Crimea moved from one set of tz rules to another. Once the mechanism is in place, then as new historic material comes to light, the historic record can be corrected and tzdist has the mechanism for that in relation to timezone rules. So as a start ... what has happened to tzdist. The full historic record of tz changes can provide a complete set of data that has been used over the last 20 years and as new changes are logged in now they can be pushed to tzdist while also maintaining tz distribution for off-line population systems. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

3 3