- tz - lists.iana.org

Use or Apply for SPDX Licence
by Brian Inglis June 23, 2020

June 23, 2020

Hi folks, It would be useful to distributions, packagers, and organization licence checkers if the tzcode and tzdata were covered by (a) Public Domain SPDX licence identifier(s) https://spdx.org/licenses/ e.g. CC-PDDC, PDDL, SAX-PD, Unlicense, WTFPL, etc. or applied for it's own e.g. IANA-TZ-PD. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]

10 14

[PROPOSED] zic now defaults to ‘-b slim’
by Paul Eggert June 21, 2020

June 21, 2020

Make zic’s ‘-b slim’ option the default. This option first appeared in tzdb 2019b (2019-07-01), and is already the default in NetBSD 9.0 (2020-02-14) and seems to be working there. Using slim format should help finish off the TZif format’s Y2038 transition that began in tzcode 95f (1995-10-28). * Makefile, NEWS, zic.8: Mention this. * zic.c (ZIC_BLOAT_DEFAULT): Default to "slim". --- Makefile | 10 +++++----- NEWS | 2 ++ zic.8 | 10 ++++------ zic.c | 5 ++--- 4 files changed, 13 insertions(+), 14 deletions(-) diff --git a/Makefile b/Makefile index 0da7c3f..8abd4d0 100644 --- a/Makefile +++ b/Makefile @@ -22,6 +22,7 @@ BUGEMAIL= tz(a)iana.org # DATAFORM= main # To wait even longer for new features, use: # DATAFORM= rearguard +# Rearguard users might also want "ZFLAGS = -b fat"; see below. DATAFORM= main # Change the line below for your timezone (after finding the one you want in @@ -249,13 +250,12 @@ LDLIBS= # other than simply getting garbage data # -DUSE_LTZ=0 to build zdump with the system time zone library # Also set TZDOBJS=zdump.o and CHECK_TIME_T_ALTERNATIVES= below. -# -DZIC_BLOAT_DEFAULT=\"slim\" to default zic's -b option to "slim", and -# similarly for "fat". Fat TZif files work around incompatibilities +# -DZIC_BLOAT_DEFAULT=\"fat\" to default zic's -b option to "fat", and +# similarly for "slim". Fat TZif files work around incompatibilities # and bugs in some TZif readers, notably readers that mishandle 64-bit # data in TZif files. Slim TZif files are more efficient and do not # work around these incompatibilities and bugs. If not given, the -# current default is "fat" but this is intended to change as readers -# requiring fat files often mishandle timestamps after 2037 anyway. +# default is "slim". # -DZIC_MAX_ABBR_LEN_WO_WARN=3 # (or some other number) to set the maximum time zone abbreviation length # that zic will accept without a warning (the default is 6) @@ -390,7 +390,7 @@ ZIC= $(zic) $(ZFLAGS) # To shrink the size of installed TZif files, # append "-r @N" to omit data before N-seconds-after-the-Epoch. -# You can also append "-b slim" if that is not already the default; +# To grow the files and work around older application bugs, append "-b fat"; # see ZIC_BLOAT_DEFAULT above. # See the zic man page for more about -b and -r. ZFLAGS= diff --git a/NEWS b/NEWS index bfe02ea..6b9fd43 100644 --- a/NEWS +++ b/NEWS @@ -23,6 +23,8 @@ Unreleased, experimental changes Changes to code + zic now defaults to '-b slim' instead of to '-b fat'. + zic's new '-l -' and '-p -' options uninstall any existing localtime and posixrules files, respectively. diff --git a/zic.8 b/zic.8 index a431311..8d34368 100644 --- a/zic.8 +++ b/zic.8 @@ -61,15 +61,13 @@ is .BR slim , keep the output files small; this can help check for the bugs and incompatibilities. -Although the default is currently -.BR fat , -this is intended to change in future -.B zic -versions, as software that mishandles the 64-bit data typically +The default is +.BR slim , +as software that mishandles 64-bit data typically mishandles timestamps after the year 2038 anyway. Also see the .B \*-r -option for another way to shrink output size. +option for another way to alter output size. .TP .BI "\*-d " directory Create time conversion information files in the named directory rather than diff --git a/zic.c b/zic.c index c874b04..3aed819 100644 --- a/zic.c +++ b/zic.c @@ -661,8 +661,7 @@ static const char * tzdefault; static const char * yitcommand; /* -1 if the TZif output file should be slim, 0 if default, 1 if the - output should be fat for backward compatibility. Currently the - default is fat, although this may change. */ + output should be fat for backward compatibility. The default is slim. */ static int bloat; static bool @@ -672,7 +671,7 @@ want_bloat(void) } #ifndef ZIC_BLOAT_DEFAULT -# define ZIC_BLOAT_DEFAULT "fat" +# define ZIC_BLOAT_DEFAULT "slim" #endif int -- 2.17.1

1 0

Sudan/Khartoum time zone
by Ubay Abdelgadir June 21, 2020

June 21, 2020

Dears at IANA, Khartoum's time zone is +2 since 1/Nov/2017. I think it is wrong in the IANA database: Zone Africa/Khartoum 2:10:08 - LMT 1931 2:00 Sudan CA%sT 2000 Jan 15 12:00 3:00 - EAT 2017 Nov 1 2:00 - CAT BR Ubay Abdelgadir

3 2

Formal models and the need for storing original source data
by Michael Kenniston June 21, 2020

June 21, 2020

> > ---------- Forwarded message ---------- > From: Robert Elz <kre(a)munnari.oz.au> > To: Lester Caine <lester(a)lsces.uk> > Cc: tz(a)iana.org > Bcc: > Date: Wed, 03 Jun 2020 19:31:43 +0700 > Subject: Re: [tz] How good is pre-1970 time zone history represented in TZ > database? > Date: Wed, 3 Jun 2020 12:22:32 +0100 > From: Lester Caine <lester(a)lsces.uk> > Message-ID: <3576438c-e0bd-7188-2153-43d80e9054b8(a)lsces.uk> > > There are two kinds of > changes that may be made to a zone. One affects only future timestamps, > and is the common old garden variety "government interference" or however > you think of it. These are far and away the most common changes. While > when we have insufficient notification of a change, it may be applied > retrospectively, when that has happened, everyone tends to be very aware > that there were bad time conversions for a while. In any case, old > historic stored data isn't affected at all by this kind of change, it > is as valid (or not) after the change as it was before. > You can also have data recorded in the past which refers to the future, so even a change that affects only future timestamps can still invalidate existing stored data. > The second kind of change is a correction to historic data. This happens > when > we discover an error in what was present (and these days, almost only ever > affects pre-1970 timestamps). > > In those, if someone had stored the UTC converted form of some local > timestamp, > then after the correction they wouldn't get back the data that was > originally > used to produce it. > > The problem there is having discarded the original data instead of > retaining > it. Always retain the original source data. Then by all means, when > computing, convert timestamps from their various local values to UTC so > they can be more easily correctly ordered (or whatever) but use those > converted values only for transient computations. Store the original. > Always. > > If that is done correctly, then after a correction to old data, the > results might be different than they were before - but that's only because > they were wrong before, and (hopefully) better after the fix. > I agree 100%. I've been struggling for years to really get my head wrapped around this stuff, and finally decided to create a formal model using abstract data types. I'm finding that approach to be quite helpful, so I wrote it up in a couple of essays that folks on this list might find interesting. In fact, the folks on this list may well be the *only* people who would find them interesting. :-) The first is aimed at the general programmer, but it introduces the fundamental concepts: https://drive.google.com/file/d/1WntAyhIawYtbL2k3fPE71cM9EFkVCJGQ/view?usp=… The second is aimed at time geeks and goes much deeper into the underlying theory: https://drive.google.com/file/d/1aOj9YeDFUST0lQFXZiUsCSmxjnzlbIe4/view?usp=… These are still in draft form, but I hope others find some value in them. (Teaser: the model makes no reference to years, days, hours, or seconds. How's that for abstract?) What is rather interesting (and reassuring) is that the formal model ends up telling us pretty much what this thread has been saying: store original data. However, by looking at things in terms of abstract data types, you can easily see *why* you need to do that without having to resort to specific examples, and many seemingly unrelated cases can be seen to be special cases of the same underlying phenomenon. The model also points you to the very specific places in your design and code where you have to watch out for problems. > The only time it makes sense to store timestamps in other than the original > form is when we *know* that the conversion is correct (and hence, no later > correction will change it). For users of tzdata that really only applies > to post-1970 timestamps. > When exactly do we *know* anything, I mean really for sure? Imagine yourself back in 1966. UTC has been chugging along nicely for five years, providing a well-behaved predictable time standard. We know it's never going to change. Now it's 1967. Oops, the name just changed. Well, that doesn't really count, a rose by any other name ... Now it's 1972. Oops again, we just added a leap second, and there are more on the way. Sorry unix time_t, your fundamental assumption was just revoked -- and so for the next 50 years, nearly every computer on the planet will stubbornly refuse to accept the existence of leap seconds. Never say never. > ---------- Forwarded message ---------- > From: Robert Elz <kre(a)munnari.oz.au> > To: Lester Caine <lester(a)lsces.uk> > Cc: tz(a)iana.org > Bcc: > Date: Wed, 03 Jun 2020 23:48:42 +0700 > Subject: Re: [tz] How good is pre-1970 time zone history represented in TZ > database? > Date: Wed, 3 Jun 2020 16:02:45 +0100 > From: Lester Caine <lester(a)lsces.uk> > Message-ID: <3b7f0c78-4dd7-0f2e-a8e3-2b24401e7e1c(a)lsces.uk> > > | I came into this 20 years ago > > I've been involved with it for longer than that - back to my first > unix experience, in '76, where the US tz rules were compiled into the > code, and most people in AU simply adjusted their computer's clock > (their offset from UTC) 4 times a year (when the US switched summer time > on and off, and when AU did - and yes, that meant that the generated GMT > timestamps were wrong, most of the time). From that (a bit later) I was > responsible for the mess that existed until ado invented tzdata (and yes, > I mean the 2nd arg to gettimeofday()). > You make me look like a newbie. I first got into this seriously in 1997 while updating legacy systems to handle Y2K. > >From all of this I have learned that time is hard. Really hard. > > Many people believe that since they learned to tell the time when > they were 4 or 5 years old, and have been doing it ever since, they > know all there is to know. That's sad... > See the discussion of seduction and polar bears in the first essay linked above. > | now while working with a data archive > | which has now been simply dumped because we had no idea what rules were > | used to produce the normalised data. > > That's a pity, byt sometimes past mistakes simply come back to bite, > and sometimes bite hard. Note that the error there was normalising the > data, if that hadn't been done, none of the rest of it would matter, > you'd now have the original data and could manipulate it however seems > best, for now, regardless of what anyone did with it decades ago (and if > you get it all wrong, future generations could cope, because they'd also > still have the original data, and can fix any errors). > > | Nowadays yes it does make sense to > | store both an original time and a normalised time, > > No, it doesn't, just the original, plus ... > > | along with a location, > > yes, something which can be mapped into a timezone - and as accurate > a location as possible. > > | and a record of which version of rules was used to do the > | normalization. > > Don't care about that, since the result won't be being saved. > > | Add to that a flag that indicates if the UTC time is fixed! > > If the UTC time is the authoritative one, that is what is stored. > No need for extra flags. Just the authoritative time - the one > which defines whatever it is that is being recorded. > I second everything Robert Elz said here. - Michael Kenniston

3 2

[PROPOSED 1/2] zic has new ‘-l -’ and ‘-p -’ options
by Paul Eggert June 13, 2020

June 13, 2020

* NEWS, zic.8: Mention this. * zic.c (dolink): If fromfield is "-", simply remove tofield. --- NEWS | 3 +++ zic.8 | 12 ++++++++++++ zic.c | 5 ++++- 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 3bcddd0..cdcdbc1 100644 --- a/NEWS +++ b/NEWS @@ -23,6 +23,9 @@ Unreleased, experimental changes Changes to code + zic's new '-l -' and '-p -' options uninstall any existing + localtime and posixrules files, respectively. + The undocumented and ineffective tzsetwall function has been removed. diff --git a/zic.8 b/zic.8 index b1bf437..a431311 100644 --- a/zic.8 +++ b/zic.8 @@ -85,6 +85,12 @@ will act as if the input contained a link line of the form .ti +.5i .ta \w'Link\0\0'u +\w'\fItimezone\fP\0\0'u Link \fItimezone\fP localtime +.sp +If +.I timezone +is +.BR \*- , +any already-existing link is removed. .TP .BI "\*-L " leapsecondfilename Read leap second information from the file with the given name. @@ -109,6 +115,12 @@ and it should not be combined with if .IR timezone 's transitions are at standard time or Universal Time (UT) instead of local time. +.sp +If +.I timezone +is +.BR \*- , +any already-existing link is removed. .TP .BR "\*-r " "[\fB@\fP\fIlo\fP][\fB/@\fP\fIhi\fP]" Reduce the size of output files by limiting their applicability diff --git a/zic.c b/zic.c index 2875b55..c874b04 100644 --- a/zic.c +++ b/zic.c @@ -981,6 +981,7 @@ hardlinkerr(char const *from, char const *to) static void dolink(char const *fromfield, char const *tofield, bool staysymlink) { + bool remove_only = strcmp(fromfield, "-") == 0; bool todirs_made = false; int link_errno; @@ -988,7 +989,7 @@ dolink(char const *fromfield, char const *tofield, bool staysymlink) ** We get to be careful here since ** there's a fair chance of root running us. */ - if (itsdir(fromfield)) { + if (!remove_only && itsdir(fromfield)) { fprintf(stderr, _("%s: link from %s/%s failed: %s\n"), progname, directory, fromfield, strerror(EPERM)); exit(EXIT_FAILURE); @@ -1003,6 +1004,8 @@ dolink(char const *fromfield, char const *tofield, bool staysymlink) progname, directory, tofield, e); exit(EXIT_FAILURE); } + if (remove_only) + return; link_errno = staysymlink ? ENOTSUP : hardlinkerr(fromfield, tofield); if (link_errno == ENOENT && !todirs_made) { mkdirs(tofield, true); -- 2.17.1

1 1

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

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

May 6, 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

[PROPOSED] Remove tzsetwall
by Paul Eggert April 24, 2020

April 24, 2020

Might as well do this now, while it’s fresh in my mind. * Makefile, NEWS: Update accordingly. * localtime.c (tzset_unlocked, tzsetlcl): Merge, since there’s now only one caller to either. * localtime.c, private.h (tzsetwall): Remove. --- Makefile | 3 +-- NEWS | 8 ++++++++ localtime.c | 20 ++------------------ private.h | 5 ----- 4 files changed, 11 insertions(+), 25 deletions(-) diff --git a/Makefile b/Makefile index 610bf19..107f67e 100644 --- a/Makefile +++ b/Makefile @@ -333,9 +333,8 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # add # -DSTD_INSPIRED # to the end of the "CFLAGS=" line. This arranges for the functions -# "tzsetwall", "offtime", "timelocal", "timegm", "timeoff", +# "offtime", "timelocal", "timegm", "timeoff", # "posix2time", and "time2posix" to be added to the time conversion library. -# "tzsetwall" is deprecated and is intended to be removed soon; see NEWS. # "offtime" is like "gmtime" except that it accepts a second (long) argument # that gives an offset to add to the time_t when converting it. # "timelocal" is equivalent to "mktime". diff --git a/NEWS b/NEWS index 321e090..ac491e1 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,13 @@ News for the tz database +Unreleased, experimental changes + + Changes to code + + The undocumented and ineffective tzsetwall function has been + removed. + + Release 2020a - 2020-04-23 16:03:47 -0700 Briefly: diff --git a/localtime.c b/localtime.c index 6623eac..d3e406b 100644 --- a/localtime.c +++ b/localtime.c @@ -1355,8 +1355,9 @@ zoneinit(struct state *sp, char const *name) } static void -tzsetlcl(char const *name) +tzset_unlocked(void) { + char const *name = getenv("TZ"); struct state *sp = lclptr; int lcl = name ? strlen(name) < sizeof lcl_TZname : -1; if (lcl < 0 @@ -1377,23 +1378,6 @@ tzsetlcl(char const *name) lcl_is_set = lcl; } -#ifdef STD_INSPIRED -void -tzsetwall(void) -{ - if (lock() != 0) - return; - tzsetlcl(NULL); - unlock(); -} -#endif - -static void -tzset_unlocked(void) -{ - tzsetlcl(getenv("TZ")); -} - void tzset(void) { diff --git a/private.h b/private.h index 8513663..9efcd78 100644 --- a/private.h +++ b/private.h @@ -477,8 +477,6 @@ typedef time_tz tz_time_t; # define tzfree tz_tzfree # undef tzset # define tzset tz_tzset -# undef tzsetwall -# define tzsetwall tz_tzsetwall # if HAVE_STRFTIME_L # undef strftime_l # define strftime_l tz_strftime_l @@ -551,9 +549,6 @@ extern long altzone; */ #ifdef STD_INSPIRED -# if TZ_TIME_T || !defined tzsetwall -void tzsetwall(void); -# endif # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif -- 2.17.1

1 0

Re: [tz] [Bug 207345] zdump(8): zdump -c has an opposite behavior, in my xterm: lower bound is inclusive ...
by Paul Eggert April 24, 2020

April 24, 2020

I installed the attached doc patch to tzdb try to clarify things. The documented zdump behavior is kind of weird, but now's not the time to change it as we're about to do a new tzdb release.

2 1

Moroccan DST 2020 Change
by Ali ABDUL HAKEEM (Presta) April 24, 2020

April 24, 2020

Hello, Please note that the Moroccan government decided to activate DST between April 19th at 3am and may 31st at 2am. Hoping that you'll update the tzdata database soon. Regards, Ali Abdul Hakeem, OCM | IT Consultant | Tél: +212 520 475 306 Eurafric-Information | Département Système et bases de données [O_Database12c_Admin_Master_clr][OCM_ODb11gAdmin_clr][OCM_ODb10gAdmin_clr][OCP_MySQL5][RHCSA] [O_Certified Specialist_clr][CertWS_sm] [CertPowerSystems_sm]

2 3

'Australia/Canberra' time zone?
by John Pye April 24, 2020

April 24, 2020

Hi there I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000. What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion? Here is what I believe to be an official source about the Canberra timezone (at least for the present day): https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-a… Cheers JP

8 19

[tz-announce] 2020a release of tz code and data available
by Paul Eggert April 24, 2020

April 24, 2020

The 2020a release of the tz code and data is available. It reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Briefly: 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. Changes to future timestamps Morocco's second spring-forward transition in 2020 will be May 31, not May 24 as predicted earlier. (Thanks to Semlali Naoufal.) Adjust future-year predictions to use the first Sunday after the day after Ramadan, not the first Sunday after Ramadan. 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. Although a government press release calls this "permanent Pacific Daylight Saving Time", we prefer MST for consistency with nearby Dawson Creek, Creston, and Fort Nelson. (Thanks to Tim Parenti.) Changes to past timestamps Shanghai observed DST in 1919. (Thanks to Phake Nick.) Changes to timezone identifiers To reflect current usage in English better, America/Godthab has been renamed to America/Nuuk. A backwards-compatibility link remains for the old name. Changes to code localtime.c no longer mishandles timestamps after the last transition in a TZif file with leap seconds and with daylight saving time transitions projected into the indefinite future. For example, with TZ='America/Los_Angeles' with leap seconds, zdump formerly reported a DST transition on 2038-03-14 from 01:59:32.999... to 02:59:33 instead of the correct transition from 01:59:59.999... to 03:00:00. zic -L now supports an Expires line in the leapseconds file, and truncates the TZif output accordingly. This propagates leap second expiration information into the TZif file, and avoids the abovementioned localtime.c bug as well as similar bugs present in many client implementations. If no Expires line is present, zic -L instead truncates the TZif output based on the #expires comment present in leapseconds files distributed by tzdb 2018f and later; however, this usage is obsolescent. For now, the distributed leapseconds file has an Expires line that is commented out, so that the file can be fed to older versions of zic which ignore the commented-out line. Future tzdb distributions are planned to contain a leapseconds file with an Expires line. The configuration macros HAVE_TZNAME and USG_COMPAT should now be set to 1 if the system library supports the feature, and 2 if not. As before, these macros are nonzero if tzcode should support the feature, zero otherwise. The configuration macro ALTZONE now has the same values with the same meaning as HAVE_TZNAME and USG_COMPAT. The code's defense against CRLF in leap-seconds.list is now portable to POSIX awk. (Problem reported by Deborah Goldsmith.) Although the undocumented tzsetwall function is not changed in this release, it is now deprecated in preparation for removal in future releases. Due to POSIX requirements, tzsetwall has not worked for some time. Any code that uses it should instead use tzalloc(NULL) or, if portability trumps thread-safety, should unset the TZ environment variable. Changes to commentary The Îles-de-la-Madeleine and the Listuguj reserve are noted as following America/Halifax, and comments about Yukon's "south" and "north" have been corrected to say "east" and "west". (Thanks to Jeffery Nichols.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020a.tar.lz As usual, links to the latest release files are here: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 7aec41a1d9b57c581af086db5de5bf99b165c405 dated 2020-04-23 16:03:47 -0700 and tagged '2020a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 5235d6590e844491df32375857f5f36ba0046f2d21a078375188dff79b125cf9b69136a0a431624de1ecfa9d53b62a232f0e6ee0b734294cec62b670e6265cb2 tzcode2020a.tar.gz 2a2fc2e3ad8a6e4c574242296c847ad582c2c1d86add9c556e65c812d19b9528522e3c4dddb5239017091825d2acc5a2ccaf21dc41b900b6c300ef4264cc5a9d tzdata2020a.tar.gz 6ef3ed39ee379adce421e7964ce9cf3d36361e2ba29de78e43b36d524c5722fd151c11ac60c952130d2623ecea9d8b56b4652f394e60a893a76d2ad769072d9d tzdb-2020a.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl6iH9IACgkQ7ZfpDmKq fjQK6BAAgxpJVrK35eNuGheX51np4f7mOAomDzMqXSaYZqYLW2EZCa+JW6VWfrEm eMZYVA/U33WsIGTjyyjfmq5FVwIQj0An+mAtlOR5dd34/ikGddZjd28ChrMW9+56 VFS7dA2pUjMzQp7yGG5sVek5OeGaHajfwxzBptPrsK+JwyNC1RcGetEcrgUwwznX S1iiLFvfzgVhrqnYzthIuoUikLSUkNumkr4/8frsYwywQ0axAzpkLi5rWxOfZAi6 a1MLMXvKmzXeiNCu5oeKl2XfTymBUVyF7K3dzFdkrOto8pSTDR+BbSh88mbe7tct Rt0q/GRq8fityECzdVAzoAqCRUU97t8V4VHNFXSxy32CN99cjsLdRMiVVEGTq+TT A3m9FjQidSCP3apzQe9JDfj536gQFSkUmDlcFwya31zolRoWkIFmxIhmZWIYlm9T Wjqc7y7UnrBNvyDE4pemQ4YYHjk5YLjwoaUIafDJTAiDRfcf53SRlr3tbFcYjAt/ Tql77DWuLmg8PGFtRiyCMqrehboGi0Eu3he2MmYtsJB2ZXFN0yZQmlvDen9fkt1k EqUkKjhHmVBb5WVS5pbl8mGLr1TFtnnedmLw4xULrDzsyJ5tsqzVnkl6Ga/eoIal lLIxpXrYqQLdHNtTpdmJkqZ/89++HDov9JR0uMzU8LxFwH6duQ4= =0y/R -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl6iH9MACgkQ7ZfpDmKq fjTb6g/+P/l6Nev5Zv8mUktnT6eNKohtgpNRyHd8nYV92wmTiDSzAArFy7oi5CVV /jMv8sbV1ssq/5rQ6HUQuMDPgEIO405gxmqRWMhE6UwUbRxxa+/HKGUJH0AHY6Dh 1UhVD7QA6fDovs84ip/WgTEZYcYApLr2A3IfC0rDqDo42DiSnErFQDvqRMJQkQS1 p2Pv7YtW/2NZ52wkfq75klSsjlXzlz6CzM5P3/YU/Hylj42sQdbdtbUAyQug3YpD QQ2PiZoP92iiGrcwkKXa5xvXJ6jEZCXqi7HbJKt8OW+XpZ/ZYbTZRq+JvMbTqkOL +XvVufo/pVASgv2V0ynzJu/XRiFUeJaecmEg6QiAiJ74UMTXSGFnK//R32M9dp29 B4p2X2jmW9qjCwjbjQXl1Yl5ddlSyvBk2Lk4s1repQ2t7kphZx2C8P2WyQYGeP7H nZDucfmWK4OSh8cINexBE8xyagmv1T8mC4qEQbVPva6JysaodNBcf9WkKMCgituP tbPsVekSmG1GyN2ixPtpY86Fzjr60mEg1UKqHZIagRmH4kjUwd1gINCJgONaZZxo c1VfBD8ZORBZfG27+V5ISotKrK2UrKtcrSUEU1CC/ibOm1sSPfg0d5uxUVvg4E8+ okdszbMnQ1i0eVKW+L+jY5XOO8kmSLp4YcnrqXDyZabxyWIGMt4= =7U2J -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl6iH9QACgkQ7ZfpDmKq fjTDQQ//S8WK8/aBHCKOiNvNFL82SHsrwSzsMt/5AyWzTUgkZZdhuhPmCu/qim0M J6Gm+1XUPaq6WKQnHbNk4wrmKjlRX/R1DWIA+2FhVH0iFSAX+qrnc/KUkm0hVXg4 u8aylAUOQvdhDfVX4PafCx21Kf1sk46oleRgi5lr3cSPAIKGsiEQKGR5EMbt/8mt 55zpxYGTj4o8yjY4NqEOBD8SHts0BO0xFq2eh6C71KeTeHKm/SasIFbvhIZug2cO YQyAnBiybfsSwIPXfYZr9ux81BztdzkzS6n1EBgGrHmk/+xrpBbmaknjFDMu+Nln qOPnTQCmp3NBXOYeVnxMAgIy07yEcAR7ReV0FuJFaxrkGYstfV6k5ylhk1iuHnIZ dOPSJa4eD+cIPWJTo0AsOkNx8+xJ6DkP8iudCpGUrEmXFSoMuFr8b5QwOxsRF/eC oIIRVO35gF12xr424DVKE72Z8yELoDGXzfWh8UbY/j0Lasq6RXqF9mrCMrugxlwx 1GofM2zrIkzkgLfMoV5zJfKrPiLPj213uGmrctJNcSggtSEA0DBvSvuhVe8hzolZ /taWc+/gCPBv159s3qedQyQbfHY0/IIkePdezwn4f7DQvh7MTOteE81AwJvqtkmQ fhSp+hz9k5m4CKuY9+71p+Srefc0i8PsBpmVCDYUn6PFqXaXsiA= =dCQ0 -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, this release's data entries can be turned into a rearguard-format tarball that does not use these features. This is intended to be a temporary transition aid for these parsers. To generate a rearguard-format tarball, obtain the full distribution as described above, and run the command 'make rearguard_tarballs' on a development host. Or you can run 'make rearguard.zi' to generate a single file that can be fed directly to a parser that works like 'zic'.

1 0

Deprecating tzsetwall
by Paul Eggert April 22, 2020

April 22, 2020

In reviewing the tzdb web pages for bad links and suchlike, I noticed that they're still talking about UNIX SVR2 (superseded since 1988) and tzsetwall. So I looked into tzcode's implementation of tzsetwall, and noticed that it does nothing useful because functions like localtime now call tzset (as POSIX has require for many years), thus undoing tzsetwall's effect. Since nobody evidently cares whether tzsetwall works, we should remove it. Not right away of course, but we can document it as deprecated now without changing the implementation, and remove it in a future tzcode release. So I installed the attached patch to do that. Comments welcome as usual.

4 4