- tz - lists.iana.org

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

[PROPOSED] Pacify GCC 7.2.1 x86-64 -Wmaybe-uninitialized
by Paul Eggert Dec. 4, 2017

Dec. 4, 2017

* zdump.c (main): Add an INITIALIZE to pacify gcc 7.2.1 20170915 (Red Hat 7.2.1-2) on x86-64 with -Wmaybe-uninitialized, which otherwise incorrectly warns that ‘ab’ might be used uninitialized. Clarify the expression that confused GCC (though the clarification is evidently not enough). --- zdump.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/zdump.c b/zdump.c index 3cd4f42..60a027e 100644 --- a/zdump.c +++ b/zdump.c @@ -552,6 +552,7 @@ main(int argc, char *argv[]) } if (t < cutlotime) t = cutlotime; + INITIALIZE (ab); tm_ok = my_localtime_rz(tz, &t, &tm) != NULL; if (tm_ok) { ab = saveabbr(&abbrev, &abbrevsize, &tm); @@ -567,11 +568,10 @@ main(int argc, char *argv[]) : cuthitime); struct tm *newtmp = localtime_rz(tz, &newt, &newtm); bool newtm_ok = newtmp != NULL; - if (! (tm_ok & newtm_ok - ? (delta(&newtm, &tm) == newt - t - && newtm.tm_isdst == tm.tm_isdst - && strcmp(abbr(&newtm), ab) == 0) - : tm_ok == newtm_ok)) { + if (tm_ok != newtm_ok + || (tm_ok && (delta(&newtm, &tm) != newt - t + || newtm.tm_isdst != tm.tm_isdst + || strcmp(abbr(&newtm), ab) != 0))) { newt = hunt(tz, argv[i], t, newt); newtmp = localtime_rz(tz, &newt, &newtm); newtm_ok = newtmp != NULL; -- 2.14.3

1 0

Very cool app that uses yout TZ Database
by Anton Skorniakov Dec. 4, 2017

Dec. 4, 2017

Hello! First of all, I want to thank you very much for such cool time zones database, we are using it in our product. I want to suggest adding one more cool and simple free web based time zone converter app https://timezoneconverterapp.com/ to this page https://data.iana.org/time-zones/tz-link.html (“Web sites using recent versions of the tz database” section). I am one of the creators of this app and of course, it uses IANA TZ Database. Thank you! _________________ Anton

2 1

Fwd: New Version Notification for draft-murchison-tzdist-tzif-00.txt
by Ken Murchison Nov. 27, 2017

Nov. 27, 2017

FYI. This is our initial effort at "officially" documenting the time zone data binary format and defining a MIME type for it so it can be used with the Time Zone Distribution Service. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-tzdist-tzif-00.txt Date: Mon, 27 Nov 2017 04:58:00 -0800 From: internet-drafts(a)ietf.org To: Arthur David Olson <arthurdavidolson(a)gmail.com>, Paul Eggert <eggert(a)cs.ucla.edu>, Ken Murchison <murch(a)fastmailteam.com>, Arthur Olson <arthurdavidolson(a)gmail.com>, Kenneth Murchison <murch(a)fastmailteam.com> A new version of I-D, draft-murchison-tzdist-tzif-00.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-tzdist-tzif Revision: 00 Title: The Time Zone Information Format (TZif) Document date: 2017-11-26 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-murchison-tzdist-tzif-00.txt Status: https://datatracker.ietf.org/doc/draft-murchison-tzdist-tzif/ Htmlized: https://tools.ietf.org/html/draft-murchison-tzdist-tzif-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-tzdist-tzif-00 Abstract: This document defines the Time Zone Information File Format for representing and exchanging time zone information, independent of any particular service or protocol. A MIME media type for this format is also defined. Open Issues o Need to review definitions of terms. o Should we require TZDIST servers to always return a particular format (2 or 3) with/without leap seconds? Or should we allow the client to choose what they want (via parameters on the MIME type)? o Are we referencing the correct and most current versions of the relevant POSIX specs? o Is the MIME registration complete and correct (e.g. any security or privacy considerations)? Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat

1 0

FW: Beginner's help request
by Daniel Ford Nov. 25, 2017

Nov. 25, 2017

Oops, looks like I was mistaken. Howard's library appears to be not (specifically) for Arduino, but a C++ library for Windows (and maybe other) platforms. Maybe it will compile in the Arduino IDE, though I suspect it will be problematic, if possible at all. And I've so far found only one TZdb mirror that keeps a current copy of the data - very disappointing. It's a shame the whole TZdb scheme is so user-unfriendly. Quite discouraging. Regards, Daniel -----Original Message----- From: Daniel Ford [mailto:dfnojunk@gmail.com] Sent: Saturday, November 04, 2017 7:03 PM To: 'Time zone mailing list' Subject: RE: [tz] Beginner's help request Woohoo! I've discovered (and downloaded) an Arduino library, written by Howard E. Hinnant: "This timezone library is a complete parser of the IANA timezone database. It provides for an easy way to access all of the data in this database, using the types from "date.h" and <chrono>. The IANA database also includes data on leap seconds, and this library provides utilities to compute with that information as well." All I need to find now are established TZdb mirrors that keep their copy up-to-date, so I don't overload the master TZdb with queries. Can anyone point me to any, please? Regards, Daniel --------------- Daniel Ford (Gerroa, Australia)

7 20

Beginner's help request
by Daniel Ford Nov. 21, 2017

Nov. 21, 2017

I'm looking to develop a 'world clock' that could be sold to anyone (with Internet access via a Wi-Fi AP) anywhere in the world, that will display their local time, taking into account DST if/when applicable. Given that DST 'rules' can change at the whim of governments, my firmware will need to annually look up 'current' DST rules from the web. After much searching, it seems that your TZ Database is the best supported such reference for time zone rules. But I'm having great difficulty working out how I might access its mine of information... (I'll understand if you don't have time to help out a beginner, and maybe then you could refer me to a help site for TZ database applications.) I'm a hardware engineer with some programming experience, particularly assembler (various MCUs) and some C, but little or no experience in other languages. I'm developing this clock on an Arduino-like platform (NodeMCU, which has in-built Wi-Fi). My development tools run on a Win7Pro64 PC. The tools that you kindly provide for your database appear to be geared primarily towards Linux/Unix platforms, and I have no idea how I might convert them for a NodeMCU! I'm looking for some 'simple' way to access the desired TZ/DST information, preferably using simple string searches. For my application, all I'm interested in are the *current* rules. The wealth of history in your db is undoubtedly of interest to many, but for me is just 'clutter' to be searched through. But writing a program to find those rules for a particular locality has me stumped right now. I can't expect my dumb users to know a letter code for their time-zone/DST-rules, so all I'm expecting them to select from program-generated lists are: (1) their world region (Europe, Asia, Australasia, etc), and (2) the name of a major city in their time-zone with the same DST rules they follow. Let's take a concrete example: say my user has nominated 'Australasia' and 'Hobart'. So I look in your Australasia file and do a (manual at this stage) search for 'Hobart', but find only one reference to it (other than in comments). The jumble of numbers and letters there do not (clearly) tell me when DTS starts or ends. So how could I possibly write some code to find out that required information?? I've looked through the TZ_database-2017b.tar file for some sort of 'how-to' explanation of what all the file contents mean and how to programmatically search for a specific TZ, but have so far found nothing. Ideally, what I'd like to see is a text-only table of just current TZ/DST rules for each region/locality (they could all fit into a single file with all the historical data and comments removed), perhaps in the clear form used by Jack Christensen in his excellent Arduino Timezone library examples, such as... // Australia Eastern Time Zone (Sydney, Melbourne, Hobart) TimeChangeRule aEDT = {"AEDT", First, Sun, Oct, 2, 660}; TimeChangeRule aEST = {"AEST", First, Sun, Apr, 3, 600}; TimezoneExt ausET("NSW, Vic, Tas", aEDT, aEST); // Australia Eastern Time Zone (Brisbane) TimezoneExt QldT("Queensland", aEST, aEST); // no DST in Qld! ... which clearly tells me in a program-searchable way that in the main eastern states DST starts on the first Sunday in October at 2am, becoming UTC offset +11 hours (660 minutes), and ends on the first Sunday in April at 3am, reverting to UTC offset +10 hours. Couldn't be simpler! Any help in using the TZ database will be much appreciated (and acknowledged in my source code). Regards, Daniel --------------- Daniel Ford (Gerroa, Australia) "My loathings are simple: stupidity, oppression, crime, cruelty, soft music." - Vladimir Nabokov

17 63

[PROPOSED] Update TZDIST citation.
by Paul Eggert Nov. 21, 2017

Nov. 21, 2017

* tz-link.htm: Update TZDIST URL and discussion. (Thanks to Ken Murchison for the heads-up.) --- tz-link.htm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tz-link.htm b/tz-link.htm index 0684ed1..edf8eec 100644 --- a/tz-link.htm +++ b/tz-link.htm @@ -267,10 +267,10 @@ href="https://tools.ietf.org/html/rfc7808">TZDIST</a> (Internet <abbr>RFC</abbr> 7808), a time zone data distribution service, along with <a href="https://tools.ietf.org/html/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for -transferring time zone data by reference. The (expired) draft <a +transferring time zone data by reference. The draft <a id="TZDIST-Geolocate" -href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-00">TZDIST -Geolocate Extension</a> would have let a client determine its time zone region +href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-01">TZDIST +Geolocate Extension</a> lets a client determine its time zone region from its geographic location using a <a href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> -- 2.7.4

1 0