- tz - lists.iana.org

Re: [tz] URLs for DST changes in Hungary (full historical revision)
by Paul Eggert June 9, 2020

June 9, 2020

On 6/9/20 8:16 AM, Nyáry Géza wrote: > Year to year I enclose the URLs being about the changes, I trimmed away the view part of each URL (to keep the URL short) and installed the attached patch to the tzdb sources so that the transitions for Hungary are now much better documented. Thank you for sending us this detailed info.

1 0

How good is pre-1970 time zone history represented in TZ database?
by Alois Treindl June 4, 2020

June 4, 2020

4 10

Re: [tz] FW: [Ext] The TZ Coordination
by Paul Eggert May 28, 2020

May 28, 2020

On 5/28/20 3:41 AM, EL MAAYATI Afaf wrote: > we need to know if there is a procedure to notify IANA (TZ Coordination) officially, from a governmental source, with the official dates of TZ changes in Morocco. The procedure is to send email to tz(a)iana.org with official citations, preferably with pointers to copies in English since the mailing list is in English. For best results, give one years' notice before the dates of change. For more details, please see: https://data.iana.org/time-zones/tz-link.html#changes

1 0

zdump --version reports "unknown" on OpenSuse 15.1 [2020a]
by listclient＠hayo.de May 28, 2020

May 28, 2020

Hi all, when checking the timezone database version on my OpenSuse 15.1 Linux, I do not get the expected result. hayo@computer:~> sudo zdump --version zdump (tzcode) unknown Installed package: timezone - Time Zone Descriptions Is this a defect of the OpenSuse package or of the IANA code distribution? Regards, Hayo More Details ------------ Technical data: Installierte Version 2020a-lp151.2.9.1 Mo 18 Mai 2020 10:13:45 CEST Sa 23 Mai 2020 20:03:30 CEST System/Base BSD-3-Clause AND SUSE-Public-Domain 1,1 MiB 0 B openSUSE Leap 15.1 openSUSE http://bugs.opensuse.org x86_64 http://www.iana.org/time-zones timezone-2020a-lp151.2.9.1 0 File list: /etc/localtime /usr/bin/tzselect /usr/sbin/zdump /usr/sbin/zic /usr/share/zoneinfo ... Change log: Fr 24 Apr 2020 14:00:00 CEST Marketa Calabkova <mcalabkova(a)suse.com> - timezone update 2020a (bsc#1169582) * Morocco springs forward on 2020-05-31, not 2020-05-24. * Canada's Yukon advanced to -07 year-round on 2020-03-08. * America/Nuuk renamed from America/Godthab. * zic now supports expiration dates for leap second lists.

8 11

Re: [tz] Fwd: TR: Morocco : Time Change
by Semlali Naoufal May 27, 2020

May 27, 2020

Hello, I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. Has the patch below been deployed correctly? For iPhone, the time is not changed. Regards, -----Message d'origine----- De : Paul Eggert <eggert(a)cs.ucla.edu> Envoyé : mercredi 15 avril 2020 06:26 À : Semlali Naoufal <N.Semlali(a)iam.ma>; Tim Parenti <tim(a)timtimeonline.com> Cc : Maamar Abdelkader <A.MAAMAR(a)iam.ma>; Time zone mailing list <tz(a)iana.org> Objet : Re: Morocco : Time Change Thanks for the heads-up. A proposed patch is attached. Looks like we'll need a new tzdb release soon, since the current release is wrong for Morocco starting May 24. ________________________________ [Description : cid:image002.jpg@01CC9EE4.44A57D10]Eco – geste: privilégiez la sauvegarde électronique, si nécessaire imprimez en recto-verso ________________________________ Ce message et toutes les pièces jointes sont adressés à l'attention exclusive de leurs destinataires et sont strictement confidentiels. Si vous le recevez par erreur, merci de le détruire après en avoir informé l'expéditeur sans délai. Toute divulgation, copie ou usage par une personne autre que son destinataire sont interdits. Maroc Telecom décline toute responsabilité pour toute altération, déformation ou falsification subie par le message au cours de sa transmission. Retrouvez toutes les informations de Maroc Telecom sur www.iam.ma . ________________________________ This message and its attachments are intended only for the person or entity to which it is addressed and are strictly confidential. If you have received this in error, please delete the material from any computer after having informed the sender. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited. Maroc Telecom accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about Maroc Telecom on www.iam.ma .

5 4

Typo in a 1900 date of europe tz file
by josep lladonosa capell May 27, 2020

May 27, 2020

Hello, I was just reading the europe tz file and found a typo. The comment in the file gives the date 26/6/1900 but in fact it was July (7) not June (6). In the same text there is a reference to the official document of 26/7/1900. Attached you will find the patch.

1 0

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

May 25, 2020

we have used this code to get the IANA tz version. public static String getTimezoneDatabaseIANAVersion() { File readmeFile = new File(ZONEINFO_PATH, "README"); File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); if (!readmeFile.exists()) { readmeFile = alternativeReadmeFile; } out read me.txt file contain generated by Gradle Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz means we are using correct tzdata2020a. But still why there is issue? Something wrong with tz db?? regards, sundar On Fri, May 22, 2020 at 9:12 PM Sundar Sarma <gkssarma59(a)gmail.com> wrote: > ZoneRulesProvider.getVersions( String zoneId ). > which gives the version used by Java. > > this above code gives the version used by java. > > that is correct. Bu the above code is java.time > > we are using joda.time in our application. > > So could you please tell me that how to get the version used by java in > joda time?? > > thanks, > sundar > > On Thu, May 21, 2020 at 6:39 PM Michael H Deckers < > michael.h.deckers(a)googlemail.com> wrote: > >> >> On 2020-05-21 12:39, Sundar Sarma wrote: >> >> >> > Still i did not understand why this test case is failing with new 2020a >> tz. >> >> >> The version of the IANA database installed in the operating >> system may well differ from the version used by Java.time. >> The latter can be determined with the method >> ZoneRulesProvider.getVersions( String zoneId ). >> which gives the version used by Java. >> >> HTH. >> >> Michael Deckers. >> >> >> >>

3 4

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