June 2020 - tz - lists.iana.org

Italy April 1944 discrepancy between comment and data
by Alois Treindl Oct. 5, 2021

Oct. 5, 2021

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

FW: [Ext] The TZ Coordination
by Naela Sarras April 2, 2021

April 2, 2021

Dear Paul, Please see the note below from our colleagues in Morocco regarding the upcoming timezone change for Morocco. Best regards, Naela Naela Sarras Director, IANA Operations ICANN From: EL MAAYATI Afaf <afaf(a)anrt.ma> Date: Wednesday, May 27, 2020 at 12:01 PM To: Naela Sarras <naela.sarras(a)iana.org> Cc: BENLEMLIH Hamida <benlemlih(a)anrt.ma> Subject: [Ext] The TZ Coordination Dear Naela, I hope this email finds you well, safe and healthy. Actually, I have a request concerning the configuration of the Time-Zone for Morocco. In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it’s mentionned that a program will be running to implement the transition dates: [cid:image001.jpg@01D6342E.01C70B10] Currently we are implementing GMT and we will move to GMT+1 next Sunday, May 31. So, if possible, would you please help to get in touch with Mr. Paul Eggert, in order to have the procedure to notify IANA officially, from a governmental source, with the changes of TZ in Morocco. Thank you in advance for your feedback and for your habitual support. Best Regards, Afaf ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.

9 16

DST changes in Hungary (full historical revision)
by Nyáry Géza Oct. 12, 2020

Oct. 12, 2020

Dear Paul! I examined it all of the Hungary daylight saving time changes. More differences I found what I repaired and I prepared it it source file, which I attach to this letter. I used Library Hungarica online database as a source, where from scanned contemporary ministerial decrees, instructions, newspapers and from other documents it was possible to find the time of the changes concerning the years. https://library.hungaricana.hu I checked the modified changes many times and I considered it right. If it's possible, I ask the exchange the attached modified Hungarian section in global database! Thank you very much! Bets regards, Géza Nyáry

5 11

Removing systemv, pacificnew, Rule TYPEs, zic -y
by Tim Parenti Oct. 4, 2020

Oct. 4, 2020

I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references. Of course, I was only looking at systemv in the first place because I'd also recalled that we're still distributing the pacificnew file, which has caused some confusion every so often and has likewise generally outlived its usefulness. This led me to the related file yearistype.sh, which is also unused, except as a default script to pass to the Makefile to process the TYPE field of Rule lines. Given that the TYPE field hasn't been used by tzdata since 2000f and has been more formally deprecated since 2015f, the whole unused feature is ripe for "spring cleaning". The attached proposed patch 0002 completely drops support for the TYPE field (marking it reserved for compatibility purposes) and causes non-trivial use of the field or use of zic's -y option to error (instead of warning as it has since 2017c). It also removes the pacificnew and yearistype.sh files that are no longer needed and updates documentation accordingly. I don't presently foresee any need to repurpose the nullified field down the road, but this is the next step in allowing us to "reclaim" it in the event that such a need should arise in the future. -- Tim Parenti

3 3

Updating zic.c to further match Link line field names
by Tim Parenti Oct. 3, 2020

Oct. 3, 2020

In working on my latest proposed patch, I also noticed an outdated error message in zic.c which referred to the FROM field of a Link line. We had updated these field names in comments and documentation in release 2014g to be more descriptive and readily understandable like the parameters of 'ln': https://github.com/eggert/tz/commit/78e3924ea43079a0f3333677a728e0f0ed679cd3 The attached proposed patch further updates the zic.c code to more consistently use these new names throughout. This mostly affects the naming of parameters and locals, but a few macros and struct fields are also updated for consistency. -- Tim Parenti

1 1

Re: [tz] Fwd: DST changes in Hungary (full historical revision)
by Paul Eggert July 25, 2020

July 25, 2020

Thanks for those corrections. I installed the attached patch to the development database on GitHub. It's not exactly what you emailed me, but it should generate equivalent transitions. It'd help if we could list citations for the transitions; are URLs available for each decree etc. that you consulted? We could add them as comments. Thanks again.

9 33

Tim Parenti as backup TZ Coordinator?
by Paul Eggert July 9, 2020

July 9, 2020

Tim Parenti's recent emails to the list reminded me that I'd long been meaning to nominate him to be my backup as TZ Coordinator. We should have a backup in case I am no longer available due to retirement or whatever, not that I'm planning to retire any time soon. I would like to start by giving him commit privileges to the development repository on GitHub, so that his contributions can become part of releases more easily. Tim has been a longtime and substantial contributor to tzdb, as evidenced by his detailed and careful patches. Although he's mostly worked in the tzdata area, he's also proficient on the code side, as his recent patch proposals demonstrate. He and I have corresponded by email about this and he's indicated his willingness to take on the responsibility. I'd appreciate reactions to Tim's offer to be backup; please respond within the next week.

12 13

North Vietnam 1970 to 1975 - Asia/Hanoi belongs into main file
by Alois Treindl July 2, 2020

July 2, 2020

(Corrected subject line) The backzone file contains the zone Asia/Hanoi It should go into the main file for Asia. There exists no doubt that in all of what was North Vietnam between at least 1970 and 1975 the timezone was 7h east, and not 8h east as in South Vietnam. There may be unclear borders, but most of North Vietnam, including its capital, was not unclear at all. I find it a discrimination of former North Vietnam to not have it represented correctly, at least for the post-1970 period. What Paul Eggert writes in the comments is a poor excuse. From Paul Eggert (2019-02-19): # # The Ho Chi Minh entry suffices for most purposes as it agrees with all of # Vietnam since 1975-06-13. Presumably clocks often changed in south Vietnam # in the early 1970s as locations changed hands during the war; however the # details are unknown and would likely be too voluminous for this database. # # For timestamps in north Vietnam back to 1970 (the tzdb cutoff), # use Asia/Bangkok; see the VN entries in the file zone1970.tab. # For timestamps before 1970, see Asia/Hanoi in the file 'backzone'.

6 14

Re: [tz] Mirmalek on Martian timekeeping
by Paul Eggert June 30, 2020

June 30, 2020

On 6/30/20 2:00 AM, BASTIAN Michelle wrote: > I wondered if you had come across this ethnography of mars working time https://brill.com/view/journals/kron/8/2/article-p159_7.xml?language=en No, I wasn't familiar with Mirmalek's work. I see she turned it into a book published in March. Thanks for the heads-up. I updated theory.html's discussion of Martian timekeeping based on the info you sent, and installed the attached patch. This patch also changes some tenses in the text, as the Mars Exploration Rover mission's second rover bit the dust in 2018 (literally: communications cut off during a planetwide dust storm).

1 0

re SPDX, I'll do the work, if you'll use the tag
by Mark Atwood June 30, 2020

June 30, 2020

I was tagged in to this list because of the discussion about SPDX license tagging. I sit on the SPDX committee (which doesn't mean much, it's similar to an IETF WG, in that anyone who joins the list, joins the calls, and then does needed work is "on the committee"). It may be useful to have an SPDX tag for the TZ database data files. The SPDX makes nearly zero legal assessment about a license. Applying an SPDX tag to an existing project is intended to document reality in a machine readable way, it is not intended to change reality. Having an SPDX tag is mostly for the benefit of systems and companies who are trying to be scrupulously correct when complying with open source licenses. When the SPDX evaluates a license, the things looked for are "does/will it have real users?", "does it have a stable enough text that the matching tools can correctly identify it?", and "is it for content intended for mostly uncontrolled distribution?". We very much do not get into all the arguments about "is this well defined in europe", "is this a license or a public domain declaration", "is copyright even appropriate", "copyleft is theft", etc etc etc. We don't practice law, and we don't want to dictate policy, we just id licenses for people who just want to know they are doing the right thing when using your files, and make suggestions for projects that want to write a policy about it. Looking at the TZ database history, it has a very long history with lots of contributors, its mostly just a collection of facts, it appears to be a public domain declaration, that started out kind of adhoc. Using one of the existing PD declarations in the SPDX database would not be appropriate, because of the need to get the past contributors to assent, lots of work for no value. What does make sense is creating a new tag, something like "TZ-PD". Then you can start putting "# SDPX-License-Identifier: TZ-PD" in your database text source file, and make life easier for a bunch of people who just want to do the right thing with your data. To repeat, adding that SPDX license tag of a new identifer to id an existing stable in the field declaration, like this, does not change any legal obligations or expose anyone to any new legal risks. It's just a machine readable way of saying what's already been said about the copyright status of the TZ database. So, I'm willing to volunteer to do that lift for the TZ community, if you are willing to use the resulting id tag. What say you? ..m Mark Atwood <mark.atwood(a)gmail.com> https://keybase.io/fallenpegasus +1-206-604-2198

4 3

North Vietnam 1970 to 1970 - Asia/Hanoi belongs into main file
by Alois Treindl June 28, 2020

June 28, 2020

The backzone file contains the zone Asia/Hanoi It should go into the main file for Asia. There exists no doubt that in all of what was North Vietnam between at least 1970 and 1975 the timezone was 7h east, and not 8h east as in South Vietnam. There may be unclear borders, but most of North Vietnam, including its capital, was not unclear at all. I find it a discrimination of former North Vietnam to not have it represented correctly, at least for the post-1970 period. What Paul Eggert writes in the comments is a poor excuse. From Paul Eggert (2019-02-19): # # The Ho Chi Minh entry suffices for most purposes as it agrees with all of # Vietnam since 1975-06-13. Presumably clocks often changed in south Vietnam # in the early 1970s as locations changed hands during the war; however the # details are unknown and would likely be too voluminous for this database. # # For timestamps in north Vietnam back to 1970 (the tzdb cutoff), # use Asia/Bangkok; see the VN entries in the file zone1970.tab. # For timestamps before 1970, see Asia/Hanoi in the file 'backzone'.

1 0

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