May 2020 - tz - lists.iana.org

Re: [tz] Welcome to the "tz" mailing list
by Michael H Deckers May 23, 2020

May 23, 2020

On 2020-05-22 15:42, Sundar Sarma wrote: > So could you please tell me that how to get the version used by java in > joda time?? Joda time uses their own time zone data. I do not think you can ask for the version (but I have not looked into Joda time in ages). You can, however, list the data that Joda time keeps for a time zone by repeatedly calling the method DateTimeZone.nextTransition(instant). HTH Michael Deckers.

1 0

Re: [tz] Welcome to the "tz" mailing list
by Sundar Sarma May 21, 2020

May 21, 2020

Hello team, According to the latest 2020a tz update: Canada's Yukon, represented by America/Whitehorse and America/Dawson, advanced to -07 year-round, beginning with its spring-forward transition on 2020-03-08, and will not fall back on 2020-11-01. We have written a test cases like below for canada yukon timezone. We imported new 2020a tz into our environment. Our code seems correct but test cases are failing. So we found that there is wrong in Iana tz side. Please check and correct us. This is the below code we have written. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on 2nd nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); -------> here we are getting error: java.lang.AssertionError: expected:<-7> but was:<-8> } The above test case according to your update (will not fall back on 2020-11-01) is correct. But test case is failing. Could you please clarify us that is there anything wrong from IANA tz. If not how can i write my test case according to that? Regards, Sundar On Wed, May 20, 2020 at 3:51 PM <tz-request(a)iana.org> wrote: > Welcome to the tz(a)iana.org mailing list! > > > --- > > NOTE WELL > > Any submission to the IETF intended by the Contributor for publication > as all or part of an IETF Internet-Draft or RFC and any statement made > within the context of an IETF activity is considered an "IETF > Contribution". Such statements include oral statements in IETF > sessions, as well as written and electronic communications made at any > time or place, which are addressed to: > > * The IETF plenary session * The IESG, or any member thereof on behalf > of the IESG * Any IETF mailing list, including the IETF list itself, > any working group or design team list, or any other list functioning > under IETF auspices * Any IETF working group or portion thereof * Any > Birds of a Feather (BOF) session * The IAB or any member thereof on > behalf of the IAB * The RFC Editor or the Internet-Drafts function * > All IETF Contributions are subject to the rules of RFC 5378 and RFC > 3979 (updated by RFC 4879). > > Statements made outside of an IETF session, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not IETF Contributions in the context > of this notice. > > Please consult RFC 5378 and RFC 3979 for details. > > A participant in any IETF activity is deemed to accept all IETF rules > of process, as documented in Best Current Practices RFCs and IESG > Statements. > > A participant in any IETF activity acknowledges that written, audio > and video records of meetings may be made and may be available to the > public. > > --- > > To post to this list, send your email to: > > tz(a)iana.org > > General information about the mailing list is at: > > https://mm.icann.org/mailman/listinfo/tz > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://mm.icann.org/mailman/options/tz/gkssarma59%40gmail.com > > You can also make such adjustments via email by sending a message to: > > tz-request(a)iana.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > Gks59@smu > > Normally, Mailman will remind you of your iana.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. >

5 10

Proper (stable) way to list installed time zones?
by Paul Ganssle May 15, 2020

May 15, 2020

As part of the implementation of IANA time zone support in the Python standard library (which is now accepted <https://www.python.org/dev/peps/pep-0615/> for inclusion in Python 3.9 — many thanks to those who commented on the original proposal), I realized that likely a common feature request is to get the list of time zones installed in the system. I have a candidate implementation <https://github.com/pganssle/zoneinfo/pull/60> for this, which basically walks each potential install directory (there's a "time zone search path" equivalent to PATH) and populates a list of every file installed there which starts with the `TZif` magic string. The problem I'm running into is that tzcode installs `posix/` and `right/` folders, so for each entry in zoneinfo, I get three entries: "Africa/Abidjan", "posix/Africa/Abidjan" and "right/Africa/Abidjan". I'm also seeing a `posixrules` zone in the zoneinfo root. My questions are: 1. Is there a better source for the list of installed time zones (leaving aside `tzdata.zi`, which I don't think I can count on to exist in all environments). 2. Is there any stable and standard way to distinguish between proper zones and other things that are also zone files like posixrules and right/ and posix/? In my own redistribution of the data, I populate a list of zones from `make zonenames`, which I note does /not/ include posix/, right/ or posixrules, but I don't think that information is included in standard distributions of zoneinfo. The closest I can find is `zone1970.tab` and `zone.tab` (which I think is not even always included), and that appears to be only a subset of the output of `make zonenames`. Thanks, Paul

4 5

suggestion: split "backward" into "backward" and "deprecated"
by Andrew Gierth May 5, 2020

May 5, 2020

In a post on this list on Nov 24 last, Garret Wollman said regarding FreeBSD's c.1994 change (now reversed) to not install "backward": >> I chose not to install the "backward" zones in the hope that this >> would more securely deprecate the then-recently-obsoleted old-style >> names like "US/Eastern", and then maybe they could be completely >> removed from the distribution if other downstream consumers (only a >> few operating systems at that point, no language runtimes) would do >> likewise. >> Unfortunately, these ancient compatibility links never got deleted, >> so "backward" now contains a mix of ancient and more recent >> compatibility links, and users are still using them (or being told >> to use them by documentation that should have been updated decades >> ago). The obvious way to resolve this would be to split "backward" into two: one file containing aliases that were once regarded as canonical names (or at least names consistent with current naming theory) but were then renamed (e.g. the recent example of Godthab -> Nuuk), the other containing all the ancient stuff that never conformed to the current style (such as "W-SU", "Poland", "GB-Eire", "US/Eastern" etc.). One way to do this might be to set a cutoff date, for which the 2000a data release seems like a good choice, and retain only the zones changed since then in "backward", moving the remainder to a new "deprecated" category. Another way would be to reserve "backward" for zones that have appeared in zone.tab at any time, and move the rest to "deprecated". It turns out that these two methods give almost exactly the same results, with only two exceptions: America/Ensenada was in "backward" before 2000 going by the SCM history, but existed in zone.tab until 2010; and Asia/Ulan_Bator was added to "backward" and removed from zone.tab in the 2000a release. This suggests that the zone.tab criterion is a slightly better one. (One further exception should be made: the link from Etc/UTC to UTC is in widespread use and should probably be moved to "etcetera" alongside the similar "GMT" link. Otherwise it should stay in "backward". This change already exists in FreeBSD, where all "GMT" defaults have been changed to "UTC" at some point.) Split this way, the list of links in "backward" would become (posted in plain text here for readability, I can submit in patch form if needed) as follows: Link Africa/Nairobi Africa/Asmera Link Africa/Abidjan Africa/Timbuktu Link America/Argentina/Catamarca America/Argentina/ComodRivadavia Link America/Argentina/Buenos_Aires America/Buenos_Aires Link America/Argentina/Catamarca America/Catamarca Link America/Atikokan America/Coral_Harbour Link America/Argentina/Cordoba America/Cordoba Link America/Tijuana America/Ensenada Link America/Nuuk America/Godthab Link America/Indiana/Indianapolis America/Indianapolis Link America/Argentina/Jujuy America/Jujuy Link America/Kentucky/Louisville America/Louisville Link America/Argentina/Mendoza America/Mendoza Link America/Toronto America/Montreal Link America/Rio_Branco America/Porto_Acre Link America/Argentina/Cordoba America/Rosario Link America/Tijuana America/Santa_Isabel Link America/Denver America/Shiprock Link Pacific/Auckland Antarctica/South_Pole Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Kolkata Asia/Calcutta Link Asia/Shanghai Asia/Chongqing Link Asia/Shanghai Asia/Chungking Link Asia/Dhaka Asia/Dacca Link Asia/Shanghai Asia/Harbin Link Asia/Urumqi Asia/Kashgar Link Asia/Kathmandu Asia/Katmandu Link Asia/Macau Asia/Macao Link Asia/Yangon Asia/Rangoon Link Asia/Ho_Chi_Minh Asia/Saigon Link Asia/Thimphu Asia/Thimbu Link Asia/Makassar Asia/Ujung_Pandang Link Asia/Ulaanbaatar Asia/Ulan_Bator Link Atlantic/Faroe Atlantic/Faeroe Link Europe/Oslo Atlantic/Jan_Mayen Link Etc/UTC Etc/UCT Link Europe/London Europe/Belfast Link Europe/Chisinau Europe/Tiraspol Link Pacific/Honolulu Pacific/Johnston Link Pacific/Pohnpei Pacific/Ponape Link Pacific/Chuuk Pacific/Truk Link Pacific/Chuuk Pacific/Yap Link Etc/UTC UTC "deprecated" would contain these links: Link America/Adak America/Atka Link America/Indiana/Indianapolis America/Fort_Wayne Link America/Indiana/Knox America/Knox_IN Link America/Port_of_Spain America/Virgin Link Asia/Jerusalem Asia/Tel_Aviv Link Australia/Sydney Australia/ACT Link Australia/Sydney Australia/Canberra Link Australia/Lord_Howe Australia/LHI Link Australia/Sydney Australia/NSW Link Australia/Darwin Australia/North Link Australia/Brisbane Australia/Queensland Link Australia/Adelaide Australia/South Link Australia/Hobart Australia/Tasmania Link Australia/Melbourne Australia/Victoria Link Australia/Perth Australia/West Link Australia/Broken_Hill Australia/Yancowinna Link America/Rio_Branco Brazil/Acre Link America/Noronha Brazil/DeNoronha Link America/Sao_Paulo Brazil/East Link America/Manaus Brazil/West Link America/Halifax Canada/Atlantic Link America/Winnipeg Canada/Central Link America/Toronto Canada/Eastern Link America/Edmonton Canada/Mountain Link America/St_Johns Canada/Newfoundland Link America/Vancouver Canada/Pacific Link America/Regina Canada/Saskatchewan Link America/Whitehorse Canada/Yukon Link America/Santiago Chile/Continental Link Pacific/Easter Chile/EasterIsland Link America/Havana Cuba Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London GB Link Europe/London GB-Eire Link Etc/GMT GMT+0 Link Etc/GMT GMT-0 Link Etc/GMT GMT0 Link Etc/GMT Greenwich Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran Link Asia/Jerusalem Israel Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein Link Africa/Tripoli Libya Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC Link Pacific/Pago_Pago Pacific/Samoa Link Europe/Warsaw Poland Link Europe/Lisbon Portugal Link Asia/Taipei ROC Link Asia/Seoul ROK Link Asia/Singapore Singapore Link Europe/Istanbul Turkey Link Etc/UTC UCT Link America/Anchorage US/Alaska Link America/Adak US/Aleutian Link America/Phoenix US/Arizona Link America/Chicago US/Central Link America/Indiana/Indianapolis US/East-Indiana Link America/New_York US/Eastern Link Pacific/Honolulu US/Hawaii Link America/Indiana/Knox US/Indiana-Starke Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific Link Pacific/Pago_Pago US/Samoa Link Etc/UTC Universal Link Europe/Moscow W-SU Link Etc/UTC Zulu -- Andrew.

10 21

Database available in other formats
by Sergio Bonfiglio May 3, 2020

May 3, 2020

Dear Sirs, First thig first a big THANK YOU for your invaluable work. I was overwhelmed by the complexity of your database, because it requires also external pieces of code to be safely read. I was wondering if does exist the database in different formats that may be larger but more readable and easy usable. An SQL database could be really "for everyone", because can be queried by everything from everywhere by any language. If I may make a humble suggestion, a JD date in floating format that equips any record with the initial and final date of the rule/event could be of great help. With a single query, one could recall all the records that pertain a certain moment in time also with different and overlapping rules. Thanks for any reply and thank for your work that is making me sweat the classical " seven shirts". Stay well Sergio Bonfiglio ITALY

2 6

Re: [tz] tz Digest, Vol 104, Issue 1
by Reece Stewart May 1, 2020

May 1, 2020

Stop sending me should your fucken dogs On Fri., 1 May 2020, 10:00 pm , <tz-request(a)iana.org> wrote: > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. Database available in other formats (Sergio Bonfiglio) > 2. Re: Database available in other formats (Paul Eggert) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Apr 2020 17:12:55 +0200 > From: Sergio Bonfiglio <bonfiglio.sergio(a)gmail.com> > To: tz(a)iana.org > Subject: [tz] Database available in other formats > Message-ID: > < > CANCwfxiVBnHPUawqZxWEKU+W89PWxL0SNRUXAMLgX1iMTMUF7Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Sirs, > > First thig first a big THANK YOU for your invaluable work. > I was overwhelmed by the complexity of your database, because it requires > also external pieces of code to be safely read. > I was wondering if does exist the database in different formats that may be > larger but more readable and easy usable. > An SQL database could be really "for everyone", because can be queried by > everything from everywhere by any language. > If I may make a humble suggestion, a JD date in floating format that equips > any record with the initial and final date of the rule/event could be of > great help. > With a single query, one could recall all the records that pertain a > certain moment in time also with different and overlapping rules. > Thanks for any reply and thank for your work that is making me sweat the > classical " seven shirts". > Stay well > > Sergio Bonfiglio > ITALY >

1 0

[PROPOSED] More Ruthenia replacement
by Paul Eggert May 1, 2020

May 1, 2020

This follows up on an earlier patch in March, which replaced “Ruthenia” with “Transcarpathia” but missed a couple of instances. * europe: Ruthenia→Transcarpathia in commentary here, too. * theory.html: Switch to Europe/Prague as a more easily-understood example. --- europe | 2 +- theory.html | 10 ++++------ 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/europe b/europe index 5593c60..91949d6 100644 --- a/europe +++ b/europe @@ -3983,7 +3983,7 @@ Zone Europe/Kiev 2:02:04 - LMT 1880 2:00 1:00 EEST 1991 Sep 29 3:00 2:00 E-Eur EE%sT 1995 2:00 EU EE%sT -# Ruthenia used CET 1990/1991. +# Transcarpathia used CET 1990/1991. # "Uzhhorod" is the transliteration of the Rusyn/Ukrainian pronunciation, but # "Uzhgorod" is more common in English. Zone Europe/Uzhgorod 1:29:12 - LMT 1890 Oct diff --git a/theory.html b/theory.html index c0e6f02..ffa3b4d 100644 --- a/theory.html +++ b/theory.html @@ -115,17 +115,15 @@ Each timezone has a name that uniquely identifies the timezone. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like -"Ruthenia" instead of the timezone name "<code>Europe/Uzhgorod</code>". +"Czech Republic" instead of the timezone name "<code>Europe/Prague</code>". If geolocation information is available, a selection interface can locate the user on a timezone map or prioritize names that are geographically close. For an example selection interface, see the <code>tzselect</code> program in the <code><abbr>tz</abbr></code> code. -The <a href="http://cldr.unicode.org/">Unicode Common Locale Data +The <a href="http://cldr.unicode.org">Unicode Common Locale Data Repository</a> contains data that may be useful for other selection -interfaces; it maps timezone names like <code>Europe/Uzhgorod</code> -to CLDR names like <code>uauzh</code> which are in turn mapped to -locale-dependent strings like "Uzhhorod", "Ungvár", "Ужгород", and -"乌日哥罗德". +interfaces; it maps timezone names like <code>Europe/Prague</code> to +locale-dependent strings like "Prague", "Praha", "Прага", and "布拉格". </p> <p> -- 2.17.1

1 0