- tz - lists.iana.org

[PATCH 1/4] Simplify tzselect by omitting old Bash workaround
by Paul Eggert Dec. 13, 2021

Dec. 13, 2021

* tzselect.ksh (doselect): Omit Bash 1.14.7 workaround that I wrote in September 1996, as Bash 1.14.7 hasn’t been supported for years and surely should not be used anyway for security reasons. Bash 2.0 came out in December 1996. --- tzselect.ksh | 8 -------- 1 file changed, 8 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 18fce27..832cf75 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -101,14 +101,6 @@ then esac done || exit } - - # Work around a bug in bash 1.14.7 and earlier, where $PS3 is sent to stdout. - case $BASH_VERSION in - [01].*) - case `echo 1 | (select x in x; do break; done) 2>/dev/null` in - ?*) PS3= - esac - esac ' else doselect() { -- 2.32.0

1 3

Anniversary
by Arthur David Olson Dec. 13, 2021

Dec. 13, 2021

Discussion at an online meeting today made me realize that, alas, we missed the recent 35th anniversary of the start of the time zone mailing list. Put 2026-11-25 on your calendars now.-) https://mm.icann.org/pipermail/tz/1986-November/008946.html @dashdashado

5 5

[PROPOSED] Distribute tarballs in ustar rather than gnu form
by Paul Eggert Dec. 13, 2021

Dec. 13, 2021

It recently came to my attention that tzdb tarballs are not generated in standard POSIX ustar format, but instead use a trivially different but nonstandard format. Fix this by switching to the standard format. * Makefile (GNUTARFLAGS): Add --format=ustar. * NEWS: Document the change. --- Makefile | 3 ++- NEWS | 10 ++++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c89c1be..fd312d9 100644 --- a/Makefile +++ b/Makefile @@ -466,7 +466,8 @@ OK_LINE= '^'$(OK_CHAR)'*$$' # Flags to give 'tar' when making a distribution. # Try to use flags appropriate for GNU tar. -GNUTARFLAGS= --numeric-owner --owner=0 --group=0 --mode=go+u,go-w --sort=name +GNUTARFLAGS= --format=ustar --numeric-owner --owner=0 --group=0 \ + --mode=go+u,go-w --sort=name TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ then echo $(GNUTARFLAGS); \ else :; \ diff --git a/NEWS b/NEWS index 572a161..edb9a1d 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,16 @@ Unreleased, experimental changes reader no longer mistakenly attempts to parse a version 1 TZIf file header as a TZ string. + Changes to build procedure + + Distribution tarballs now use standard POSIX.1-1988 ustar format + instead of GNU format. Although the formats are almost identical + for these tarballs, ustar headers' magic fields contain "ustar" + instead of "ustar ", and their version fields contain "00" instead + of " ". For details about ustar format, please see + "pax - portable archive interchange", IEEE Std 1003.1-2017, + <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. + Changes affecting documentation and commentary Rename CONTRIBUTING to CONTRIBUTING.md and use Markdown format. -- 2.32.0

1 0

.UA uses both kiev.ua and kyiv.ua, sebastopol.ua, uzhgorod.ua
by Brian Inglis Dec. 11, 2021

Dec. 11, 2021

...and other spellings for backward compatibility and convenience e.g. odessa.ua, sebastopol.ua with sevastopol.ua reserved, uzhgorod.ua (no mention of uzhhorod.ua even as reserved); from: https://hostmaster.ua/2ld/ referenced by the Public Suffix List package. Headings translated: Public domains second level =========================== Thematic domains ---------------- com.ua in.ua org.ua net.ua Specialty domains ----------------- edu.ua gov.ua Geographical domains -------------------- cherkassy.ua cherkasy.ua ck.ua chernigov.ua chernihiv.ua cn.ua chernovtsy.ua chernivtsi.ua cv.ua crimea.ua dnepropetrovsk.ua dnipropetrovsk.ua dp.ua donetsk.ua dn.ua ivano-frankivsk.ua if.ua kharkov.ua kh.ua kharkiv.ua kherson.ua ks.ua khmelnitskiy.ua km.ua kiev.ua kyiv.ua kirovograd.ua kr.ua lugansk.ua lg.ua lutsk.ua lt.ua volyn.ua lviv.ua nikolaev.ua mk.ua odessa.ua od.ua odesa.ua poltava.ua pl.ua rovno.ua rivne.ua rv.ua sebastopol.ua sumy.ua sm.ua ternopil.ua te.ua uzhgorod.ua uz.ua vinnica.ua vn.ua yalta.ua zaporizhzhe.ua zp.ua zhitomir.ua zt.ua Reserved domain names --------------------- cr.ua khmelnytskyi.ua kropyvnytskyi.ua krym.ua kv.ua lv.ua mykolaiv.ua sb.ua sevastopol.ua sicheslav.ua vinnytsia.ua zaporizhzhia.ua zhytomyr.ua Technological domains --------------------- admin.ua ipv6.ua ns.ua ua.ua www.ua xn--mqa.ua dnssec.ua rdap.ua epp1.ua epp2.ua This documents that proposed alternative English spellings may be neither as common nor the issue as settled as the trolls claim. -- 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 binary units and prefixes, physical quantities in SI.]

1 0

Israel DST: Proposed Change of Start of DST
by Ephraim Silverberg Dec. 5, 2021

Dec. 5, 2021

The Minister of Interior, Ayelet Shaked, is proposing to change the Time Law so that DST will start in Israel at 2 a.m. on the *Friday *before the *second *Sunday of March. DST starts, according to the current law, at 2 a.m. on the Friday before the *last* Sunday in March. The proposed change has yet to be brought before the Knesset. I will endeavour to update the list if the proposed change receives Knesset approval.

2 2

America/SaoPaulo TZ still observing DST
by William Renan Santos (DHL Supply Chain) Dec. 4, 2021

Dec. 4, 2021

Hi, In Brazil the DST was revoked few years ago by government, but looks like the systems are still considering the DST change. I ran the tzupdater using latest file of tzdata and the systems are still considering 1 hour ahead in Sao Paulo. Could you please help me to review and point where in the tzdata file the DST for Brazil was removed? Thanks! William Santos LATAM - IT Products Sr Systems Analyst DHL Supply Chain Estrada da Cruz Grande, 1700 Louveira - SP ZipCode: 13290-000 Brazil Telephone: +55 19 3848 9377 william.r.santos(a)dhl.com<mailto:william.r.santos@dhl.com> www.dhl.com/supplychain<http://www.dhl.com/supplychain> DHL Supply Chain - Excellence. Simply delivered. [top_em]

3 2

Proposal: Sections for different kinds of backward links
by Stephen Colebourne Nov. 18, 2021

Nov. 18, 2021

I have taken a stab at splitting the `backward` file into sections. This is based on repeated observations made by multiple people that the file represents different kinds of Link. https://github.com/eggert/tz/pull/33 The sections I'm suggesting are: CROSS-ISO - These link across an ISO-3166 boundary EXCESS - These were added despite the locations having the same timekeeping since 1970 RENAMED - These are simple aliases/renames OBSOLETE - These are the most obsolete form of IDs FIXED - These are alternate names for fixed offsets I don't expect this PR to be merged as is - There will probably need to be some consideration as to the correct split, and as to whether each ID is in the correct section. The approach I've used is commented sections with stable section names. Alternate approaches to this problem are possible. For example, a new file could be created for each section. That seems to be more disruptive than the proposed approach. Note that in order for this change to be useful, the section names need to be considered part of the source file API, and maintained over time. thanks Stephen

5 16

Re: [tz] tz Digest, Vol 122, Issue 22
by nadir altinbas Nov. 14, 2021

Nov. 14, 2021

@ Comment; Time(Winter-summer) setting discussions in Turkey and research about it (Alan Mintz) May I remind to Alan Mintz ;On the "en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_population" list shows that Turkey is in Asia, One of the region where is called as Marmara region is in Europe . Turkey is in both of Asia and Europe. Coordinates for Turkey as follows; ------------------------------------------- Latitude: 38° 57' 26.43" N Longitude: 35° 14' 26.67" E ------------------------------------------ also in GPS DD coordinate; 38.9573415 35.240741 ----------------------------------------- Nadir Altinbas nadiraltinbas(a)yahoo.com n.altinbas On Sunday, November 14, 2021, 05:27:55 PM GMT+3, tz-request(a)iana.org <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. Re: Time(Winter-summer) setting discussions in Turkey and research about it (nadir altinbas) 2. Re: Time(Winter-summer) setting discussions in Turkey and research about it (Alan Mintz) ---------------------------------------------------------------------- Message: 1 Date: Sat, 13 Nov 2021 15:36:25 +0000 (UTC) From: nadir altinbas <nadiraltinbas(a)yahoo.com> To: Paul Eggert <eggert(a)cs.ucla.edu> Cc: Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Time(Winter-summer) setting discussions in Turkey and research about it Message-ID: <2020539311.1385787.1636817785458(a)mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Ok ! Paul, Thanks,wikipedia correction explanation was better. Nadir Altinbas n.altinbas On Saturday, November 13, 2021, 11:15:33 AM GMT+3, Paul Eggert <eggert(a)cs.ucla.edu> wrote: Thanks for the heads-up. If Turkey actually changes its time zones or daylight-saving rules please let us know. I hope they give us plenty of warning (such as a year or more); otherwise, their cell phones and/or computers will likely be off. One minor point. The text says "Saatlerini de?i?tirmeyen en b?y?k ?lkeler ?in, Hindistan ve Japonya" which Google translates as "The largest countries that do not change their clocks are China, India and Japan." Using the Wikipedia list of countries by population[1], the ten most populous countries that do not observe daylight saving time are China, India, Indonesia, Pakistan, Brazil, Nigeria, Bangladesh, Russia, Japan, and Ethiopia, in that order. [1] https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_populat… ------------------------------ Message: 2 Date: Sat, 13 Nov 2021 10:48:15 -0800 From: Alan Mintz <alan.mintz(a)gmail.com> To: Paul Eggert <eggert(a)cs.ucla.edu> Cc: Time Zone Mailing List <tz(a)iana.org>, nadir altinbas <nadiraltinbas(a)yahoo.com> Subject: Re: [tz] Time(Winter-summer) setting discussions in Turkey and research about it Message-ID: <CAMLM5-Vkqs_k7HkGy+MPwWGcjAUzRXhu4OOkAdFywvy-Ppj5rw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Sat, Nov 13, 2021 at 12:15 AM Paul Eggert via tz <tz(a)iana.org> wrote: > ... Using the Wikipedia list of countries by population[1], the ten > most populous countries that do not observe daylight saving time are > China, India, Indonesia, Pakistan, Brazil, Nigeria, Bangladesh, Russia, > Japan, and Ethiopia, in that order. > > [1] > > https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_populat… > Kind of a misleading statistic, though, since Indonesia straddles the equator and much of Brazil, Nigeria, and Ethiopia are within 15 degrees latitude, making DST unnecessary for them. -- Alan Mintz <Alan.Mintz(a)gMail.com>

1 0

Time(Winter-summer) setting discussions in Turkey and research about it
by nadir altinbas Nov. 13, 2021

Nov. 13, 2021

Thank You Paul! Resending e -mail message as plain Text as follows.Amendment e -mail; GMT+2.30 adviced by Turkeys Electrical Engineers Society (TMMOB-EMO) for eficiently enery usage in the country, on the news dealing with conflict while settings winter and summer time through organization. here is the link about news as Turkish; (www.emo.org.tr/genel/bizden_detay.php?kod=136372&tipi=5&sube=0) There also mentioned a research by ITU (Istanbul technical University research about time arrangement. These are just discussions and advice not officially anouncment. nadiraltinbas(a)yahoo.com Nadir Altinbas n.altinbas

3 3

Tİme zone discussions in Turkey and research about it
by nadir altinbas Nov. 12, 2021

Nov. 12, 2021

For GMT +2.30 adviced from Turkey's Electrical Engineers Society (TMMOB-EMO) reported on Social mediato efficient energy usage in Turkey. news here on the link as follows;EMO - SAATLERE AYAR ARANIYOR (OKSİJEN) | | | | | | | | | | | EMO - SAATLERE AYAR ARANIYOR (OKSİJEN) | | | This research is not official now.It may be considered future plan nadiraltinbas(a)yahoo.com n.altinbas

1 0

Pre-1970 data
by Stephen Colebourne Nov. 12, 2021

Nov. 12, 2021

How can this project successfully handle pre-1970 data? Why have I focussed so much on IDs and their value to tzdb? Intro ------- In previous threads I've focussed on IDs, and laid out different ways to describe the groups of IDs we have. For now, lets focus solely on the two main groups - region IDs, which represent abstract regions where clocks have been the same since 1970 - non-region IDs, which represent locations where tzdb has, at some point, added an ID The key observation is that the segregation between these two groups of IDs *did not exist* until around 2014. It was only in 2018 that the ISO country rule was removed. It has only been since 2014 or so that IDs have been merged. What tzdb previously offered was a set of IDs, based on a simple rule - "ID as needed for post-1970 data, with at least one per ISO country". Full history was available for each of these (whether accurate or not). What has happened since is a split, where no split previously existed. A split which favours some locations over others. The recent mailing list debates merely represent the cumulation of this favouritism. The irony is that the merges are being done in the name of equity and fairness, when the outcome has actually been the exact opposite - picking favourites, and denigrating everywhere else. That the approach to picking favourites is according to a standardised largest city rule isn't really that relevant here - it is the outcome that is unfair, not the process. If region IDs were of different appearance (eg. numeric or textually different) then the issues would not have arisen. The mistake was taking a fully functional and fully integral set of IDs, and bifurcating it into two groups. The split was actually a huge change in the policy of tzdb, which has been added drip by drip, rather than something that was ever fully appreciated up front. FWIW, it is clear to me that there is an aspect of imposing a US-centric timezone system on other parts of the world. The recent tzdb approach of focussing entirely on timezone regions makes perfect sense for the US, where region boundaries do not follow state lines, and ordinary members of the public need to be aware of whether they are in US/Mountain or US/Central. This simply isn't the timezone model in many other parts of the world. In places like Europe and Asia, the timezone is driven primarily by the country you live in - an ordinary member of the public in Iceland is never going to associate with some abstract timezone region stretching down the Atlantic that is not named, not legally defined and is little more than a random outcome based on tzdb's choice of 1970. Even in somewhere like Norway, an ordinary member of the public will understand that although they follow CET, their timezone is actually driven by their Government in Oslo. The brilliance of the original rule - "ID as needed for post-1970 data, with at least one per ISO country" - was that it seamlessly handled *both* models of timezone in one unified set of IDs. Removal of the ISO country part has completely destabilised that balance. As a constraint to this thread, tzdb really needs to offer one standard view of data, not command line flags that allow different views. If downstream projects end up with different views of the data, it makes tzdb a much less reliable source. (tzdb can be packaged in different ways on the same machine, for example it is undesirable for Postgres' internal tzdb and the OS tzdb to diverge for the same version). Given this, what needs to be nailed down is what is the default data set that tzdb publishes - there isn't really much point in talking about compile time flags, or that the contents of backzone could be used by someone. Lets look at seven options for pre-1970 data: Pre-1970 data for regions only ----------------------------------------- 1) Pre-1970 data for regions only - Despite looking identical to other IDs, region IDs are treated as special/favoured - Pre-1970 data for non-region IDs is of no importance whatsoever, thus most get pre-1970 data from another country/continent - The split between region and non-region locations is fully completed - the US-centric timezone model is dominant - An end user in Iceland is supposed to use Africa/Abidjan, Europe/Reykjavik is treated as a historical mistake of tzdb kept around only for backwards compatibility Pre-1970 data for most IDs ------------------------------------ 2) Pre-1970 data for each ID meeting the rule "ID as needed for post-1970 data, with at least one per ISO country" - The split between region and non-region locations is healed - High quality data from places like Iceland and Norway is retained, but low quality data from elsewhere is restored - The pre-1970 data is simply viewed as the best available data for the each location which can be improved over time - Most end-users in Iceland would expect tzdb to provide pre-1970 data from Iceland, not the Ivory Coast 3) Pre-1970 data for for all IDs that currently exist except true aliases - This is very similar to #2, but would include something like Montreal which was effectively mistakenly added to tzdb - This doesn't seem as desirable as #2 4) Pre-1970 data for any ID where the pre-1970 data is high quality - Subjective on quality, which doesn't seem like a great idea - It does avoid bringing bad quality data back into the main tzdb distribution - On balance, #2 has fewer places for debate to arise 5) Pre-1970 data for all IDs that currently exist except true aliases, plus a *new* set of IDs representing regions - As per #2, but adding IDs like "Region/12345" or "Region/Berlin" - Regions should contain post-1970 data only, as the region is by definition only meaningful post-1970 - It is not entirely clear what this solves over just going with #2 - This option is connected to Russ' proposals [1], although he suggests a bigger split between timekeeping data and ID naming - Perhaps it makes sense if the new region IDs were internal and not normally seen by end users? Remove pre-1970 data from general use ------------------------------------------------------- 6) No pre-1970 data whatsoever, all IDs are post-1970 only - Project policy is that tzdb is focussed on post-1970 data only - Paul repeatedly tells us that pre-1970 data is unreliable, and people shouldn't use it - Pre-1970 data would not be deleted, but would not be available in most downstreams - The split between region and non-region locations is effectively healed - End users lose access to pre-1970 data, which is particularly notable in some locations where that data is reliable, eg London - It is unknown at this point what the user impact is of removing pre-1970 data from major financial/business centres (no major location has yet been merged) 7) No existing IDs get pre-1970 data, but a *new* set of IDs are created containing it - As per #5, the existing IDs get no pre-1970 data and the split between region and non-region locations is healed - New IDs, such as "Historic/Europe/London" or "Historic/Africa/Abidjan" get created for each of the main IDs - The historic IDs include pre-1970 data, the standard IDs do not - There is a mechanical transformation between the historic and non-historic IDs - Whether downstreams do or do not include the historic IDs is their choice, potentially based on available space - The data provided by the standard non-historic IDs remains the same whether the downstream includes the historic IDs or not (a Good Thing) - Users have to deliberately opt-in to get pre-1970 data, which might make them think about the accuracy issue Notes -------- - I'm not discussing adding new IDs simply to represent locations whose clocks differ only before 1970. I don't personally think that is a job for tzdb, and even if it is, it is a job for a different thread. - I'm not discussing what value is returned prior to 1970 when pre-1970 data is removed. That would be a job for a different thread. - Link vs Zone is not important for this discussion. Summary ------------- After a few weeks of thinking, these are the options I've come up with. Feel free to suggest another option or variant if you think I've missed anything obvious. I believe that was a disaster that the brilliant "ID as needed for post-1970 data, with at least one per ISO country" rule was removed. It has created needless division, bifurcating a unified set of ID into region and non-region IDs and creating backwards compatibility issues in the data of many locations. IMO, there are two basic models of timezones in the world, and moving tzdb from one that supported both to one that only supports the US-centric model is simply a mistake that needs correcting. As such, my preference would be to adopt option 2. Option 6 or 7 could work, and might be the best choices if we had a clean slate or if there was some hidden pressure that the list is unaware of to remove pre-1970 data, but they are risky options given we do not know the impact on end-users in major financial/business centres. Stephen [1] https://mm.icann.org/pipermail/tz/2021-September/030518.html

23 59

The link-name, America/Virgin, is linked to two zones in 'backzone'
by Yan-Jie Wang Nov. 12, 2021

Nov. 12, 2021

A link-name (the second column of the Link line) in a file should be unique. However, 'America/Virgin' is linked to two zones (America/Port_of_Spain and America/St_Thomas) in 'backzone'. The error is in the latest commit as well as in the archive tzdata2021e.tar.gz. The link to the file: https://github.com/eggert/tz/blob/6c15079/backzone Yan-Jie Wang

2 1

Re: [tz] What are the interfaces to the TZDB?
by Brian Park Nov. 10, 2021

Nov. 10, 2021

(Replying back to the list with permission) On Tue, Nov 9, 2021 at 11:45 AM Eliot Lear <lear(a)lear.ch> wrote: > On 09.11.21 20:38, Brian Park wrote: > > Is the TZDB project intended to support only POSIX systems? > > It's a fair question. Before we say, “no”, I would like to understand > what sort systems use the database that themselves are *NOT* POSIX > compliant. But also, as Paul pointed out, the binary format itself is > standardized at the IETF, the sponsor of this shindig. > > We could go up the stack, but before we do so, we should be clear on our > reasons as to why we are doing so. And so when you say: > > My downstream usage does not have a file system, or even an operating > system. For me, the API into the TZDB project are the raw files, but I > understand that my usage is unusual. > > Would you mind being a bit more specific? Are you printing a book? ;-) > Not that primitive... My libraries run on bare-metal, embedded microcontrollers, with no operating system. My first version is in C++, supporting all Zones and Links in about 36kB of flash (8-bit controllers) to 44kB of flash (32-bit controllers), without using 64-bit integers. I have another version in Python that I hope to convert to MicroPython soon. I'm hoping to write another version in Go lang, which will be converted into TinyGo. Brian

2 1

Re: [tz] Pre-1970 data
by dpatte Nov. 5, 2021

Nov. 5, 2021

I was be contributing a longer message on this whole subject within a few days, but I want to state upfront that country/city is insufficient in many countries for a fully expandable location database.Off the top of my head, I can think of three different Richmonds in Canada. One in Quebec, one in Ontario, and one in BC. I know there are many Springfields in many USA states, and let's not even talk about the potential USA/Columbus.The key of a database should be unique and recognizable. For many countries, multiple levels of government are the only way to properly differentiate cities.Canada/British_Columbia/Richmond would be more appropriate.This allows the pre-1970 db to be both infinitely expandable, as well as user friendly to the point of being fully obvious to all users.Sent from my Galaxy -------- Original message --------From: Brian Park via tz <tz(a)iana.org> Date: 2021-11-05 11:27 (GMT-05:00) To: Philip Paeps <philip(a)trouble.is> Cc: Stephen Colebourne <scolebourne(a)joda.org>, Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Pre-1970 data On Thu, Nov 4, 2021 at 10:11 PM Philip Paeps <philip(a)trouble.is> wrote:On 2021-11-05 12:17:34 (+0800), Brian Park via tz wrote: > I get the impression that this debate is caused by the existence of 2 > different schools of thought: [...] > > I want to suggest that it may be possible for these 2 views to > coexist. They de facto coexist right now. The overwhelming majority of the data are descriptive. Only recent efforts have made some of the post-1970 data appear more prescriptive.They coexist in an ad hoc manner right now, and that seems to be one of the causes for the contention. I am suggesting that we formalize the separation, so that both groups are happier. > We > could create a new file, e.g. call it 'countryzone', which contains a > set > of Links organized in a hierarchical tree by country, pointing to the > Core > zones. I strongly believe we should continue to carefully avoid attempting to group data by country. [I would even avoid using the word "country" wherever possible.]Can you explain why? Because it will cause arguments about disputed places? I think only a small minority of places around the world are disputed. By separating these ISO-country timezones into a 'countryzone' file, perhaps we can confine the debate into a smaller section of the TZDB. We could create duplicate entries (i.e. Country1/City, Country2/City), or create a pseudo-country called "Disputed" (i.e. Disputed/City). The point is, we can create policies that govern these disputed regions.Could we move 'countryzone' into a separate project? Probably, but some amount of initial coordination and refactoring would be required to resolve conflicting zone identifiers.Overall, I feel like the TZDB data should lean a bit more towards matching how end-users think about timezones in the real world (Prescriptive), and lean slightly less on treating timezones as a clustering problem (Descriptive). But I can see pros and cons of both approaches. Which is why I am suggesting ways to make the 2 approaches interoperate better. > For the pre-1970 data, it is my understanding that the 'backzone' file > contains Zone records which should replace ONLY the LinkMerged records > found in the other files. I propose that all LinkMerged records be > extracted into a separate file (let's call it 'mergedzone') so that > there > is a clear symmetry between 'backzone' and 'mergedzone', which allows > them > to be substituted for each other. The dependency diagram looks > something > like this: As I've suggested before in another thread, I think we should consider undoing the split into backzone. I really liked Stephen's phrasing earlier in this thread: acceptably accurate, not outrageously wrong. We started moving data to backzone to limit the scope of 'active' maintenance to post-1970 data. That artificial split led us towards a more prescriptive worldview. It seems clear that prescriptive simply does not work for a real world with people on it.I think Paul Eggert has made it clear that he does not want to maintain this data. My proposed refactoring of this info into the 'backzone' / 'mergedzone' pair makes it easy for downstream libraries to add back the 'backzone' data if they want. The 'make PACKRATDATA=backzone' hack does not help downstream libraries which do not use TZif or the Makefile. > If there is any chance that this will result in being able to type > "Canada/Toronto" instead of "America/Toronto", that would resolve an > annoyance that has lasted some 30-35 years. In this context, America refers to the landmass, not to the political entity occupying a large chunk of it. [Canada/Eastern etc moved to backward around 1993, as far as I can tell.]Virtual no one in the world thinks of "America" as referring to all of "North America" and "South America".Brian

2 1

Ref: Tz on social media
by nadir altinbas Nov. 4, 2021

Nov. 4, 2021

is it possible to add 'news' from TZ Coordiation web site share button to social media such as; Linkedin,FaceBook(meta),Instagram,Twitteretc.... There may be occur an anouncment to publicize for sharing via social media? Nadir Altinbas Estanbul /TR, 2021 Nov,2 nadiraltinbas(a)yahoo.com n.altinbas

2 2

event of interest: Future of Europe debates – The end of DST: how can it be placed back to the European agenda?
by BASTIAN Michelle Oct. 28, 2021

Oct. 28, 2021

Hi all, I was just at events for the Barcelona Time Use initiative time use week 2021 and the panel on changing DST in Europe was very interesting and I thought some of you might want to take a look. It is free to sign up and you can access recordings of all the events including the one on time zones/DST. Description and link below. Loved that there was lots of talk about there being no problem having many more time zones in Europe as ‘our computers handle all of that for us now’. https://timeuseweek.beplanet.tv/en/ Future of Europe debates – The end of DST: how can it be placed back to the European agenda? In 2019, the European Parliament agreed to end the biannual clock change. Nevertheless, the Member States have not been able to achieve an agreement on which time zone has to be adopted. This debate explores how can we place back the debate on the European and Member States agenda. Representative of European Parliament Pending to confirm Maria Nikolopoulou European social and economic council Ticia Luengo International Association for Natural Time Till Roenneberg World Federation of Societies for Chronobiology Best, Michelle. --- Dr Michelle Bastian Mid-Career Fellow, Independent Social Research Foundation (Project info<https://www.isrf.org/fellows-projects/michelle-bastian/>) Senior Lecturer in Environmental Humanities ESALA, Edinburgh College of Art, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

3 2

Re: [tz] tzcode2021e: uninitialized variable in localtime.c
by Paul Eggert Oct. 27, 2021

Oct. 27, 2021

On 10/22/21 07:49, Christos Zoulas wrote: > My linter reports "prevcorr" is uninitialized in the if statement > below the comment that starts "To avoid other botches". Thanks for mentioning that. This prompted me to find an obscure bug in localtime that would cause it to access an uninitialized local variable (which is undefined behavior) in cases involving 32-bit time_t code reading malformed 64-bit data. I installed the attached patch to fix the bug, and I hope this also pacifies your linter.

2 1

[PROPOSED] Be more generous when dealing with v1 data
by Paul Eggert Oct. 27, 2021

Oct. 27, 2021

* NEWS: Mention this. * localtime.c (tzloadbody): In version 2 and later files, do not attempt to validate the version 1 header and data block; instead, ignore them except for the purpose of skipping over them, as per a recommendation in RFC 8536 section 4. Also, when the TZif file is version 1 and we break out near the end of the loop, do so only after altering nread and memmoving any later data; this avoids having later code attempt to parse the version 1 header as if it were a TZ string. --- NEWS | 6 +++++ localtime.c | 71 +++++++++++++++++++++++++++++++---------------------- 2 files changed, 47 insertions(+), 30 deletions(-) diff --git a/NEWS b/NEWS index d4a9823..0f684f7 100644 --- a/NEWS +++ b/NEWS @@ -14,6 +14,12 @@ Unreleased, experimental changes Fix bug when 32-bit time_t code reads malformed 64-bit TZif data. (Problem reported by Christos Zoulas.) + When reading a version 2 or later TZif file, the TZif reader now + validates the version 1 header and data block only enough to skip + over them, as recommended by RFC 8536 section 4. Also, the TZif + reader no longer mistakenly attempts to parse a version 1 TZIf + file header as a TZ string. + Release 2021e - 2021-10-21 18:41:00 -0700 diff --git a/localtime.c b/localtime.c index 6d736b2..39ef6e3 100644 --- a/localtime.c +++ b/localtime.c @@ -434,35 +434,45 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (close(fid) < 0) return errno; for (stored = 4; stored <= 8; stored *= 2) { - int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); - int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); - int_fast64_t prevtr = -1; - int_fast32_t prevcorr; - int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); - int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); - int_fast32_t typecnt = detzcode(up->tzhead.tzh_typecnt); - int_fast32_t charcnt = detzcode(up->tzhead.tzh_charcnt); - char const *p = up->buf + tzheadsize; - /* Although tzfile(5) currently requires typecnt to be nonzero, - support future formats that may allow zero typecnt - in files that have a TZ string and no transitions. */ - if (! (0 <= leapcnt && leapcnt < TZ_MAX_LEAPS - && 0 <= typecnt && typecnt < TZ_MAX_TYPES - && 0 <= timecnt && timecnt < TZ_MAX_TIMES - && 0 <= charcnt && charcnt < TZ_MAX_CHARS - && (ttisstdcnt == typecnt || ttisstdcnt == 0) - && (ttisutcnt == typecnt || ttisutcnt == 0))) - return EINVAL; - if (nread - < (tzheadsize /* struct tzhead */ - + timecnt * stored /* ats */ + char version = up->tzhead.tzh_version[0]; + bool skip_datablock = stored == 4 && version; + int_fast32_t datablock_size; + int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); + int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); + int_fast64_t prevtr = -1; + int_fast32_t prevcorr; + int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); + int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); + int_fast32_t typecnt = detzcode(up->tzhead.tzh_typecnt); + int_fast32_t charcnt = detzcode(up->tzhead.tzh_charcnt); + char const *p = up->buf + tzheadsize; + /* Although tzfile(5) currently requires typecnt to be nonzero, + support future formats that may allow zero typecnt + in files that have a TZ string and no transitions. */ + if (! (0 <= leapcnt && leapcnt < TZ_MAX_LEAPS + && 0 <= typecnt && typecnt < TZ_MAX_TYPES + && 0 <= timecnt && timecnt < TZ_MAX_TIMES + && 0 <= charcnt && charcnt < TZ_MAX_CHARS + && 0 <= ttisstdcnt && ttisstdcnt < TZ_MAX_TYPES + && 0 <= ttisutcnt && ttisutcnt < TZ_MAX_TYPES)) + return EINVAL; + datablock_size + = (timecnt * stored /* ats */ + timecnt /* types */ + typecnt * 6 /* ttinfos */ + charcnt /* chars */ + leapcnt * (stored + 4) /* lsinfos */ + ttisstdcnt /* ttisstds */ - + ttisutcnt)) /* ttisuts */ + + ttisutcnt); /* ttisuts */ + if (nread < tzheadsize + datablock_size) + return EINVAL; + if (skip_datablock) + p += datablock_size; + else { + if (! ((ttisstdcnt == typecnt || ttisstdcnt == 0) + && (ttisutcnt == typecnt || ttisutcnt == 0))) return EINVAL; + sp->leapcnt = leapcnt; sp->timecnt = timecnt; sp->typecnt = typecnt; @@ -578,13 +588,14 @@ tzloadbody(char const *name, struct state *sp, bool doextend, ttisp->tt_ttisut = *p++; } } - /* - ** If this is an old file, we're done. - */ - if (up->tzhead.tzh_version[0] == '\0') - break; - nread -= p - up->buf; - memmove(up->buf, p, nread); + } + + nread -= p - up->buf; + memmove(up->buf, p, nread); + + /* If this is an old file, we're done. */ + if (!version) + break; } if (doextend && nread > 2 && up->buf[0] == '\n' && up->buf[nread - 1] == '\n' && -- 2.31.1

1 0

Extra transition type is generated by zic with -r specified
by Almaz Mingaleev Oct. 26, 2021

Oct. 26, 2021

I’ve tried to generate a TZif file with transitions up to 1 Jan 2100 using zic with -r and “-b fat”. However, an extra transition type is generated for many (all?) time zones. That type’s UTC offset is zero and it is used only for the last transition in the 64-bit section. What I did: mkdir /tmp/zic cd /tmp/zic git clone https://github.com/eggert/tz.git . make -C . zic make -C . NDATA= rearguard.zi mkdir data ./zic -b fat -r /@4102444800 -d ./data rearguard.zi Below is an investigation for Australia/Lord_Howe (I don’t think choice matters here). I couldn’t find a way to force zdump to print transitions for a given TZif file. Instead, please see human-readable dumps from the TZif from our internal tools immediately below and raw byte information at the bottom if you’d prefer to work with that. These are local time transition types for Australia/Lord_Howe: Types gmtOffset (seconds),isDst,ttisgmt,ttisstd,[gmtOffset ISO],[DST?] 38180,0,,,PT10H36M20S,STD 0,0,,,PT0S,STD <- this is odd 36000,0,,,PT10H,STD 41400,1,,,PT11H30M,DST 37800,0,,,PT10H30M,STD 39600,1,,,PT11H,DST Transitions: transition,type,[UTC time],[Type offset],[Type isDST] … 4063275000,5,2098-10-04T15:30:00Z,PT11H,DST 4078998000,4,2099-04-04T15:00:00Z,PT10H30M,STD 4094724600,5,2099-10-03T15:30:00Z,PT11H,DST 4102444800,1,2100-01-01T00:00:00Z,PT0S,STD <- this is odd So, after the upper bound specified in -r, the transitions say that GMT is used. As I’d expect, the 32-bit transitions are not affected when the upper bound in -r is after 2038. However, with -r /@1634833073 the 32-bit section also has 6 transition types and the last transition sets offset to 0. Is that a bug or is there a reason for such behaviour? Thanks, Almaz Byte manipulations: typecnt is 5 in 32-bit section: xxd -seek 36(4+1+15+4*4) -len 4 data/Australia/Lord_Howe 64-bit section starts at offset 674. timecnt is 0xF0(=240) in 64-bit section: xxd -seek 706(674 + 20 + 3 * 4) -len 4 data/Australia/Lord_Howe typecnt is 6 in 64-bit section: xxd -seek 710(706 + 4) -len 4 data/Australia/Lord_Howe So, 64-bit header has one extra transition type. Let’s check how it is used and what that transition is: 2638 = 674 + 44 + 240 * 8 xxd -seek 2638 -len 240 -c 1 data/Australia/Lord_Howe prints transition types: 00000b38: 05 . 00000b39: 04 . 00000b3a: 05 . 00000b3b: 04 . 00000b3c: 05 . 00000b3d: 01 . Transition type is changing from 4 to 5, but the last one is 1. xxd -seek 2878 -len 36 -c 6 data/Australia/Lord_Howe prints local time type records: 00000b3e: 0000 9524 0004 ...$.. 00000b44: 0000 0000 0000 ...... <- the last transition type 00000b4a: 0000 8ca0 0008 ...... 00000b50: 0000 a1b8 010d ...... 00000b56: 0000 93a8 0013 ...... 00000b5c: 0000 9ab0 0119 ...... Which means that 1st type’s offset is 0 and that the last rule for Lord Howe is actually GMT.

2 4

[PROPOSED] Improve Palestine predictions for 2025 and later
by Paul Eggert Oct. 25, 2021

Oct. 25, 2021

* NEWS: Mention this. * asia (Palestine): Guess Fri>=23, not lastFri, for fallback transitions in the future. Fri>=23 is more consistent with past practice than lastFri. The first differing prediction is a fallback on 2025-10-24, not 2025-10-31. --- NEWS | 10 ++++++++++ asia | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index a7aa269..d83e01c 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,15 @@ News for the tz database +Unreleased, experimental changes + + Changes to future timestamps + + Predict Palestine fallbacks to be the first Friday on or after + October 23, not October's last Friday, to be more consistent with + past practice. The first differing prediction is a fallback on + 2025-10-24, not 2025-10-31. + + Release 2021e - 2021-10-21 18:41:00 -0700 Changes to future timestamps diff --git a/asia b/asia index dd228e5..6d6b1de 100644 --- a/asia +++ b/asia @@ -3445,7 +3445,7 @@ Rule Palestine 2019 only - Mar 29 0:00 1:00 S Rule Palestine 2019 only - Oct Sat>=24 0:00 0 - Rule Palestine 2020 max - Mar Sat>=24 0:00 1:00 S Rule Palestine 2020 only - Oct 24 1:00 0 - -Rule Palestine 2021 max - Oct lastFri 1:00 0 - +Rule Palestine 2021 max - Oct Fri>=23 1:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Gaza 2:17:52 - LMT 1900 Oct -- 2.31.1

3 3

Wrong name of timezone
by Igor Melnyk Oct. 25, 2021

Oct. 25, 2021

Hello! There is *Europe**/Kiev* timezone related to Ukraine. But Ukraine has the Ukrainian language and *Kiev* is in russian language. The correct name of the capital city of Ukraine is *Kyiv.* It must be changed. I know that it's not easy to do that but you must have some way to do that. For example, rename *Europe/Kiev* to *Europe/Kyiv* and make *Europe/Kiev* to be a temporary alias or link to *Europe/Kyiv.* What do you think about it? Best regards, Igor Melnyk.

1 0

Re: [tz] Palestine winter time
by Paul Eggert Oct. 22, 2021

Oct. 22, 2021

On 10/21/21 01:03, heba.hamad(a)mtit.gov.ps wrote: > Could you please confirm that Palestine winter time has been adopted in IANA time zone database Yes, tzdb release 2021e was published today with the updated Palestine winter time. The announcement is archived here: https://mm.icann.org/pipermail/tz-announce/2021-October/000069.html

2 2

[tz-announce] 2021e release of tz code and data available
by Paul Eggert via tz-announce Oct. 22, 2021

Oct. 22, 2021

The 2021e release of the tz code and data is available. This release reflects the following changes: Changes to future timestamps Palestine will fall back 10-29 (not 10-30) at 01:00. (Thanks to P Chan and Heba Hemad.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2021e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2021e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2021e.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: 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 b102002e5300d94c369796d5b70bae22b5af720d dated 2021-10-21 18:41:00 -0700 and tagged '2021e' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 87b0335129ea41c5f42f687f548712e5da892baa8494cecf5d34851beceecf6ae52f22104696ed187713cf9e502570eb2041e277dfd3c043c11d0253bfde685a tzcode2021e.tar.gz c1e8d04e049157ed5d4af0868855bbd75517e3d7e1db9c41d5283ff260109de46b6fac6be94828201d093e163d868044ac2a9db2bf0aeab800e264d0c73a9119 tzdata2021e.tar.gz 8abd662f07a91eed5b77d03eaa3e9ef59ce08b4e3fc14f9857095c3d4f2039e8ac216fc985b0cf87a823eacad064197c8ecb76ba531a9fc700014d7f0057aba8 tzdb-2021e.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFyF3cACgkQ7ZfpDmKq fjQKRw//c5HpFCN0vcPUIC/OQKTF/SXFOANCpHWypc/vgTVXFAsVu0zIKWdBuXXI 0zQDpbTcTJ2FfI5Z1JGNzeKa2G4Wy71lwwPu2mGDt0WCCAqh/l15XvgVEAM96YLG WZRK+WLKIVWgZ67NA2xWAt9VLgtA643Cgym1DCpsr9jTDAhGSYq8D0XC5OQHtfw2 oyzv4InTW+0EI14FQcQ3VqImLwGSefeYPfMBRjrAspqrTLez78vW914IWNKcgEoC pKCkq9+14u0L+G5j5E+f27gbRtZ4hZnIn5uNgItomJmGObW6khn0Huf+G6U1BAal 2zLSAYMubr1kq/6dP62QUivi1W2S3YRZDh20YsKxn214HW5qK5LdQKYruBGKOFou 7oAe91W3UW0vSJuboXj0Dbdc3p8Oay97eJ/kRDVKJZ95/UOQtwrkQi2wCbm19eC8 kvHdejbIrOvdl+ZpvkHIggQGSOchyXUASeqnX/9zirOAX0N05insC/ybJLAwepFm FqpvcfwjrJKCotAjFEEex1uIT5kgQwIumvtxLef3bGQgYtF1yfWMD0NSJAR1iAU2 BzXuikOLPNbHWpC41ODgRxBVaQnMpliC0WGJ/HiVT78ukEkx0MpcxyfnxjEDD7fz F3GlJlj/bw5rvsPrFzbSjYyzXfrn0u1y8/vgehUmtSj1K7MmB6I= =CliF -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFyF3cACgkQ7ZfpDmKq fjSLPw/9EDTMMp0ySiPkYgXICy+hYq78xDOpF5IU34tcvmL2j3OZiM49X//CQzNF 7kLoEkYenpjJZ9QU8V0w+26UJF3js/R3a9gLU3ybPZ7+o+NOanQK68z5EvggWGfm 0yVCGbPhsKNoP/2Xtpv3gLiT6WoBvJF6k16mRQtiE7ngLJ3OUpaWaQAZ73F+sMTY I5F++cAdTvOTHw6M4ORmvp8OMg2df1KVXf2MINQZkx3OVxw+y6zaMwcKUJHz81eY KCDO6DJyoj48/WNDxfIiYVk2YoOVm9I3HiqgmrojmniJFLCq/PkWGqU61gmNCSRv 5vLjb9qnfWQG8E3E44pdH8aqZt7z7kYdcL89y5UnDBlJMmoh/cPigjfBmAot7Erw 5Mj8pp/a7tcvHKIoGZscIzjRnffYDHTD6rNwStVvTfKyGE7O6Fa63yUnndCudqdu 6nZCQNkELrn9ber4ieJR6d46LOVFvqlMhCzhknZRUBkbtU4ltwBze8RvrGGhdyJ3 s9YQtGpY1uEcNF4JWzqkE9sXtPnevFERUT1hZdQpJ2NM0mrVKAfdLhryvJyi+t30 fbMbyqmYRhPuyk7OUPbduTIXc4IIpSzAaeQRFwZqDGSOuOj+8JSk6EX9Kwel7ahp 2PIzzyffxL7m2kG9+iAKckRHz0nyvoYGHQl1gsah9qUVx2Q/JIo= =kEHz -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFyF3cACgkQ7ZfpDmKq fjSLPw/9EDTMMp0ySiPkYgXICy+hYq78xDOpF5IU34tcvmL2j3OZiM49X//CQzNF 7kLoEkYenpjJZ9QU8V0w+26UJF3js/R3a9gLU3ybPZ7+o+NOanQK68z5EvggWGfm 0yVCGbPhsKNoP/2Xtpv3gLiT6WoBvJF6k16mRQtiE7ngLJ3OUpaWaQAZ73F+sMTY I5F++cAdTvOTHw6M4ORmvp8OMg2df1KVXf2MINQZkx3OVxw+y6zaMwcKUJHz81eY KCDO6DJyoj48/WNDxfIiYVk2YoOVm9I3HiqgmrojmniJFLCq/PkWGqU61gmNCSRv 5vLjb9qnfWQG8E3E44pdH8aqZt7z7kYdcL89y5UnDBlJMmoh/cPigjfBmAot7Erw 5Mj8pp/a7tcvHKIoGZscIzjRnffYDHTD6rNwStVvTfKyGE7O6Fa63yUnndCudqdu 6nZCQNkELrn9ber4ieJR6d46LOVFvqlMhCzhknZRUBkbtU4ltwBze8RvrGGhdyJ3 s9YQtGpY1uEcNF4JWzqkE9sXtPnevFERUT1hZdQpJ2NM0mrVKAfdLhryvJyi+t30 fbMbyqmYRhPuyk7OUPbduTIXc4IIpSzAaeQRFwZqDGSOuOj+8JSk6EX9Kwel7ahp 2PIzzyffxL7m2kG9+iAKckRHz0nyvoYGHQl1gsah9qUVx2Q/JIo= =kEHz -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. 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

Re: [tz] Palestine winter time
by Paul Eggert Oct. 21, 2021

Oct. 21, 2021

On 10/20/21 01:47, heba.hamad(a)mtit.gov.ps wrote: > winter time will begin in Palestine from Friday 10-29 ,01:00 AM by 60 minutes backwards. Thank you for letting us know. Attached is a proposed change to tzdb, installed into its development version <https://github.com/eggert/tz>. We plan to have a new tzdb release soon. This change implements this year's transition, and also guesses that winter time will begin on October's last Friday at 01:00 in 2022 and later years, to be consistent with 2021. If this guess is wrong, please let us know as far in advance as possible, because rule changes trickle out only slowly to cell phones and computers.

2 1

The origin of time zone regions
by Arthur David Olson Oct. 21, 2021

Oct. 21, 2021

A middling-length story with a small point. In the seventies and eighties, I helped develop two-dimensional PAGE* image analysis software. Black and white images had a thousand or so spots; the positions of the spots and their size provided information on the characteristics and abundances of proteins in samples. Step one was to get the positions and sizes of spots in a single image. Step two was to compare two images, pairing up the spots. Some spots would only appear in one image and have no pairs; in other cases, two (or more) spots would appear in one image where only one appeared in the other; one spot would be paired with multiple spots. The final step was to consider groups of images. For this purpose, there were groups of spots where (to quote an article on the matter) “each spot in a group is paired with some other spot in the group and no spot in any group is paired with any spot in any other group.” In the mid-eighties, work started on the time zone database. And time zone regions ended up being defined as being places where all the clocks agreed. The small point: the nature of time zone regions has less to do with chronometry or geopolitics than it does with gel analysis. @dashdashado _ * https://www.sciencedirect.com/topics/neuroscience/two-dimensional-gel-elect…

1 0

Re: [tz] Pre-1970 data
by Stijn “Adhemar” Vandamme Oct. 20, 2021

Oct. 20, 2021

The “should timezones be merged when they contain identical offsets from 1970 onwards” discussion has been going on for quite a while on the tz mailing list. Still, contributions that I find insightful are still being made. Stephen Colebourne recently made this observation: > The key observation is that the segregation between these two groups > > of IDs *did not exist* until around 2014. It was only in 2018 that the > > ISO country rule was removed. > This change was reflected in the documentation <theory.html> as recently as 20/21 February 2019 < https://github.com/eggert/tz/commit/5f48dee82bc111b21f3610893e3b788e37396bce > < https://github.com/eggert/tz/commit/6176aefe79e83ddb8f255849b85c149f34d46aba > And Stephen made this spot-on point of analysis: > FWIW, it is clear to me that there is an aspect of imposing a > > US-centric timezone system on other parts of the world. The recent > > tzdb approach of focussing entirely on timezone regions makes perfect > > sense for the US, where region boundaries do not follow state lines, > > and ordinary members of the public need to be aware of whether they > > are in US/Mountain or US/Central. This simply isn't the timezone model > > in many other parts of the world. In places like Europe and Asia, the > > timezone is driven primarily by the country you live in - an ordinary > > member of the public in Iceland is never going to associate with some > > abstract timezone region stretching down the Atlantic that is not > > named, not legally defined and is little more than a random outcome > > based on tzdb's choice of 1970. Even in somewhere like Norway, an > > ordinary member of the public will understand that although they > > follow CET, their timezone is actually driven by their Government in > > Oslo. The brilliance of the original rule - "ID as needed for > > post-1970 data, with at least one per ISO country" - was that it > > seamlessly handled *both* models of timezone in one unified set of > > IDs. Removal of the ISO country part has completely destabilised that > > balance. > If I may throw in my two-penny, it would pertain to the documentation of this policy. Presently, <theory.html> does mention - that timezones are zones whose clocks all agree about timestamps that occur after the 1970 POSIX Epoch; - that 1970 is indeed a somewhat-arbitrary cutoff, but that moving it earlier even by a decade or two would impose significant challenges, due to the wide variety of local practices before computer timekeeping became prevalent; - that pre-1970 clock transitions are recorded for location-based timezones, but that the database is not designed for and does not suffice for applications requiring accurate handling of all past times everywhere; - that the previous “at-least-one-timezone-per-country-with-officially-designated-ISO-3166-1-two-letter-country-code” rule is dropped for this imposed too high a maintenance burden; and - that some information outside the scope of the database (implied: pre-1970) is collected in a file backzone that is distributed along with the database proper, but that this file is less reliable and does not necessarily follow database guidelines. What astonishes me in this issue is that high-quality information is being removed from the database proper into backzone, without this being mentioned in the documentation <theory.html>. Granted, <theory.html> does not explicitly state an “at-least-attempt-to-get-monotonically-closer-to-the-truth-with-increasing-versions” policy, but one would think that’s implied in maintaining a (versioned) database, unless explicitly stated otherwise. The other way around (moving information from backzone to the database proper, e.g. when historical information is double-checked and confirmed to be in accordance with database guidelines) is totally acceptable without mentioning in the documentation <theory.html>. Indeed, even though I know that correcting pre-1970 data is not the priority of this project, I’ve seen some great sluthing of historical time zone offsets presented on the tz mailing list in the past, and I kinda assumed that the results of such research found its way to the database proper (or backzone when doubts remained). In my opinion, removing high-quality information — thereby having correct offsets changed into incorrect offsets in information systems that rely on the tz database and keep it up-to-date on the default settings (which disregard backzone) — should cease, and should preferably be undone where such damage has already occured. Seeing how much problems pursuing “fairness” under the new rules causes, perhaps it’s worth reinstating the previous “at-least-one-timezone-per-country-with-officially-designated-ISO-3166-1-two-letter-country-code” rule, either officially or unofficially. (And for what it’s worth, this comes from someone who generally tries to avoid relying on country lists such as ISO 3166-1, due to strong political belief in the desirability of independence or at least increased self-governance for several countries/regions currently lacking an officially-designated ISO 3166-1 two-letter country code, including Flanders, Wallonia, Scotland, Catalonia, Basque Country, Canary Islands, Tibet, and others.) But alternatively, if this project persists in its “removing-high-quality-information and merging-for-merging’s-sake” policy, then at the very least this should be mentioned clearly, unambiguously and conspicuously highlighted (bold, bigger font size, bright but fully saturated background colour, following an animated warning icon, the lot) in the documentation <theory.html>: PREVIOUSLY OR CURRENTLY CORRECT PRE-1970 OFFSET INFORMATION IS > INTENTIONALLY BEING CHANGED AND/OR MAY INTENTIONALLY BE CHANGED IN LATER > VERSIONS OF THE tz DATABASE INTO INCORRECT OFFSET INFORMATION for the > braindead reason of merging timezones for merging’s sake. > USERS MUST NOT RELY ON UNDISPUTEDLY AND UNCONTESTEDLY CORRECT AND VERIFIED > OFFSET INFORMATION REMAINING CORRECT in the database proper, except for > timezones that have post-1970 particularities which prevent them from being > merged with foreign timezones. (And even then — who knows what the > coordinator-maintainer will come up with next…) > Information systems that rely on tz for offset information, including for > pre-1970 datetimes-with-timezone-identifier, ought to pass this warning on > to their users. > — Adhemar

1 0

Palestine winter time
by heba.hamad＠mtit.gov.ps Oct. 20, 2021

Oct. 20, 2021

Dear Sir, I’m Heba Hamad .I have been appointed as a focal point by the Ministry of telecommunication and information technology (state of Palestine) to communicate with you. We would like to inform you that winter time will begin in Palestine from Friday 10-29 ,01:00 AM by 60 minutes backwards. Kindly find the attachment below that includes the decision of the Palestinian cabinet. With Respects, Sent from Mail for Windows

4 4

Palestine winter time
by P Chan Oct. 18, 2021

Oct. 18, 2021

http://wafa.ps/Pages/Details/34701 https://www.facebook.com/wafagency/posts/4457787417632704 Palestine winter time will start from midnight 2021-10-29 (Thursday-Friday).

4 4

[tz-announce] 2021d release of tz code and data available
by Paul Eggert via tz-announce Oct. 15, 2021

Oct. 15, 2021

The 2021d release of the tz code and data is available. This release reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Briefly: Fiji suspends DST for the 2021/2022 season. 'zic -r' marks unspecified timestamps with "-00". Changes to future timestamps Fiji will suspend observance of DST for the 2021/2022 season. Assume for now that it will return next year. (Thanks to Jashneel Kumar and P Chan.) Changes to code 'zic -r' now uses "-00" time zone abbreviations for intervals with UT offsets that are unspecified due to -r truncation. This implements a change in draft Internet RFC 8536bis. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2021d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2021d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2021d.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: 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 4de3d7f2499328c97e652242a36fed9523741d12 dated 2021-10-15 13:48:18 -0700 and tagged '2021d' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: dbd7e3df02a11676600aa7efa14592feb2ac9ab5807b0d395e0c29ff1ed4a31580120287df9fe0c65a78162157dcd31d9fbe90a2a93bfd891d59ae3668a3adda tzcode2021d.tar.gz e25e85679256cfa57072cc8902aad1ca1df5ddc4a06844ca38bd57c8b5ad386e38303654dc85525f4fb470a924db4deb3576827a14d3ff87f4a1c679414b95c9 tzdata2021d.tar.gz 6ccb3ed6ebf35643cb49d503f18b7c66957de098f41870fd14ac37489b0931abd6d3e7bf5c2797e69f56f44b31ff9f9068ffa40f5aa29260ecda9d0aac878103 tzdb-2021d.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFp6ekACgkQ7ZfpDmKq fjQtmBAApD1Am4P0gbEECXOABxrnE258QrPRqPhupj45gW0kMD5BehW+yO2oIzOU zDmgLbWyG5CmbD2lSt2fq1mZKhfqYD2J4QJlwwiPGHriNKZZCVIQniXZVRFUzQz/ oObtIzNm5mgR6OUhWDcbzYZsa10eJ7HTMrDOGViZ7T1DyLj5yobSXqkC/Q/ZlEvM Vpnl9nDieey2GgXvobfpR+Bby6NB26Pojjab9Mbw9jyRtcvnf6GmdBn6v4aoDwKc ZUqcb9qjv7NXnN5o9nCUSK7/ad+RoVZJAVDe84Quj1Vn8ydfZ0/1+i6bF3mM6Bpi I3riuPKkv7AHW2iRgZPnnqH7U+X32gb55/+WleokkasZj7e8i1QjJW7L0b91YOHN USz1McquYNsh/n9IDph4Zw1tBpbmLYAy3HQPaR6OzO8fc9paw5nsoics/5fQ5WoZ 2T2EavJfa045XKxwzd57w9YthQgW27Ep6UMpVCEGjYCBfVt8MfmiB787apGJdeJj NeVaKfSfpE4PTWvrtfTXPCIVIbIhlA5UUXyhEBXrMJw/FVxf8rAHGi/zvmrgl48X iY/xMG4yWpUYwZqWG0NBeGE0tvj8Yj2NagWj/UnGXcte3MvgmjkFSnKhj+UZrcA+ 1ehgE8pGicWEl0xl7uW6uwJ1IgWBMHYIkxpslJdTru+nnfbBIaA= =Bvd6 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFp6ekACgkQ7ZfpDmKq fjTbSA/9HBEpib2dXzZg06u4WuVwFEbzu1AUblHm7I9PAzoxtTvJJqH0dMCrHDlj wldeHGclbBxLq8wF33Ajh7bvgISDhmjQCm/ux7nS0ctRnPkV4Pj2j6lsfk/gYVIB agFefLTTrdHaIrPxZ9TK7c63X+6HMfFDnE+nOrJXimls/gW/Xu/VeMDtngrCIoB3 JTSbPePbaSlA+NMn+RRhfb6jlw/Slbm7n5Zpf+VSZs2HN4+bNpHuFLbl5oMbPOrQ C+va/yKJXrNYroGOfIlz/ZnM24ZGDterLh9BBLe+zy3Ni+dhuH0x406C8zkZXSDu U1BZvHK3f84beSF0H1SbkGyjkfVSIol1o2p69mMdcyZzewng3n+MLB8lNxyMkmyk f8cTKviE0V+xoEe/yV8+0+uDhli+oLMudqNGy8eCRNgrnRkCsP513LMX73bagohQ xjtBd+cp2VSzhV4vXsJJE7mIwzofnZaGqdR/jyHND+4gx80TQo8Ftc29wRGbwCCI WU37r17EmcOPg+emOciIf8nYCPnIvKGBBZ0UcCEuvaZXXYhyg+2c82z7A+bIPZaS 6wQZhqptoWB07tJOMxcgCCV7I1fT8+GLlLLlJQXladooOa06mVzsFk8VlUX4PRl3 bIQGNgqRtoE/RnhbxgD0A4ToYUqdMvYzcoCGIGpg/4zmyFZWcaY= =NgZm -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFp6esACgkQ7ZfpDmKq fjSsWg/+NCtwn4E06FCtkR08EV0R8uG4xI6HyQc8JsB5DiFkt+evge2Bu+De03y5 nUJ1eaWbg27MLMfdYI7q5tET9G5RRcFUSZx5Zpj+Bv++KHEz7QSB5ZajE2n2qi93 AkXtFEQn8n0sCKbxdpikiUtKyZbIhcBZkzpAVU3sDdphoLUJFI2YPUCwNL5sPnzH 9pI9/iXCvu1mDW0Mg+mdBO6BuMVmTZneSJ+qtWVRvDPBvWJu8vDr16YiNaTYXkX6 atnvTDmjc3RP5DAjFzItBjsZWcLfrWWQ9WezYXWGDmJS+ijxSH0eYAUfXdHESMMd ggNwlsYZumla1p8yGmHP7YkUynds2hZYV8ySCZhfaCjq/AYANs2hzYLIY5reQ6mJ XxRoGOECc2uCmIVwFjYAALghW0GnDAy6M/l+qgzSxAr92Y0GdlFSdv8yWvIBYPyg /gFKrS+IkLHPJEF5vcpxCpCJC2XR2lJLAzoAgLUc14kD5enmVUjJzia8CpKahq2S argJwtnUl+pZT5QLfOSC46jG2o+RnhSarPSNb21cs+eNnPMA31aXDIRrGDCJ6UXf nRAU1t7eq4bbb/cvEGgJ9ZCfoQpBhYT4QO8as4JXnzkHrB7PuUiqw2sOXixF6H46 MSKRQq/uWI6XiAbXpUDFh67EeH/U1YkR8mx67Uii6pcGLvK2ptM= =Brw7 -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. 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

[PROPOSED 1/3] Document that -00 means local time is unspecified
by Paul Eggert Oct. 15, 2021

Oct. 15, 2021

* tzfile.5, zic.8: Document longstanding practice in time zone abbreviations. This better matches draft RFC 8536bis. --- tzfile.5 | 4 +++- zic.8 | 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/tzfile.5 b/tzfile.5 index 74564cb..e2f11b4 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -118,7 +118,9 @@ and serves as an index into the array of time zone abbreviation bytes that follow the .B ttinfo -structure(s) in the file. +entries in the file; if the designated string is "\*-00", the +.B ttinfo +entry is a placeholder indicating that local time is unspecified. The .B tt_utoff value is never equal to \-2**31, to let 32-bit clients negate it without diff --git a/zic.8 b/zic.8 index 3727922..89fc827 100644 --- a/zic.8 +++ b/zic.8 @@ -559,6 +559,9 @@ alphanumeric ASCII characters, .q "+" and .q "\*-". +By convention, the time zone abbreviation +.q "\*-00" +is a placeholder that means local time is unspecified. .TP .B UNTIL The time at which the UT offset or the rule(s) change for a location. -- 2.30.2

1 2

Kiev >> Kyiv
by Pavlo Komendant Oct. 12, 2021

Oct. 12, 2021

Hello, Could you please amend the Ukraine capital in the time zone? Kyiv is the correct spelling of the Ukraine capital https://en.wikipedia.org/wiki/Kyiv Thank you! -- Pavlo

3 2

Daylight Saving in Fiji Islands
by Jashneel Kumar Oct. 11, 2021

Oct. 11, 2021

Dear Support, Please note that there will be no daylight saving this year. Appreciate if the same can be reflected in your system to ensure that the time does not change. Looking forward to the confirmation. Regards, [New_VF_Icon_RGB_RED] Jashneel Kumar Manager Data Networks & Services Jashneel.Kumar(a)vodafone.com.fj<mailto:Jashneel.Kumar@vodafone.com.fj> Vodafone Fiji PTE Limited, 168 Princes Rd, Tamavua, Suva, Fiji Islands www.vodafone.com.fj<http://www.vodafone.com.fj/> Together we can [Vodafone] ________________________________ The content of this email including any attachments is confidential and may contain information that is proprietary and privileged. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify E-mail Administrator on info(a)vodafone.com.fj Please also destroy and delete this message from your system. Vodafone Fiji PTE Limited does not guarantee that this message is free from computer virus or any other defect. The reader accepts full responsibility for taking defensive and counteractive action needed to rectify the computer virus or other defects caused. Vodafone Fiji PTE Limited : Private Mail Bag, Suva, Fiji | Telephone : +679 3312000 | E-Mail : info(a)vodafone.com.fj Please consider your environmental responsibility before printing this e-mail [https://www.vodafone.com.fj//images/default-source/logo/logo-2x.png] Vodafone Fiji PTE Ltd <https://www.vodafone.com.fj/>

5 6

Typo in zic(8) man page
by Jonathan Wakely Oct. 8, 2021

Oct. 8, 2021

The description of a RULES field in a zone line says: "giving of the amount of time to be added" The first "of" looks like a typo.

2 1

Classifying IDs
by Stephen Colebourne Oct. 8, 2021

Oct. 8, 2021

Following on from the previous thread [1] I wanted to try and classify the IDs we have, which may or may not identify missing IDs. Again, please avoid talking about pre-1970 data at this point. Obsolete ------------ IDs that are obsolete and should never be used. They date from many years ago whe tzdb was just starting. Yet these still do appear in downstream UIs even today (of course UIs should not use the tzdb ID list, but in reality lots do). Examples: Portugal, NZ-CHAT, Navajo, Libya. Proposal: Provide 3-6 months notice, then move obsolete IDs to a new file "obsolete" which downstream projects are strongly encouraged not to include. (I would argue that the time has come to properly remove these IDs, which are very inconsistent in terms of which are provided and which not, eg Portugal, but not Spain) Deprecated, same location ------------------------------------ IDs that have been deprecated with a single clear alternative ID being provided. Both IDs represent the same physical location/city. Spelling changes: Asia/Katmandu (replaced by Asia/Kathmandu), Asia/Rangoon (replaced by Asia/Yangon) ID structure changes: America/Louisville (replaced by America/Kentucky/Louisville) Proposal: Ensure all of these are in `backward` Consider: Is there any way to move these IDs to the obsolete file? Maybe after 5 years? Or do we just accept backwards compatibility restrictions on these? Legally described mega-zones ----------------------------------------- IDs for locations where a federal or supra-national body defines rules, eg the EU or US DOT. Examples: US/Mountain, CET, WET Consider: Can we write down a rule to identify when something like this should be included? Then move the matching IDs to the main files (eg. are the EU and US DOT the only two examples here?) Regions ----------- IDs for abstract regions that have had the same wall clock since 1970. Examples: Europe/Berlin, America/New_York, Africa/Abidjan Proposal: Ensure all of these are in the main files. Consider: Should there be new IDs for each of these abstract regions to indicate they are a separate and distinct concept? eg. "Region/Berlin". (Maybe something to consider in future threads as it isn't clear what the benefit of doing so is without considering pre-1970 which I'm still trying to avoid) Non-region locations --------------------------- IDs for locations that are not region IDs. Each ID will have the same wall clock since 1970 as one of the region IDs. Examples: Europe/Oslo, Europe/Amsterdam, Atlantic/Reykjavik Consider: Can we write down a rule that covers which IDs are included here? And therefore when a new ID can be added to this set? If we can define a rule, then these can be split so rule-following IDs are in the main files and rule-breaking ones are in `backward` (although ideally they should be separate from the spelling changes). Obviously, we can say these IDs only exist for backwards compatibility, but that seems like a weak justification, and doesn't tackle the issue of when a new ID would be added to the list (which has been a point of tension). As is well known, I think the obvious rule is that the IDs follow the ISO-3166-1 standard (rule: one ID per ISO code, additional IDs may be added where clocks have diverged since 1970). Using ISO-3166 can be justified by IANA domain policy [2]: "We are not in the business of deciding what is and what is not a country. Instead, we employ a neutral standard maintained by the ISO 3166 Maintenance Agency. Our policy is to create new country-code top-level domains when the country or territory is listed on the ISO 3166-1 standard." As per the previous thread, these non-region location IDs are actively used in downstream business applications, and it is not OK that only works because tzdb happens to have IDs for backwards compatibility. There needs to be a better justification than that - these non-region locations need to be fully supported, with a consistent rule used to define what is and is not fully supported. Fixed/etc type rules -------------------------- IDs with a fixed offset Examples: GMT, UTC, Etc/GMT-9 Proposal: No change, retain in the main files unless a particular ID is considered obsolete or deprecated Are there any more classifications I've missed? Stephen [1] https://mm.icann.org/pipermail/tz/2021-September/030857.html [2] https://www.iana.org/help/eligible-tlds

7 17

Downstream use of 2021c
by Philip Paeps Oct. 8, 2021

Oct. 8, 2021

Since the tzdata 2021c release removed most of the controversial link changes, I wonder how other downstreams feel about importing it. I spent some time this morning looking at the downstreams I know about. FreeBSD has 2021c in main but is still on 2021a plus Samoa and Jordan in the supported stable branches. Debian is in the same state as FreeBSD. NetBSD, OpenBSD and Ubuntu are on 2021a + Samoa and Jordan. Fedora is on 2021b. CentOS is on 2021a. A casual glance at other Linux distributions shows they are either on 2021a or 2021c. I am not familiar with their support models so I can't read anything into that. Python "pytz" seems to be on 2021c. Python "tzdata" seems to be in a similar state to FreeBSD, though I'm not sure I'm interpreting the release model correctly. I know Paul G is on this mailing list though. As far as I can tell, PostgreSQL is still on 2021a without modifications for Samoa and Jordan. Tom will correct me if I'm reading that wrong. I don't know enough about PHP, Java or any of the other well-known (let alone less well-known) downstreams to figure out what they're doing. This is looking terribly fragmented. Spare a thought for a hypothetical engineer tasked with debugging a Java application on Debian with some Python scripts on Fedora talking to a PostgreSQL database running on FreeBSD... While discussions on this list appear to have become more constructive, it looks like we're still lacking a clear consensus on the long-term direction. I feel that 2021c is a pretty reasonable compromise and would be willing to merge it to the supported FreeBSD releases. Is this something other downstreams would consider too? Alternatively, can we reach an interim consensus for a 2021d release that we'd all be willing to merge? Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises

11 20

Use cases for source data
by Gilmore Davidson Oct. 8, 2021

Oct. 8, 2021

Stephen Colebourne's recent attempts to define requirements and use cases for tzdb got me thinking about the source data files. There have been several discussions over the years regarding the intended stability of the source format, separate from TZif binary files. These generally arise when the answer to a data query is "use this special compile-time flag". The most recent example is from Stephen at http://mm.icann.org/pipermail/tz/2021-September/030561.html The subtlety is in how the data set is consumed. While many downstream > projects use the makefile, not all do. A significant portion of > downstream users make use of the source files directly, with their own > parsers. ie. there is no ability to use a compile-time option. Those > parsers are not setup to use backzone even if it were a valid option > I think some of these discussions come about because there's disagreement about the intended use of the source files. The impression I've got from this list over the years is that the source files weren't intended to be a stable API; only the compiled TZif binary files were intended to be consumed downstream (and in later years, the .zi text representations). But many projects do use the source files as their primary interface, leading to tension when the format changes. So this is my attempt to list the use cases that people have for the source data files. This could prompt a wider discussion about what counts as a defined, stable interface for tzdb. Not every consumer of tzdb data is relying solely on the pre-compiled binary files. NOTE: This is a separate issue from the recent pre-/post-1970 data discussions. I'm trying to stay away from wading into that topic. ----------------------- Consumers of the source data text files: 1) The zic compiler for producing TZif binary files and .zi text files in an official tzdb release. 2) People reading the file comments to understand the history of certain zones. 3) Libraries/projects that need to parse/compile the data into a different representation than that provided by zic. This is often, but not exclusively, to preserve the distinction between Link and Zone entries, either for API or data compression reasons. 4) Data analysis or visualisations that care about knowing the higher-level Rule definitions ("transition on the last Sunday of October every year") rather than the exact transition timestamps for each year. 5) IDE or text editor plugins that provide syntax highlighting for the source files. All of these are based just on my own experiences and from lurking on this list. Any corrections/additions are welcome.

2 1

Re: [tz] On ISO country for timezones (Re: Classifying IDs)
by dpatte Oct. 7, 2021

Oct. 7, 2021

I believe you are missing an important part of this discussion.There is a strong need for a repository of pre 1970 data, especially for historical research applications. As this is the only tz database, tz has also become the main database for this older data.For any populated place on earth researchers need such a repository. If I want to add the pre 1970 tz history for Ottawa Canada where should it be stored? Since it is called tz, and it also has other pre 1970 data, tz seems the appropriate place.But if no simple method of adding open-ended historical data is negotiated here, then the only other option is to fork tz and work on it as a separate project.Secondly, since the number of locations that could eventually be supported in a historical tz database is potentially very large, it cannot not be micromanaged, and this suggests that each historical zone should use an international standard for naming - iso - for simplicity and clarity.Canada/Ontario/OttawaAre we going to have two tz databases, or just one. That is the question here.Sent from my Galaxy -------- Original message --------From: Steffen Nurpmeso via tz <tz(a)iana.org> Date: 2021-10-07 09:35 (GMT-05:00) To: Stephen Colebourne <scolebourne(a)joda.org> Cc: tz(a)iana.org Subject: Re: [tz] On ISO country for timezones (Re: Classifying IDs) Stephen Colebourne wrote in <CACzrW9Cau-q2e+yoBcg=7Rztu19zZN582Xca9ZMYbz=H_0iOpw(a)mail.gmail.com>: |On Thu, 7 Oct 2021 at 07:08, Watson Ladd via tz <tz(a)iana.org> wrote: ... |I agree with backwards compatibility. The primary concern here is |whether an ID is considered deprecated or not.IDs shall be stable and not change at all. At maximum they shouldbe moved to backward, for example if a zone is renamed (which mayhappen for example for Ukraine in a not too distant future, ifthat is still necessary then, and it looks as if it would be).I would always have been all for making infinite stability of IDsa documented assertion.Even if not, your "six months" claim is nothing but an aggressivestatement. I think this entire thread is shadowboxing and noisefor nothing.Looking at the interface of your JAVA framework i think getID()should simply return the correct ID, which may be a link if it isone, and just in case this is not what getID() already returns.In my opinion there are only two problems with IANA TZ and howPaul Eggert manages it as a maintainer. That is the same PaulEggert who contributes to this software since 1995, an astonishing26 years. Corroding the maintainership with a continuous streamof noise is disgusting.The first is combining of datasets to equal-post-1970 bundles,which is going on for many years. But the data is there, it is inbackzone, and everybody can easily install a complete TZ DB onone's own request. Yet noone did, even though many packagers areon this list. This is schizophrenic. But maybe it is onlybecause of black and yellow people do not matter as much as someblue-eyed white people from northern Europe, which does not trulycome as a surprise given the audience who possibly reads this now,and given the fact that colonianisation ended only about 55 yearsago, and de facto was only turned from armed political to armedmaterial oppression.The second is that documentation did not follow suit the codeimprovements, as has been recently shown for tzselect(8) and the-t option. That tzselect(8) uses the administrative zone1970.taband not the end-user-preferrable zone.tab is a different thing.If you want to enforce upon the maintainer of the TZ database thatthe pre-1970 data is joined back into the normal data, or that"backzone" is splitted into "backzone" and "unreliable", and/orthat "backzone" is included by default, and/or that "ZFLAGS='-r@0'" is made default, then create a thread and try to gain enoughhums, but please stop this subversion by spreading uncertainty andthat even upon topics which never were under discussion as far asi know, and i also read this list for a decade now.It must anyway be said it was nicer once i only had thedistribution and did not know about the list :)Ciao from Germany,--steffen||Der Kragenbaer, The moon bear,|der holt sich munter he cheerfully and one by one|einen nach dem anderen runter wa.ks himself off|(By Robert Gernhardt)

2 1

TZDB use cases
by Stephen Colebourne Oct. 7, 2021

Oct. 7, 2021

In this thread I want to try and capture the *requirements* for the project from the perspective of a downstream user. Given this, we may then have a chance to analyse whether the project needs a change of rules. NOTE: The discussion below is not a proposal, nor does it seek to explore which locations get pre-1970 data. Lets keep that for another thread. -------- 1) "What is the time now?" To answer this question you need a dataset that records the current timezone rules for each region in the world. Over time that data will naturally build up to form a historic record. To aid the project, a 1970 rule has been adopted for data management. In some parts of the world, clocks have agreed since 1970 across large parts of a continent. In other parts of the world, different parts of the same country have had different rules since 1970. Viewing the data through a post-1970 lens splits the planet into regions where clocks have agreed since 1970. Some of these regions are quite abstract, for example the region including Iceland, Ivory Coast, and St Helena. An abstract region would need to be split if one of the parts of the region changed its timezone rules. If a user had previously selected to follow one of these abstract regions, they might have to change their timezone settings. For example, if a user in Iceland selected their abstract region by the recommended ID based on the largest city they would get `Africa/Abidjan`, but if the Ivory Coast changed their rules, users in Iceland would have to change their selected timezone. The minimum set of IDs is one ID for each abstract region. The current ID scheme selects the largest city in the abstract region. My interpretation: * An abstract region should theoretically have an ID separate to the IDs of the cities/countries in the region * Trying the ID of the abstract region to the largest city in the region is prone to failure if that city changes timezone rules but the rest of the abstract region stays the same. * An abstract region ID would naturally have no pre-1970 data, as it doesn't define data in a single city/location. * The alternative is to encourage users to use their local city, which means that IDs like Europe/Amsterdam and Europe/Oslo cannot be deprecated -------- 2) "What was the time at some instant in the past?" The project can answer this question pretty reliably for dates from 1970 onwards because of the data set in #1. The project can never realistically answer the question reliably or accurately before 1970 for *all* locations. For example, timezone rules were entirely local in the US for about 20 years, meaning that hundreds of entries would be needed to correctly capture the data. In addition, much of the historic data globally is unknown and not viable to research, even if someone wanted to do so. It is possible to research and record historic timezone rules for *some* locations. Europe/London being one example. The project generally operates on the basis that if an ID exists, historical data can be recorded against it, although which file that data lives in has varied over time. IDs are generally not created solely to document historic data. There is no minimum set of IDs for this use case - the set of possible IDs is unbounded. My interpretation: * The majority of pre-1970 data isn't much use * Some pre-1970 data is high quality, and almost certainly relied upon (eg Europe/London) * Without a massive increase in scope the best that can be done pre-1970 is to record data against IDs created for some other reason. -------- 3) "An event will happen at this time in the future" If an end-user wants to store an event in the future, eg. a one hour meeting next month, the correct approach is to store the date, time and zone ID, not the offset (which is not yet known for certain).Even if the local timezone authority changes the tz rules between now and the event, the time of the event is still correct. https://stackoverflow.com/questions/19166995/java-calendar-date-and-time-ma… For this approach to work, the ID that is stored must be aligned with the timezone authority. Business contracts are frequently written to describe future events. For example, payment must be made by 2pm Paris time on a given date. The minimum set of IDs for this use case is one ID per timezone authority. This is typically the country but not necessarily, examples being decisions devolved to states/nations etc. My interpretation: * Using TZDB IDs for future events/contracts is very widespread * In most parts of the world, this requires one ID per country, in some parts of the world additional IDs would ideally be needed such as per state in the US * One ID for each ISO country (as was the guideline in the past) is a reasonable minimum expectation of end users * While one might argue IDs for future events are not TZDBs problem, I believe the reality is that they are because usage in this way is already very widespread -------- 4) "An event will happen at this time in the future relative to a shared/common definition" Some future events are declared relative to a definition that is supra-national or federal. For example, US Mountain, US Pacific, EU Central etc. A TV show might be defined to air at 8pm Mountain Time in one months time. It will air at that time regardless of whether any of the states that are currently on Mountain Time change to Pacific Time. For example, even if Denver (and Colorado) moved to Pacific Time or stopped following DST, Mountain Time would still exist and the TV show would still air at 8pm Mountain. The minimum set of IDs for this use case is one ID per shared/common definition. These IDs are not full aliases for a country or city ID, although they may currently share data. To support this use case, these IDs cannot be deprecated. My interpretation: * Some shared zone IDs are distinct and separate enough to warrant a full ID * US Mountain time is not the same as Denver time when considering the future, the IDs could diverge * In TZDB terms, the Link from US/Mountain to America/Denver is fine to define the data, but US/Mountain should not be considered deprecated as it has a real and distinct meaning separate from America/Denver * It would be useful to agree what the criteria for including these shared/federal rules is. -------- 5) "Data should be backwards compatible" The project has various associated downstream projects. Many of these have an expectation of backwards compatibility. This compatibility extends to the binary format, the source format, and the data contained within. This use case wants to see the project just continue with the data it has, enhancing it over time. The project has a pretty good record in terms of not removing IDs. For example, IDs exist for "Portugal" and "Poland", but not "Italy" or "Spain" simply because they were defined once upon a time. My understanding is that IDs in the `backward` file represent deprecated IDs that should not be used going forward. Yet, downstream projects focussed on backwards compatibility will generally use the `backward` file in full. The minimum set of IDs for this use case is the set of IDs that existed in the previous release. My interpretation: * Many users care about compatibility * The current IDs are not going away * Inconsistency has existed in TZDB for many years, see "Portugal" vs "Spain" - no one wants to fix that * It is hard at present to identify IDs that are deprecated because of proper aliasing, such as spelling changes, vs those where the ID is a real location but its TZDB status has been reduced. * Change may be possible with a long notice period --------- Please note that the above is not a proposal, but an exploration of the design space. If you have any use cases I've missed feel free to write them up. thanks Stephen

10 23

timezone Verschlimmbesserung
by Tony Finch Oct. 6, 2021

Oct. 6, 2021

Paul Eggert's rationale is informative https://mm.icann.org/pipermail/tz/2021-September/030764.html But I think there are a few more things to say. The aim of merging timezones was to avoid political issues and to reduce the maintenance burden. It seems to me that it has failed to achieve those goals. There have been several very long discussions on the topic, and the recent arguments are making exactly the same points as were made in 2013. So I think the changes have increased the amount of political discussion and controversy on the tz list, not reduced it. https://mm.icann.org/pipermail/tz/2013-May/thread.html https://mm.icann.org/pipermail/tz/2013-August/thread.html https://mm.icann.org/pipermail/tz/2013-September/thread.html Paul says in his rationale that it was a lot of extra work, and in other messages he said that he has found it hard to keep up with the discussions. So merging timezones has increased the maintenance burden, not reduced it. I have identified two policy changes that caused this argument. In 2013, Paul Eggert started a new policy of merging timezones that are the same since 1970. As far as I can tell, no-one wanted this other than Paul. This merging policy was applied first to places with small populations, and (because of alphabetical order) to Africa, which is not well-represented by the people on the TZ list. Some of the merges also ignored the guideline that each country should have at least one timezone to call its own. The other policy change was to drop the guideline that each country should have at least one timezone. This change occurred in 2019, buried at the end of a very long discussion about Vietnam, and presented as a fait accompli. https://mm.icann.org/pipermail/tz/2019-February/027602.html This was after a great deal of discussion about the need to retain country information in the tz database, back in 2013 when these changes started. As I understand it, the equity / fairness issue is that the timezone merges were implemented in an unfair manner, affecting Africa (since 2014, against the guidelines as written at the time) but not Europe. So although Paul says the merges worked without significant incident, they did in fact cause a political complaint - exactly what the merges were supposed to avoid. The current argument was triggered by the question of whether this fairness issue should be addressed by undoing the data loss in the compiled tz files that caused the complaint, or by imposing the data loss more strictly. I think the way to fix this is to revert both policy changes, and revert all the timezone merges. Tony. -- f.anthony.n.finch <dot(a)dotat.at> https://dotat.at/ Lundy, Fastnet, Irish Sea: Northwest 4 to 6, backing southwest 5 to 7, perhaps gale 8 later. Slight or moderate until later in Irish Sea and Lundy, otherwise moderate or rough. Rain or showers. Good, occasionally poor.

7 10

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

legal status of information on TZ database
by nadir altinbas Oct. 5, 2021

Oct. 5, 2021

Hye, Is there a RFC document in which "explain rights and responsibilities of icann TZ coordination , about to solve regulation problems become from legal conflicts that third party person or company got and use of changes on TZ database country data by damage of their economic contracts agreement ?04.10.2021regards, Nadir Altinbasnadiraltinbas(a)yahoo.com n.altinbas

2 2

Re: [tz] TZDB use cases
by Hal Murray Oct. 5, 2021

Oct. 5, 2021

Stephen Colebourne said: > So, it turns out that there is, I believe, a critical difference here between > the US view of timezones and the European one. In the US, timezones do not > follow the boundary of the whole country, nor even States. In Europe, by > contrast, timezone boundaries are very much driven by country boundaries. There is another interesting difference. US borders are stable. Czechoslovakia and Yugoslavia have split post 1970. Did all the pieces retain the same TZ info? I think small regions on the France/German border changed sides after WW 1. Are there others? Anything similar post 1970? Have any US/state borders changed when rivers changed their course? If so, do any people live in the regions that changed and/or did anything interesting happen there? -- These are my opinions. I hate spam.

3 3

32-bit section missing transitions in 2021b
by Daniel Fischer Oct. 2, 2021

Oct. 2, 2021

Hi, It looks like 32-bit data generated by 2021b is missing the effects of transitions below INT32_MIN. Before commit 93132d18, zones had a transition at INT32_MIN to the type in use at that time. For example, the Pacific/Port_Moresby zone used to have these two transitions: -2147483648 -> 1 (+10) 2147483647 -> 1 (+10) Starting with commit 93132d18, including in 2021b, only one transition is present: 2147483647 -> 1 (+10) Since clients are supposed to assume type 0 before the earliest transition, this almost always leads to wrong times for some period of time (or all times for extreme cases like Port Moresby). Danny -- Daniel Fischer Rastatt, Germany Oracle Global Services Germany GmbH

3 3

[tz-announce] 2021c release of tz code and data available
by Paul Eggert via tz-announce Oct. 1, 2021

Oct. 1, 2021

The 2021c release of the tz code and data is available. This is a bugfix release that addresses compatibility problems reported since 2021b came out, notably those reported by Stephen Colebourne. Although this release doesn't address the deeper issues about maintenance philosophy and procedures (discussion of which is ongoing), it does merge in changes to address what Stephen reported was his primary problem with 2021b. This release reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Briefly: Revert most 2021b changes to 'backward'. Fix 'zic -b fat' bug in pre-1970 32-bit data. Fix two Link line typos. Distribute SECURITY file. This release is intended as a bugfix release, to fix compatibility problems and typos reported since 2021b was released. Changes to Link directives Revert almost all of 2021b's changes to the 'backward' file, by moving Link directives back to where they were in 2021a. Although 'zic' doesn't care which source file contains a Link directive, some downstream uses ran into trouble with the move. (Problem reported by Stephen Colebourne for Joda-Time.) Fix typo that linked Atlantic/Jan_Mayen to the wrong location (problem reported by Chris Walton). Fix 'backzone' typo that linked America/Virgin to the wrong location (problem reported by Michael Deckers). Changes to code Fix a bug in 'zic -b fat' that caused old timestamps to be mishandled in 32-bit-only readers (problem reported by Daniel Fischer). Changes to documentation Distribute the SECURITY file (problem reported by Andreas Radke). Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2021c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2021c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2021c.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: 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 d2c79c4bc68c02b785990a6d4eb161770058078e dated 2021-10-01 14:21:49 -0700 and tagged '2021c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 9ed7677744058c58656b47d77d464bad6ef503f2892b53c6abe694e68e73fa123dfc5c11bbcbbb7798f0a6bf1da72b81f8f1c63670839b967e15e58d6d36adad tzcode2021c.tar.gz e8de3a17c38f530b2ec39605699742dd32da5ee92ecf64accaaa5b012a1dac51d1f594adc52660602c3425016520346ab6ad614fa475eb310e17ccdcae93e6ca tzdata2021c.tar.gz a6a86b5b84353c952eec6192222f95f348900dfb414f2dd205fa245515a0f240ba50eab83999f2a5c2cc8e3547406c111aacd96ff9043364d679c86a5e4b0794 tzdb-2021c.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFXfJgACgkQ7ZfpDmKq fjReHA/+LiurpLRdXhwkSuhwUKlAQTKmry3F2/zFyobqi+EEEd7naiJIiQbIlScv aZ0cr6Tpq+oP0L8K0EaLMnz9vvb4qd7M3LLGOcrsML8/z0IigMBaA4c8L/Ep3ACa nsLTKESq6bYUJ2SbaFcCFx4KqwA8UEmfhzrPbNxeb3SVgrI1KwUWkpuTCOpewu+g ZYCVO7mFRhLuaD3wCbErtw9g7vQHyHGPGfTDHyc6lPrEbIaY1gwgl6GwBTmJD72a przvxg/0r0X+ZzHH9GZRQaWSDEGXYUdnIwrnS7zwDNk33WO3VwgLWiX2QMGJwiTe wPku4mnGkRhwQLzG+kJxpWe3DJ9/iKFVvxvS3/5RSN1mnELA6xcGOWMTL9cawlwo RkpyN3bLow/9u3wcW2QSrDhCTlGl5kUeK7Qbi20Rji9q2NIO0zrJ732pdr0PgyCN NeuO0YnHUW0bvGO7IMv0JfhQ+VbjB9yAzOg7D2bR2dSVm++38bR8umI757xU/6sT /CTIpmfP67FsXmtg98PbO6rEmoLr7Y/t+JYi/AwzvoHeFS5CAGs9xnTpdk+dBhjh wjLegKDtLZpIUppH9AkJ/T9MAVsfFpsLa2EnteF3LuYZhFTXzLJj3uo3l6Ji0eMZ RRy1jZAxnZ02EoLRIloezzST4pmxIurepluyzvTXVBBuXcoqDk4= =S2t+ -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFXfJgACgkQ7ZfpDmKq fjR/9g/+LOFIZC6n1xKEMn95PsJx2e+zQ4m2/MG1L1KKZdR6kYnvQHL3hh+dXLdr cKRoB6k4AZDaCl7NZDZ8iKgm0nrXnG4/dVEfVOeJn9VHdRyYZ4sg68Nij0yHheRN fcX/ikKwmVaszwj8t+zTmetZOxlJi1mdLyZaQYgBZuM+8Aj+AnB3QUT00yP3j5xP lZgAToYXyLg8KweHnCuD41ZzU8AmsUU2GSfbTryez5lSGnhTsI+tNFtk5w+2fWZZ C0ZAskT//F2k6viFBozeBoodTs955mPKuzyWte6WyhQOTVUySuaeeAU7Dc9SK1k2 nNMTDeQyR78CL39D/X0qmINAif9YKqQ1k0fJFHH1K+pSbhtw0TaqZarQ7JRQnZpC XSIJ9PwpuLLb4k0pBUWYS+r1bZDWrymmgvDO4uNFRFC8LWR4pKyWZ8k34IYQndaV otWbBcThgyz8JJk5mrf113j7qQ3AYiC/y1lVtBpCXpOy1LzYGSTDUqUoHeib8ToD Q3wD1UTPPlo1nh47+cx/Fq1MasdB4MF/OwX7w33nV7TbYgNOHHjb5ROgf7unbaqM 96rtJDRFXFnnPtDOES3xtF4IEEXeoqx1q6AEEcEBBmkCc+DQk5AvW64JwluKn4b1 XSDP7AuXex+wJKffa/7I2KyNLNiX8aLQcnvVsD9cqV4hComR3O8= =LtLe -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFXfJoACgkQ7ZfpDmKq fjTWQA/9Geo9i7m1YlBbU6xJQFyT2AVTTeCgA3wnQOc7VXj5Sy8/7JBU/AJW4Vmi iaTE+XZJU8ghslbdwkyEwoFcZ+4dT8qtjIDSaJ989LV8zpL0MPjgQPdYnh9egaGo qUQBXBcBzzK6giDut7vYcldf5YbK8AAv/ApvVyqL9JjdjbE2P3/juPAHUBUTxHIl bGrnRKbXIeqHB2MGgNZcby4HyblR+BCue3r9kN7Jq0kzETHG8UDeEDeHpL9x9DIq QIYpCiiuMvT7FZR4vNlQg5oBm6Tjz47BEWlvpDQcZHSAgXVrMOTds7uameG72DRW TtEGbozg2LQS3RKHn9mN0GK505d/qiSgrR/AoP420g6xa7d49Orz5qTcE4hUUqQ6 /YA2/3LqqCXeNep/BjwDvsvSTN8TKF4y0iF26Ie2BWRCnI377tT/76NncWaXRT3f k4X2qdIu/6EGle9kleanIZvet3/yavwpOXpgjcMPBwa1RoZDcH2/YSTd0uFhBXLw FTgJ2LKU1d7HVn5VR3t0z1ltjTjv5kjAt+/E/xdANN/vY27ef6yOMp9Mq4z3Pp9Y cUtwwM0aXchlCcomOhoKOShW/j8hFFlIX3pEEAQOhvDS4t7zw0x18+737Fi5diY6 5GUcyKs0sgIkGcAco1qZXd6vvR61ekq7rgMANpi8g9H5igjt5TM= =23yb -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. 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

[tz-announce] 2021b release of tz code and data available
by Paul Eggert via tz-announce Oct. 1, 2021

Oct. 1, 2021

The 2021b release of the tz code and data is available. Partly because it's been so long since 2021a, this release has many changes, noted below. In one area, noted "Merge more location-based Zones" below, the mailing list has had significant trouble coming to a long-term consensus. Because we should publish something before the Samoa change takes effect, this release contains just one step towards making tzdb fairer and more equitable in future releases. This release reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Briefly: Jordan now starts DST on February's last Thursday. Samoa no longer observes DST. Merge more location-based Zones whose timestamps agree since 1970. Move some backward-compatibility links to 'backward'. Rename Pacific/Enderbury to Pacific/Kanton. Correct many pre-1993 transitions in Malawi, Portugal, etc. zic now creates each output file or link atomically. zic -L no longer omits the POSIX TZ string in its output. zic fixes for truncation and leap second table expiration. zic now follows POSIX for TZ strings using all-year DST. Fix some localtime crashes and bugs in obscure cases. zdump -v now outputs more-useful boundary cases. tzfile.5 better matches a draft successor to RFC 8536. A new file SECURITY. This release is prompted by recent announcements by Jordan and Samoa. It incorporates many other changes that had accumulated since 2021a. However, it omits most proposed changes that merged all Zones agreeing since 1970, as concerns were raised about doing too many of these changes at once. It does keeps some of these changes in the interest of making tzdb more equitable one step at a time; see "Merge more location-based Zones" below. Changes to future timestamps Jordan now starts DST on February's last Thursday. (Thanks to Steffen Thorsen.) Samoa no longer observes DST. (Thanks to Geoffrey D. Bennett.) Changes to zone name Rename Pacific/Enderbury to Pacific/Kanton. When we added Enderbury in 1993, we did not know that it is uninhabited and that Kanton (population two dozen) is the only inhabited location in that timezone. The old name is now a backward-compatility link. Changes to past timestamps Correct many pre-1993 transitions, fixing entries originally derived from Shanks, Whitman, and Mundell. The fixes include: - Barbados: standard time was introduced in 1911, not 1932; and DST was observed in 1942-1944 - Cook Islands: In 1899 they switched from east to west of GMT, celebrating Christmas for two days. They (and Niue) switched to standard time in 1952, not 1901. - Guyana: corrected LMT for Georgetown; the introduction of standard time in 1911, not 1915; and corrections to 1975 and 1992 transitions - Kanton: uninhabited before 1937-08-31 - Niue: only observed -11:20 from 1952 through 1964, then went to -11 instead of -11:30 - Portugal: DST was observed in 1950 - Tonga: corrected LMT; the introduction of standard time in 1945, not 1901; and corrections to the transition from +12:20 to +13 in 1961, not 1941 Additional fixes to entries in the 'backzone' file include: - Enderbury: inhabited only 1860/1885 and 1938-03-06/1942-02-09 - The Gambia: 1933 and 1942 transitions - Malawi: several 1911 through 1925 transitions - Sierra Leone: several 1913 through 1941 transitions, and DST was NOT observed in 1957 through 1962 (Thanks to P Chan, Michael Deckers, Alexander Krivenyshev and Alois Treindl.) Merge more location-based Zones whose timestamps agree since 1970, as pre-1970 timestamps are out of scope. This is part of a process that has been ongoing since 2013. This does not affect post-1970 timestamps, and timezone historians who build with 'make PACKRATDATA=backzone' should see no changes to pre-1970 timestamps. When merging, keep the most-populous location's data, and move data for other locations to 'backzone' with a backward link in 'backward'. For example, move America/Creston data to 'backzone' with a link in 'backward' from America/Phoenix because the two timezones' timestamps agree since 1970; this change affects some pre-1968 timestamps in America/Creston because Creston and Phoenix disagreed before 1968. The affected Zones are Africa/Accra, America/Atikokan, America/Blanc-Sablon, America/Creston, America/Curacao, America/Nassau, America/Port_of_Spain, Antarctica/DumontDUrville, and Antarctica/Syowa. Changes to maintenance procedure The new file SECURITY covers how to report security-related bugs. Several backward-compatibility links have been moved to the 'backward' file. These links, which range from Africa/Addis_Ababa to Pacific/Saipan, are only for compatibility with now-obsolete guidelines suggesting an entry for every ISO 3166 code. The intercontinental convenience links Asia/Istanbul and Europe/Nicosia have also been moved to 'backward'. Changes to code zic now creates each output file or link atomically, possibly by creating a temporary file and then renaming it. This avoids races where a TZ setting would temporarily stop working while zic was installing a replacement file or link. zic -L no longer omits the POSIX TZ string in its output. Starting with 2020a, zic -L truncated its output according to the "Expires" directive or "#expires" comment in the leapseconds file. The resulting TZif files omitted daylight saving transitions after the leap second table expired, which led to far less-accurate predictions of times after the expiry. Although future timestamps cannot be converted accurately in the presence of leap seconds, it is more accurate to convert near-future timestamps with a few seconds error than with an hour error, so zic -L no longer truncates output in this way. Instead, when zic -L is given the "Expires" directive, it now outputs the expiration by appending a no-change entry to the leap second table. Although this should work well with most TZif readers, it does not conform to Internet RFC 8536 and some pickier clients (including tzdb 2017c through 2021a) reject it, so "Expires" directives are currently disabled by default. To enable them, set the EXPIRES_LINE Makefile variable. If a TZif file uses this new feature it is marked with a new TZif version number 4, a format intended to be documented in a successor to RFC 8536. zic -L LEAPFILE -r @LO no longer generates an invalid TZif file that omits leap second information for the range LO..B when LO falls between two leap seconds A and B. Instead, it generates a TZif version 4 file that represents the previously-missing information. The TZif reader now allows the leap second table to begin with a correction other than -1 or +1, and to contain adjacent transitions with equal corrections. This supports TZif version 4. The TZif reader now lets leap seconds occur less than 28 days apart. This supports possible future TZif extensions. Fix bug that caused 'localtime' etc. to crash when TZ was set to a all-year DST string like "EST5EDT4,0/0,J365/25" that does not conform to POSIX but does conform to Internet RFC 8536. Fix another bug that caused 'localtime' etc. to crash when TZ was set to a POSIX-conforming but unusual TZ string like "EST5EDT4,0/0,J365/0", where almost all the year is DST. Fix yet another bug that caused 'localtime' etc. to mishandle slim TZif files containing leap seconds after the last explicit transition in the table, or when handling far-future timestamps in slim TZif files lacking leap seconds. Fix localtime misbehavior involving positive leap seconds. This change affects only behavior for "right" system time, which contains leap seconds, and only if the UT offset is not a multiple of 60 seconds when a positive leap second occurs. (No such timezone exists in tzdb, luckily.) Without the fix, the timestamp was ambiguous during a positive leap second. With the fix, any seconds occurring after a positive leap second and within the same localtime minute are counted through 60, not through 59; their UT offset (tm_gmtoff) is the same as before. Here is how the fix affects timestamps in a timezone with UT offset +01:23:45 (5025 seconds) and with a positive leap second at 1972-06-30 23:59:60 UTC (78796800): time_t without the fix with the fix 78796800 1972-07-01 01:23:45 1972-07-01 01:23:45 (leap second) 78796801 1972-07-01 01:23:45 1972-07-01 01:23:46 ... 78796815 1972-07-01 01:23:59 1972-07-01 01:23:60 78796816 1972-07-01 01:24:00 1972-07-01 01:24:00 Fix an unlikely bug that caused 'localtime' etc. to misbehave if civil time changes a few seconds before time_t wraps around, when leap seconds are enabled. Fix bug in zic -r; in some cases, the dummy time type after the last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3. Fix a bug with 'zic -r @X' when X is a negative leap second that has a nonnegative correction. Without the fix, the output file was truncated so that X appeared to be a positive leap second. Fix a similar, even-less-likely bug when truncating at a positive leap second that has a nonpositive correction. zic -r now reports an error if given rolling leap seconds, as this usage has never generally worked and is evidently unused. zic now generates a POSIX-conforming TZ string for TZif files where all-year DST is predicted for the indefinite future. For example, for all-year Eastern Daylight Time, zic now generates "XXX3EDT4,0/0,J365/23" where it previously generated "EST5EDT,0/0,J365/25" or "". (Thanks to Michael Deckers for noting the possibility of POSIX conformance.) zic.c no longer requires sys/wait.h (thanks to spazmodius for noting it wasn't needed). When reading slim TZif files, zdump no longer mishandles leap seconds on the rare platforms where time_t counts leap seconds, fixing a bug introduced in 2014g. zdump -v now outputs timestamps at boundaries of what localtime and gmtime can represent, instead of the less-useful timestamps one day after the minimum and one day before the maximum. (Thanks to Arthur David Olson for prototype code, and to Manuela Friedrich for debugging help.) zdump's -c and -t options are now consistently inclusive for the lower time bound and exclusive for the upper. Formerly they were inconsistent. (Confusion noted by Martin Burnicki.) Changes to build procedure You can now compile with -DHAVE_MALLOC_ERRNO=0 to port to non-POSIX hosts where malloc doesn't set errno. (Problem reported by Jan Engelhardt.) Changes to documentation tzfile.5 better matches a draft successor to RFC 8536 <https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/01/>. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2021b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2021b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2021b.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: 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 9ffa3f6e5019dfa7cfb5c0e4e8a84fa95adec704 dated 2021-09-24 16:23:00 -0700 and tagged '2021b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 00fca7508cfbc42123065fe8087397c9dd2acbdda96f3bb0936187825348cf13538f1893f2d02bd8bfa3465427ca7a9a65451baffe39889bc58ba0a77a047806 tzcode2021b.tar.gz ca61d64af5ae791f337533c09d2b4f7caa645ecab7b9d13e9bcafc47c7c68535abe7c103c56bbd41d6bd913a8607f9c5187c8ce8a91b4891a750a643f89c8b51 tzdata2021b.tar.gz 326fb99666c8d5bb798a9c24d2869307620dce918d47fbedd7f765c91eb35ea44bf776f43cb00cde1944884150232ac6dcdc0194a0364e2d28f6470691cf9177 tzdb-2021b.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFOX/wACgkQ7ZfpDmKq fjRKwA//RVH1mmf13Uz99KBQZMc/meVaYT1YSpMqilocZo1w+i+Omai7Aw/r9u1e lnwLQukqjpCH4TJWdq8VuloL5ojN1ImoZuIRYECWRHOShxMaS9DLkPRr4qA9Fxic hladneiIglVrnzQbG4pH0Vnu9Qakb6I+1um8lCNiJHng84y5KAOIcZu1m9O+A1F1 bdik8Ddxc4qBluUvcq9n9aqWSgDBvIyCYik6bOo3lOd5zP1rcjSr8VJ+15cAkH4X hU/igj9qloyqAmoOyJOzIIwv63T3Xg63rH/V2hJWyux54ayP4Kt8nZqLYA9V8gFI V/HL5qNafSYEqguO2H3hTwURc3Utini8Oa2Ou89Ih0hkO+nySacc0ZnhaunmX7Ip D5Oj6A8kssG0Uj5fZqpqUp1FeRbziAinSdwTOpRxdkdeHI6tfS0XVnRvRiFATfTu oh9107e3okwKAb2UPJtr8Oev0uU8rz8+EorN9/PqJv0n2c3I69NUv6TudFVHM8uB lwG3hUNtWWYpK/rzwX8AQkwTrOHMN3VJ94T8xaTm13/jtk6R/+GgSjXKC2C9XZG6 5uvi6et06WnRVRO+V5TwnQdfY85pe5nqRDLeo0clxdkAvx6fslLpz9YNacLV/Gn8 0UIGt9CBKjE+PU1F5w+O/5btA/1aTojuSpKscdzgQIzXTfDlTZo= =+McC -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFOX/0ACgkQ7ZfpDmKq fjRYmg/9H3rMpV7uQdd+G2K0wybdzTH6vJiNQClWE1+wqCPh/L3e8kCbPIjSo7MF SFV/Pu4EDb9kjeA2ruEMYlLnpg5nTP7dYfFRsRDcQJ5Yw70luNImm1ipUkKr9o5Q oQqYFKzxvB0G1rE+/gMaxmCHtGaJnv0DEChhmAS5U4j48z71Fn3+UJIU9XPEaODD U1Fw62xDsxIlFKjZ9UvilhlVRMnnP5nK9hjrsFKn7OGbxYvkdaRoK5f3M+G5nGXh L9nZcE0cd/7zhD3+wlttcH+xw3b+5P+7sxMhucoWQXEl3KyIklh97fi7jzHBHz+s DRYLZv/yPoEp94QyCfaYdvWL/i4OX4/9YnXK3ruXDcEV2y8Zl7Wc70Ihxk3I2XAb S4YeMcb30uls93QUdSmuhpEEUWrS5e45OnPy9RnT/VnpCalxsukudSNRzuvivKZn TsPpf90VUtI9ncLZ4l7OoNVXSj5pJ6DS+V1nCesEQyfyFnFvgK/rogCZ0yt+Cosp zaXwBtGyOWwWsGgXHGdJoiQqt/FF8o387EL95vpFr9BRSdSQoKd6K9RrRIH9fuy/ nnpaksD86fx+WbdLMtbHzsZgCqL1RTGO+kc35Qlr3vqH02UAZiwC9l3DHS9SA01c MGDy9zaiLsL/8/lUV3AP31dEP1+DY+BXvdFhIJkmIceBUf7zl0E= =PO3W -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmFOX/4ACgkQ7ZfpDmKq fjSaPg//ZlKREhlxjnstpEl6W3x4sStpUrF/Kebp62txYoCjbK22EDnw4BbE0wFh BcIBGbfxioC2+1gAjG57LK0RzTqFPPuDA69qYIZFk+xLrREISDqrGHViLGkFEgm5 jEDamuGW59UoBdnu4Klp1JAd7hvYQYEbbVaIVsrUlAL99OTyujeA6QoZdIjM43eh jx4g1P/XuHBqJEH7d9kOM5tBCRvgFhhcu/s4vOvrfFibRHRimYBuPlep5nJ88bb/ UyCQ1oYIQucWtl+DOszICl/GTmuM33FMTeAX6OrlGxwON6KPI2qNzAaQVpK1apB/ qF9dTnOVP8pygW6HkiFwNOKx4mplB2V8f1eqLT9mfdOQsEWPRuDyUvejBIr/Hmww jHF1w9TX8FxND2KQmcfZNTlKqYcw1O8Vz4m+0UnDzNuLiZAsnTBTrfnKMnVrTOFt 1K6KKK+v5y4WYu+pE36cIBM2YxITEpD+YrRr7G1ilzVgRH5FRGCJsxJu0O+BO35z rv9qVnJz0xISMJs+qSdJT8v4W4Uc6+crnHjAc7T7eAin3i3y/GY/MA44isCACmhx +Rq165laaHXnqTOgQfHhGjigJoH3JCnDYUwg6q+fMMBU2eALkOs+IbgdfVB3hoyo UOlYH/A25nuI0PrRgUKsN6N2lrfPjq3bM4twDw33BOyGJ/LN88w= =aNBd -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. 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'.

17 26

Discussion on LWN on the equity controversy
by Sanjeev Gupta Oct. 1, 2021

Oct. 1, 2021

Folks, On Linux Weekly News (which actually is about more than Linux), there is a summary and discussion on the issues raised here. LWN has a very high signal/noise ratio, I find. I have been a paid subscriber for a couple of decades. Here is a link (LWN allows subscribers to generate a link to an article for viewing by non-subscribers, all content s free after a week): https://lwn.net/SubscriberLink/870478/9dcc3764b87edfaf/ Thanks, -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane

2 1

Dropping coordinates from zone1970.tab?
by Aurelien Jarno Oct. 1, 2021

Oct. 1, 2021

Hi, With the recent changes, geographically distant locations share the same timezone and the same coordinates in the zone1970.tab file. For instance Antarctica/Syowa is a link to Asia/Riyadh and appear with the same coordinates in the zone1970.tab file, while they are more than 10000 km apart. The zone1970.tab says: "This table is intended as an aid for users, to help them select timezones appropriate for their practical needs". I have the impression that the coordinates in that table do not anymore aid users to select appropriate timezones, so I wonder if they should just get dropped. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien(a)aurel32.net http://www.aurel32.net

4 16

[PATCH] Formatting of NEWS file is inconsistent in 2021b
by Paul Ganssle Sept. 30, 2021

Sept. 30, 2021

All previous entries in NEWS have a format of headings following nested levels of indentation — the release is unindented, then subheadings with a 2-space indentation, then the contents of each subhead are blocks indented with 2 spaces. In the 2021b release, there is some commentary about the release that isn't indented to the level of the "Briefly" sub-block, but also doesn't have its own heading. I think it would be preferable to put this note under a heading rather than as free-floating content at the level of other subheads. I've attached a patch to move the note into the "Briefly" subheading, though it could also be a separate heading like "Note about the 2021b release" or something. I don't really expect this format to be guaranteed or anything, but for selfish reasons I liked the consistency of the previous format since it makes it much easier for me to parse the NEWS file for repackaging in the Python tzdata format. Obviously I do not consider this any sort of contract or required interface, but since it seems unlikely that accepting this patch would increase your maintenance burden and it will decrease my maintenance burden by a decent amount in the future, I'm hoping you wont' mind accepting this patch (or a similar one). Thanks! Paul

2 1

(no subject)
by Cool Gab19 Sept. 30, 2021

Sept. 30, 2021

I knew that we do already have a time zone for Philippines, Asia/Manila called "Philippine Standard Time" with an offset of UTC+8:00 but the other one I was requesting is for the body of water surrounded inside the mainland such as the Ocean or Sea. I'm proposing to add UTC/GMT+8:15 to your database We do have an 8:30 and 8:45 zone. Why not 8:15? Plus,and if there's an specific location it's Asia/Philippines with different abbreviation "Philippine Pacific Time" with offset of UTC+8;15and will be used inside Philippine sea (not in mainland)

2 1

something wrong with 2021b zdump
by 大山俊成 Sept. 30, 2021

Sept. 30, 2021

I compared 2021b with 2021a. The result is following. I don't understand the meaning for line 3-5,20-22 of 2021b result. Is it correct ? *** tzdb-2021b $ ./zdump -v Pacific/Honolulu Pacific/Honolulu -9223372036854775808 = NULL Pacific/Honolulu -67768040609740801 = NULL Pacific/Honolulu Thu Jan 1 00:00:00 -2147481748 UT = NULL Pacific/Honolulu Thu Jan 1 10:31:25 -2147481748 UT = NULL Pacific/Honolulu Thu Jan 1 10:31:26 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-37886 Pacific/Honolulu Mon Jan 13 22:31:25 1896 UT = Mon Jan 13 11:59:59 1896 LMT isdst=0 gmtoff=-37886 Pacific/Honolulu Mon Jan 13 22:31:26 1896 UT = Mon Jan 13 12:01:26 1896 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:29:59 1933 UT = Sun Apr 30 01:59:59 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:30:00 1933 UT = Sun Apr 30 03:00:00 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:29:59 1933 UT = Sun May 21 11:59:59 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:30:00 1933 UT = Sun May 21 11:00:00 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:29:59 1942 UT = Mon Feb 9 01:59:59 1942 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:30:00 1942 UT = Mon Feb 9 03:00:00 1942 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 13:29:59 1945 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 13:30:00 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:29:59 1945 UT = Sun Sep 30 01:59:59 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:30:00 1945 UT = Sun Sep 30 01:00:00 1945 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:29:59 1947 UT = Sun Jun 8 01:59:59 1947 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:30:00 1947 UT = Sun Jun 8 02:30:00 1947 HST isdst=0 gmtoff=-36000 Pacific/Honolulu Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 13:59:59 2147485547 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 67768036191676800 = Wed Dec 31 14:00:00 2147485547 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 67768036191712799 = Wed Dec 31 23:59:59 2147485547 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 67768036191712800 = NULL Pacific/Honolulu 9223372036854775807 = NULL *** tzdb-2021a $ ./zdump -v Pacific/Honolulu Pacific/Honolulu -9223372036854775808 = NULL Pacific/Honolulu -9223372036854689408 = NULL Pacific/Honolulu Mon Jan 13 22:31:25 1896 UT = Mon Jan 13 11:59:59 1896 LMT isdst=0 gmtoff=-37886 Pacific/Honolulu Mon Jan 13 22:31:26 1896 UT = Mon Jan 13 12:01:26 1896 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:29:59 1933 UT = Sun Apr 30 01:59:59 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:30:00 1933 UT = Sun Apr 30 03:00:00 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:29:59 1933 UT = Sun May 21 11:59:59 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:30:00 1933 UT = Sun May 21 11:00:00 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:29:59 1942 UT = Mon Feb 9 01:59:59 1942 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:30:00 1942 UT = Mon Feb 9 03:00:00 1942 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 13:29:59 1945 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 13:30:00 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:29:59 1945 UT = Sun Sep 30 01:59:59 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:30:00 1945 UT = Sun Sep 30 01:00:00 1945 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:29:59 1947 UT = Sun Jun 8 01:59:59 1947 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:30:00 1947 UT = Sun Jun 8 02:30:00 1947 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 9223372036854689407 = NULL Pacific/Honolulu 9223372036854775807 = NULL ---- Toshinari Ohyama

2 2

Merged 1970+ time zones should always return -1 pre-1970
by Brian Inglis Sept. 29, 2021

Sept. 29, 2021

I think for all zones with data merged prior to 1970, the data and API should always return *-1* for all times prior to 1970-01-01 00:00:00Z, as anything else is inaccurate or a kludge. Arbitrary disposition of any valid historical data is itself really political, for ease of administration, not really technical. I firmly believe that no decision on the list has ever been made on a basis of in-/equity or un-/fairness, as those would be political decisions, and we have bent over backwards for years to avoid any such appearance never mind actuality, devoting probably the majority of the volume of posts and the majority of the volume of words to such discussions. I have always taken the position that any churn not necessitated by changes on the ground (or government offices) is detrimental to the project and the database, and places a massive burden on downstreams who make good use of that data, including the CLDR and ICU projects, astronomy and astrology applications, all facets of the transportation industry, the databases they maintain, and the storage of what was the truth at a previous point in time, and future application uses of that previously stored data. Any such churn should be mediated by the request the list makes of time zone decision makers: to provide adequate notice of such changes, at least six months, preferably longer. I can only believe that the adminstrators of this database are under some form of political pressure (perhaps /only/ "vitriol in private email", which appears to be nearing the norm in certain arenas) to dispose of some data to achieve some misguided form of "equity" and "fairness", in response to some misguided perception of "inequity" and "unfairness" that is not apparent to members of this mailing list, and from the reactions, nor does it appear to have been adequately or clearly expressed in a form that members of this list can readily comprehend, nor is it clearly exactly when these political terms entered the discussion, nor what business they have being in it. As in any project where decisions are questionable, it is necessary to back off making any! The proposers of drastic changes need to enunciate clearly: * exactly what technical problem they perceive, and why it appears to be a problem; * some alternative options for technical solutions and/or approaches to address the technical problem; * how each alternative option for technical solutions and/or approaches to address the problem will satisfy the majority of needs of the majority of the stakeholders, and impacts on those unsatisfied; * why they think the option they propose to adopt is the best and most comprehensive solution to address the problem, and satisfies the most needs of the most stakeholders. This is standard practice in most commercial projects. It is often used when stakeholders can not quickly make a decision, decide on policy, or easily change policy. It allows development to proceed in parallel on all the offered options. When stakeholders finally decide or act, perhaps months along the timeframe nearing release, the selected option can be preferentially enabled, possibly with only minor tweaks or just data changes, and quickly regression tested to ensure the effect is precisely as desired. Of course, the best decision to satisfy the most needs of the most stakeholders is often the decision to just say "NO !" ;^> -- 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 binary units and prefixes, physical quantities in SI.]

9 15

Using the tzdb: What's actually changed
by Watson Ladd Sept. 29, 2021

Sept. 29, 2021

Dear all, I see lots and lots of people who seem to be running applications that care about pre 1970 timestamps and don't use backzones, or seem to ignore links. Well, if you ignore links you deserve what you get: it's been documented that zones may become links. The size of tzdb has already caused problems for some embedded devices. Post-1970 correctness only strikes me as very reasonable. Applications that need more should use backzones, and this has been true for years. If you care about the truth of what time something happened, and it was recorded in local time, and the zone that it was in might need to get split in the future, and that split could change when the time was or other times you care about then the database isn't your problem, reality is. I see a lot of complaints, and very few details about the applications affected. Which makes me skeptical they actually exist. Remember, you're only affected if you deal with pre-1970 timestamps. Sincerely, Watson -- Astra mortemque praestare gradatim

4 5

[PATCH] Port better to >64-bit platforms
by Paul Eggert Sept. 29, 2021

Sept. 29, 2021

* zic.c (limitrange, writezone): Use max_time instead of ZIC_MAX when dealing with timestamps that would go into the TZif file. The distinction matters only on very unusual platforms where int_fast64_t is wider than 64 bits. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index c6feb8b..224cc22 100644 --- a/zic.c +++ b/zic.c @@ -1990,7 +1990,7 @@ limitrange(struct timerange r, bool locut, zic_t lo, zic_t hi, /* Omit ordinary and leap second transitions greater than HI + 1. */ - if (hi < ZIC_MAX) { + if (hi < max_time) { while (0 < r.count && hi + 1 < ats[r.base + r.count - 1]) r.count--; while (0 < r.leapcount && hi + 1 < trans[r.leapbase + r.leapcount - 1]) @@ -2205,7 +2205,7 @@ writezone(const char *const name, const char *const string, char version, error(_("too many transition times")); thistimelim = thistimei + thistimecnt; - if (thistimecnt && hi_time < ZIC_MAX + if (thistimecnt && hi_time < max_time && ats[thistimelim - 1] == hi_time + 1) hicut = false; memset(omittype, true, typecnt); -- 2.30.2

1 0

Request
by Cool Gab19 Sept. 29, 2021

Sept. 29, 2021

I'm proposing to add UTC/GMT+8:15? We do have an 8:30 and 8:45 zone. Why not 8:15? Plus,the GMT+8:15 if ever will be named as Anywhere on Southeast Asia Time (ASAT) (Asia/Southeast) a very usable time zone in southeast asian countries specially in zone 7 and 8.

2 1

Re: [tz] [EXTERNAL] [tz-announce] 2021b release of tz code and data available
by Paul Eggert Sept. 28, 2021

Sept. 28, 2021

On 9/28/21 5:57 AM, crdrequest(a)ups.com wrote: > I was informed that the start Jordan now starts DST on February's last FRIDAY.....NOT THURSDAY. My guess is that you're OK because your informant referred to 00:00 on February's last Friday, which in 2022 is equivalent to what we have in tzdb 2021b (namely, 24:00 on February's last Thursday). The distinction between the two rules matters only in one year out of seven, the first such year being 2024 when February ends on a Thursday. Our source for the 24:00-on-last-Thursday rule is here (in Arabic): https://petra.gov.jo/Include/InnerPage.jsp?ID=189969&lang=ar&name=news

1 0

Why 2021b needed to be issued
by Paul Eggert Sept. 28, 2021

Sept. 28, 2021

Since 2013 I've been patching tzdb by replacing Zones with Links when Links suffice according to the guidelines. These patches have not affected timestamps after 1970. I've been doing this gradually. The changes have worked without significant incident, partly because end users generally don't care about pre-1970 timestamps, and partly because the few users who do care (astrologers, mostly) know or should know that the pre-1970 Zone data entries are often wrong and even when right are typically grossly inadequate for realistic use outside the named location - this is partly why any focus on pre-1970 is out of scope for tzdb. Preparing all these patches has been a big enough job that I've been doing it gradually since I have limited time. This process was discussed on the list before it began, and although there was some objection, a consensus to move towards these goals was reached at the time. Most of this job was done before 2021a came out. The main difference in this round of patches, is that I had aimed to complete the job, in response to a user query raising equity concerns in 2021a. It is clear that the 2021a setup was not sustainable in the long term, if equity is a goal. Completing the job generated larger patches than usual, and the patches' size triggered concern that they held too many changes all at once. Also, the patches' effects on pre-1970 timestamps in (for example) Norway and Sweden have triggered concerns, much more so than similar changes made (for example) to Angola and Congo in tzdb 2014g. My own view is that we've done this before, many times, it hasn't been a problem in practice, and it's way past time to address the equity concerns as they have a good chance to really bite this project and its repackagers in the future. It's a bad look for us that so much concern about Norway and Sweden has appeared on this mailing list, even though hardly anybody seems to have cared about Angola and Congo. It'll be an even worse look if we ignore this issue weeks, months or even years after it's been made clear to us. I wrote, tested and published several concrete suggestions addressing the fairness problem. In the months since May when the fairness problem was discovered and objections to my proposed fixes were raised, no other concrete fix addressing both of these concerns has been implemented or tested, and all other suggestions made so far would have required significant work, if they would have worked at all, or would have caused more data churn than what I proposed. I realize that there are valid concerns about installing too many of these patches at once, so 2021b affects only nine Zones instead of the thirty-odd Zones in my May proposal. The idea is to do further patch sets in not-too-distant-future releases, so that the job can finally be finished. I also recognize that there are other forms of equity and fairness that should be considered, perhaps along with alternative technical solutions to the problems these patches address. With all this in mind, issuing 2021b now is a significant step toward equity in tzdb. It will let us say that we are moving toward a fair process, and will give us the opportunity and motivation to improve on that process and to address and balance the various other concerns that have recently appeared on the mailing list.

3 3

Preparing to fork tzdb
by Stephen Colebourne Sept. 27, 2021

Sept. 27, 2021

Hi all, As most of you probably know, there is a dispute about the tzdb maintainer's recent changes to merge large numbers of time-zones [1][2]. These have the effect of wiping out historic time-zone information on many locations where the data has been in tzdb for many years. It appears that there is soon to be a new release of tzdb containing these changes. In my opinion, the correct behaviour of the tzdb maintainer would be to revert the controversial changes before doing a release. In the event that the tzdb maintainer does not revert, consideration must be given to forking the project. The purpose of the fork would initially be to maintain the tzdb data set as it was prior to the dispute. This would then be released in parallel to the original tzdb to ensure that downstream projects do not each do their own thing (ie. to minimize incompatibilities downstream). Is there support for a fork? Is anyone willing to help out? Is any other group willing to sponsor tzdb (eg. CLDR or Red Hat)? Please reply to this thread with an indication of support and/or help. thanks Stephen Colebourne [1] https://mm.icann.org/pipermail/tz/2021-June/thread.html [2] https://mm.icann.org/pipermail/tz/2021-September/030372.html

31 151

Re: [tz] Preparing to fork tzdb
by dpatte Sept. 27, 2021

Sept. 27, 2021

Most people in the Americas who live outside 'america' would prefer it being 'Americas', 'North_America' or better yet, just the iso country names.Sent from my Galaxy -------- Original message --------From: Paul Eggert via tz <tz(a)iana.org> Date: 2021-09-26 20:44 (GMT-05:00) To: Brooks Harris <brooks(a)edlmax.com> Cc: Time zone mailing list <tz(a)iana.org> Subject: Re: [tz] Preparing to fork tzdb On 9/22/21 11:32 AM, Brooks Harris via tz wrote:> Olsen's original insight to use towns and cities to name time zones > turns out to be extraordinarily useful.As a historical note, the naming convention you're talking about is something I originated and contributed to tzdb in 1993. Although I began with more-complicated names like Pacific/Fiji/Suva and North_America/US/Los_Angeles, the country names (and the "North_") were more trouble than they were worth, so I removed them before sending patches for Arthur to install.One of my early emails about my idea concluded that "It looks like this will take some time." Which it has.https://mm.icann.org/pipermail/tz/1993-October/009233.html

1 0

Samoa awakes to time change confusion
by Paul Eggert Sept. 27, 2021

Sept. 27, 2021

The Samoa Observer's James Robertson reported today that much of Samoa woke up in confusion today as mobile phones, computers, and other cellular-enabled devices displayed the time as 10:00 when it was in fact 09:00. Many reportedly arrived at church early because their cell phones incorrectly sprang forward. An anonymous employee at Digicel said that Digicel hadn't been given enough notice. Vodafone Samoa apparently did not respond to media inquiry. The Observer's Marc Membrere reports tomorrow that the president of the Samoa Information Technology Association (S.I.T.A.) criticized the government for not consulting tech experts about the effect of changing DST rules with so little notice. ---- Robertson J. Nation awakes to time change confusion. Samoa Observer. 2021-09-26. https://www.samoaobserver.ws/category/samoa/92122 Membrere M. "Daylight savings change rushed: S.I.T.A." Samoa Observer. 2021-09-27. https://www.samoaobserver.ws/category/samoa/92126

1 0

Re: [tz] [tz-announce] 2021b release of tz code and data available
by Paul Eggert Sept. 26, 2021

Sept. 26, 2021

On 9/26/21 3:38 AM, Michael H Deckers wrote: > Link America/Port_of_Spain America/Virgin > in line 755 of backzone should be converted to > Link America/St_Thomas America/Virgin That would create a link-to-a-link (America/Virgin → America/St_Thomas → America/Puerto_Rico), which would cause "make check_links" to fail. This maintainer check was put in several years ago, when some downstream software misbehaved with a link-to-a-link in one of our releases. And I suspect that even zic is not robust in the presence of arbitrary links-to-links, though I haven't tested this. I do see the semantic issue behind the change you're proposing, as America/Virgin is an old alias for America/St_Thomas. If we wanted to add support for links-to-links, I suspect someone would have to code up and test changes to zic.c, and we would definitely need to give downstream users considerable time to adjust to the change. I'm not sure it's worth it merely to support this very minor issue.

2 2

Replacing the TZ Coordinator
by Stephen Colebourne Sept. 26, 2021

Sept. 26, 2021

The TZDB project is guided by RFC 6557. Section 4 allows the list to seek an alternate TZ coordinator where "The TZ Coordinator is not performing the function in accordance with community wishes". https://www.rfc-editor.org/rfc/rfc6557.html#section-4 The RFC instructs as follows: Members of the community should raise the issue on the TZ mailing list and attempt to reach consensus on a new candidate to fulfill the role of TZ Coordinator. If rough consensus cannot be reached easily, the Area Directors of the IETF Applications Area should attempt to guide the members of the community to rough consensus. The candidate that is agreed upon by the community through rough consensus shall be presented to the IESG for confirmation. If rough consensus cannot be reached, even with guidance from the Applications Area Directors, the IESG shall use whatever means it has at its disposal to choose a candidate who in its best judgment will be able to fulfill the role of TZ Coordinator. Is there consensus on the list that a change is required? Is there a candidate willing to take on the role of TZ Coordinator? Stephen

28 40

Some thoughts about the way forward
by Tom Lane Sept. 26, 2021

Sept. 26, 2021

A modest proposal, if I may. Let's take it as read that Paul is going to stick to his guns about the May reorganization --- he's certainly shown no willingness to do otherwise. (I do accept that there are valid reasons for that move, even if I differ as to their importance.) What do we need to do to mitigate the undesirable consequences of that reorganization? After chewing on this for awhile, it seems to me that the really fundamental undesirable consequence is going to be inconsistent received versions of tzdb. Currently, the usage of backzone seems to be quite negligible [1]. But I fear it is certain that some platforms will start using backzone, in order to placate users who are negatively affected by the May changes. That will mean that those platforms will start showing different results from platforms that don't do that, for all zones in backzone (both old and new). I rate this outcome as disastrous on multiple levels, not least being the damage to the credibility of the tzdb project itself. To avoid that, I already proposed [2] that we drop the links in "backward" that are overwritten by backzone. This would have the effect that a non-backzone build would not offer those zone names at all, instead of presenting them as having the data content of some other zone. This would eliminate the issue of different platforms presenting different results for the "same" zone. If we do that, it seems probable that instead of some platforms adopting backzone, nearly all will, because otherwise their users will moan about their favorite zone being gone. I therefore further suggest that we make use of backzone be the default. Anybody who wants a "lean and mean" build can leave it out --- but they'll be presenting a clean subset of the data seen in the default build, rather than data that is different and known to be less good in some cases. This approach suggests that we make some adjustments in how we think about things. I think we ought to rename backzone to "extended" or something like that. We'd view tzdb as offering a "base" set of zones that are considered in-scope per the rule about different-since-1970, plus an "extended" set of zones that are out-of-scope and are not maintained as carefully as the base. (This really is just applying different terminology to the existing understanding about how backzone is maintained.) The primary advantage of doing it this way, rather than the way we're handling backzone now, is that it's a lot clearer to end users what the status of the extended zones is, and we're not confusingly offering two different versions of those zones. Assuming we make these changes before shipping git tip in its present form, we could expect that users in zones affected by the May changes would see no actual change in their TZ data. There would be a loss of data stability for users in the zones that were moved to backzone previously. I'm not terribly thrilled about that, but it seems like the least amount of damage to the least amount of people, compared to any other likely outcome. We could hopefully placate those users by pointing out that (1) the new data, while likely not perfect, is almost certainly a net improvement over what was shipped before, and (2) this is effectively reverting these zones to their pre-2015 state. We'd thus be acknowledging that the original implementation of backzone was a mistake, and undoing it with the least amount of side-effects we can manage. I shall now retire and wait to be shot at ... regards, tom lane [1] https://mm.icann.org/pipermail/tz/2021-September/030572.html [2] https://mm.icann.org/pipermail/tz/2021-September/030632.html

11 45

Re: [tz] Why 2021b needed to be issued
by dpatte Sept. 26, 2021

Sept. 26, 2021

Agreed.Sent from my Galaxy -------- Original message --------From: Stephen Colebourne via tz <tz(a)iana.org> Date: 2021-09-25 12:40 (GMT-05:00) To: Time zone mailing list <tz(a)iana.org> Subject: Re: [tz] Why 2021b needed to be issued "On Sat, 25 Sept 2021 at 06:23, Paul Eggert via tz <tz(a)iana.org> wrote:> The main difference in this round of patches, is that I had aimed to> complete the job, in response to a user query raising equity concerns in> 2021a. It is clear that the 2021a setup was not sustainable in the long> term, if equity is a goal.Equity is not a formal goal of the project. It is not documented oragreed in the RFC nor in the theory file. Your opinion of what isequitable does not align with mine.> Completing the job generated larger patches than usual, and the patches'> size triggered concern that they held too many changes all at once.Having read hundreds of emails over the past few months, I don't think*anyone* expressed the concern of patch size or too many changes.> Also, the patches' effects on pre-1970 timestamps in (for example)> Norway and Sweden have triggered concerns, much more so than similar> changes made (for example) to Angola and Congo in tzdb 2014g.It may not be pleasant to accept, but I would strongly argue thatplaces like Norway, Denmark, Sweden and the Netherlands are much moresignificant to the world economy than Angola and Congo. You simplycannot judge the impact based on what has happened before. Inaddition, the pre-1970 data being removed now is much betterresearched than much of what has previously been removed.> I also recognize that there are other forms of equity and fairness that> should be considered, perhaps along with alternative technical solutions> to the problems these patches address.Thank you for the acknowledgement.In summary, I am livid with the high-handed approach you have takenwrt the release of 2021b. Despite near unanimity of the mailing listrequesting you to release 2021a+MinimalChanges, you progressed 9 outof the 30 link merges based on a rationale that you acknowledge is notuniversally accepted.I believe your actions are against the spirit of the RFC, if not theletter (as decided by the IESG), as you "SHOULD take into accountviews expressed on the mailing list".I will now take a break from this matter for a long weekend, as thelist has requested. Later next week I will try to start a positivediscussion as to what the next steps can be.Stephen

1 0

Atlantic/Jan_Mayen, Arctic/Longyearbyen and Europe/Berlin
by Chris Walton Sept. 25, 2021

Sept. 25, 2021

Paul, 1. For the record, I detest the practice of linking zones across different ISO-3166 regions. Forcing one country to be associated with another country is politically and culturally offensive. 2. In 2021b you have: Atlantic/Jan_Mayen linked to Europe/Berlin. Arctic/Longyearbyen linked to Europe/Oslo. This seems inconsistent to me. If you insist on keeping Atlantic/Jan_Mayen linked to Europe/Berlin, then I think that the Europe/Berlin entry in zone1970.tab should show "DE,SJ" instead of just "DE". -chris

2 1

proposal for new tzdb versions
by Paul Eggert Sept. 25, 2021

Sept. 25, 2021

In light of the previous discussions and the fact that we need a new release very soon, I propose the following: * We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS). * We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA. Although this is effectively a fork in the short term, the idea is that it's a small fork with the intent that we'll work together to combine the two approaches in later releases, taking the abovementioned concerns into account. There is precedent for this approach, in that when there were compatibility problems with earlier releases, I generated alternate tarballs to support downstream users while they were adapting their database readers. Although the two cases are not the same, generating an alternate distribution also has the benefit of giving us time. Although I haven't had time to read all the discussions so far (and email is still rolling in), I will try to take these discussions into account when writing the NEWS entries for the two versions. After the versions are published and the dust has settled, I hope that we can incorporate some of the suggestions that have been made, as we will then have time to implement and test them. I don't want this followup discussion to take a looong time, though, as the goal is to combine the two approaches soon. Since Samoa's rules change in less than 72 hours I plan to generate these new versions soon.

17 30

Re: [tz] Some thoughts about the way forward
by Kerry Shetline Sept. 24, 2021

Sept. 24, 2021

I’ve written code myself that depends on regex patterns (4 digits followed by one or two letters) to match timezone version numbers, so I definitely would not want to see the version formatting change, at least not abruptly and without plenty of lead time before the first version numbers in any new or modified format appear. > Specifically, this is what is documented and this is what our software supports: > >> Since 1996, each version has been a four-digit year followed by lower-case letter (a through z, then za through zz, then zza through zzz, and so on) > > Deborah

1 0

Re: [tz] Preparing to fork tzdb
by Shawn Steele Sept. 24, 2021

Sept. 24, 2021

(I subscribe to digests - though as many of those have been sent recently, it doesn't feel like a digest 😁) It's one thing to have a zone that has "always" behaved this way, and another to have folks feel like it was "taken away" from them. The first may have begrudging acceptance, but the second is harder to come to terms with. I confess the identifiers always bug me a bit when I don't actually live in the place being identified, but that's closest to my time zone. -Shawn ------------------------------ Message: 2 Date: Fri, 24 Sep 2021 00:43:26 -0700 From: Paul Eggert <eggert(a)cs.ucla.edu> To: Stephen Colebourne <scolebourne(a)joda.org>, Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Preparing to fork tzdb Message-ID: <3c8e2714-752c-83f3-fafd-61fd796c7353(a)cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed On 9/23/21 6:07 AM, Stephen Colebourne via tz wrote: > the solution adopted (creating Links > where previously there were Zones) has created a *different* equity, > diversity or inclusion issue. That's not a new issue. We've dealt with it many times, by dealing with questions like "How come there's no Asia/Beijing Zone?" When the issue comes up we point to the guidelines, which are based on timekeeping rather than traditional political issues. Although we can't expect the guidelines to be familiar in advance to everyone who asks such questions, explaining the guidelines hasn't been much of a problem in practice.

1 0

2021b v 2021a1
by Michael Douglass Sept. 24, 2021

Sept. 24, 2021

I suspect the requests to have 2021b be 2021a+Samoa are reasonable - whatever view one has of Paul's changes and reasons. Internal processes of large organizations are not easily changed and modifying processes to accept 2021a1 will lead to all sorts of churn. I'd request: a: Paul move his changes to a branch and release 2021b as 2021a+Samoa b: Everybody take a break - at least for a (long) weekend c: Ratchet down the fury when we get back. Just my personal view,,,

8 7

DST in Jordan to start in February instead of March
by Steffen Thorsen Sept. 24, 2021

Sept. 24, 2021

The Jordanian Government announced yesterday that they will start DST in February instead of March: https://petra.gov.jo/Include/InnerPage.jsp?ID=37683&lang=en&name=en_news (English) "The Cabinet decided on Thursday to move the Kingdom's annual switch to summertime from the end of March to the end of February. The cabinet kept the switch to wintertime at the end of October. Clocks are to be set back by 60 minutes as of 1am of the last Friday of October every year, bringing the Kingdom two hours ahead of Greenwich Mean Time, while they will be set forward one hour on the last Thursday of February as of next year." https://petra.gov.jo/Include/InnerPage.jsp?ID=189969&lang=ar&name=news (Arabic) From the Arabic version, it seems to say it would be at midnight (assume 24:00) on the last Thursday in February, starting from 2022. There are a few news articles about it too: https://www.jordannews.jo/Section-109/News/Daylight-savings-now-starts-from… https://menafn.com/1102853678/Switch-to-summer-time-moved-a-month-earlier-t… Regarding the discussion on the future of backzone etc: My vote would also go for doing 2021a + just the necessary Samoa (+Jordan) patches in a 2021b until an agreement is made that is working well for everyone. We also depend on backzone data to be present somehow. Best regards, Steffen - timeanddate.com

2 1

Re: [tz] Preparing to fork tzdb
by Gerardo Ballabio Sept. 24, 2021

Sept. 24, 2021

Stephen Colebourne wrote: > On Thu, 23 Sept 2021 at 09:52, Paul Eggert via tz <tz at iana.org> wrote: > > On 9/22/21 2:53 AM, Almaz Mingaleev wrote: > > > What equity, diversity or inclusion issues were in 2021a? > > > > Locations in countries like Norway and Sweden got special treatment by > > being Zones, whereas locations in countries like Angola and Ethiopia > > were only Links. > > Taken at face value, it is easy for anyone reading this to nod their > head and agree that Norway should not receive favouritism over Angola. > > What it fails to state is that the solution adopted (creating Links > where previously there were Zones) has created a *different* equity, > diversity or inclusion issue. The resulting tzdb state clearly favours > Berlin over Oslo or Stockholm, Brussels over Amsterdam. Guys, PLEASE!!! That is ridiculous. Stop that madness. The distinction between Zones and Links is an internal implementation detail. It makes no practical difference [*]. Why should users care whether their location is a Zone or a Link? Why would they even need to know? If anybody actually complained about their favourite location not getting a "first-class treatment", I believe that "Get a life!" would be a fully deserved answer. [*] That changing an existing Zone to a Link might alter some data for that location is another issue that IMHO deserves consideration. Basically, it's a matter of deciding how much you commit to backward compatibility, and whether the impacted data are within the scope of that commitment. But that's completely orthogonal to the bogus "favouritism" issue. Gerardo

1 0

Issues with pre-1970 information in TZDB
by Stephen Colebourne Sept. 24, 2021

Sept. 24, 2021

(David Braverman recently asked for a summary of the issue. This is my attempt to summarize in a relatively even-handed way) The TZDB theory file starts with the following: "The tz database attempts to record the history and predicted future of civil time scales. It organizes time zone and daylight saving time data by partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch (1970-01-01 00:00:00 UTC. Although 1970 is a somewhat-arbitrary cutoff, there are significant challenges to moving the cutoff earlier even by a decade or two, due to the wide variety of local practices before computer timekeeping became prevalent." I have always thought this is a wise choice for the management of time zone data. I suspect that most people on this list would agree. The rules for creating new IDs where post-1970 data differs are well understood and, I believe, agreed upon. Apart from debates over negative daylight saving, I do not believe there are any significant issues with the data post-1970. Despite the theory file introduction above, TZDB does in fact contain data for some locations before 1970. The issue at hand is which timezone IDs are allowed to have this data and which are not. And more broadly, the degree to which it is acceptable to change the status quo on the pre-1970 data. Over many years, pre-1970 data was added to many different IDs. However, over recent years, pre-1970 data has been removed. (Technically, it has been moved to another file, but for the purposes of those consuming the main set of tzdb files it has effectively been removed.) The net result of recent changes are various situations which might be described as "cleaner", "more equitable", "nonsensical", "unacceptable" or "less equitable" depending on your viewpoint. For example, Europe/Berlin has pre-1970 data, but Europe/Oslo and Europe/Stockholm do not. In technical terms, Europe/Oslo and Europe/Stockholm are now aliases for Europe/Berlin (known as Links in tzdb). Where the problem lies is that a user who queries Europe/Oslo for the timezone offset in 1950 used to get the data for Oslo but will now get the data for Berlin. Depending on your viewpoint this is "irrelevant", "unfortunate" or "offensive". Why has the data changed? Because Oslo, Stockholm and Berlin all have the same timezone data post-1970, and Berlin is the largest city. The argument is that if only post-1970 data matters (as per the theory file), then there is no justification for three separate data sets when only one will do, and the one chosen is the one with the largest city. The counter argument is that merging data sets across country boundaries is unacceptable and politically naive, particularly when there were no complaints about the previous status quo. More broadly, different individuals, some representing organizations, have expressed different opinions on what they do or do not want from the tzdb data set. Some would like a full historical record of time zone data, others want stability, many I suspect have absolutely no interest whatsoever in pre-1970 data. My personal concerns are data stability (agreed managed changes are OK), and the politically-sensitive inaccuracy that results from merging across country boundaries. Can we keep responses limited on this thread? Perhaps only respond if you think I've mischaracterized the issues at stake here? Or missed something obvious? Stephen

17 72

Re: [tz] proposal for new tzdb versions
by Shawn Steele Sept. 23, 2021

Sept. 23, 2021

+1, it would be best if the 2021b had the minimal fix required to support the immediate timezone changes needed and defer additional cleanup/refactoring until the group has reached more of a consensus on how to handle the various concerns raised. -Shawn (I'll also confess to not having had time to catch up on ALL of the email flying around about this, however the passionate discourse by itself would seem to be an indication that we should take a step back and pause, making only the minimal changes required immediately.) ------------------------------ Message: 3 Date: Wed, 22 Sep 2021 11:52:20 -0700 From: Mark Davis ?? <mark(a)macchiato.com> To: Tom Lane <tgl(a)sss.pgh.pa.us> Cc: Paul Eggert via tz <tz(a)iana.org> Subject: Re: [tz] proposal for new tzdb versions Message-ID: <CAJ2xs_E8TMP7bhsjnM4QCCTGKDd8SnqW3bh-Am0jab3yJq0x5g(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" I agree with Tom's comments. We *really* don't want the disruption that would happen when some people pick up the 2021b and others pick up 2021a1; especially when it is likely that many of the people picking up 2021b won't know that they could be breaking downstream clients. There is *no* harm at all to just issuing a 2021b that has 2021a + Somoan fix right now (no other changes). That is the simple option for now. Then people have the opportunity to hash out the situation without disruption. Mark

1 0

An alternate framing of timezone maintenance
by Russ Allbery Sept. 23, 2021

Sept. 23, 2021

Over the past few days, I've felt like the framing of the discussion hasn't taken into account Paul's clearly expressed desire for the part of maintenance he wants to focus on, and has not attempted to incorporate that into a design that would preserve other properties that other mailing list participants are interested in. I've also wondered if all parties are making unnecessarily strong assumptions about the nature of tz maintenance that exclude potentially useful designs. In the hope of applying the maxim that all problems in computer science can be solved by adding a level of indirection, here's a wild proposal that, even if not workable as-is, might help in looking at the discussion from a different angle. One can think of the tz database as two layers. The first is a collection of rulesets that represent rules for clock changes in particular regions. Call that the timekeeping data set. The second is a many-to-one assignment of names to those rulesets. Call that the naming layer. The scheme used for the naming layer attempted to avoid politicization of that layer by using the continent and largest city approach. This was largely successful, particularly by the standards of attempts of this sort, but not entirely so. For years now, the tz project has in essence asked people to treat the zone names as opaque identifiers and not imbue them with political meaning. Unfortunately, because those identifiers embed real-world names with other meanings in other contexts, I believe this effort is doomed to never fully succeed. The names and spellings of cities are political. The choice of continent to which to assign a city can be political. Population counts are political. Readers of the mailing list can fill in more examples. However, the timekeeping data set, divorced from the naming layer, is as close to apolitical as anything involving laws and human practice could be. Putting aside timezone abbreviations, nearly all of the political conflict is over the naming layer, not the timekeeping data set. I believe Paul has clearly indicated that the part of the work that he wants to focus on is maintenance of the timekeeping data set. I would characterize his recent proposed changes as attempts to make the naming layer less political to reduce political arguments and thus allow more time and attention to be spent on the timekeeping data set, which is where the primary value of the project lies. The stability concerns that have prompted most of the recent discussion are almost entirely about the naming layer. Suppose we resurrect the idea of opaque timezone identifiers. Specifically, suppose that we *add* a new, random identifier, something like TZ0045 with random digits, to all existing rulesets in either the main database or backzone. These identifiers would be unique identifiers for the dataset itself, independent of any other names. These identifiers would immediately have some useful properties: 1. Historic times for a given identifier would change only if we discovered that the previous times were clearly erroneous. Apart from fixing discovered errors, historic times would be stable for any given identifier. 2. Looking forward, new identifiers may be added if portions of an existing region diverge in their timekeeping practices or if someone gathers new historical information that would prompt the creation of a new backzone ruleset, but that's the only possible change. Identifiers will never change or be retired. 3. These identifiers carry absolutely no additional political content on top of the rules themselves. In other words, they add no new political problems not inherent and unavoidable in the data itself. Adding these identifiers would nearly double the number of names in the current tz database, which is unfortunate, but certainly far less disruptive than the sorts of changes that have recently been considered. Once these identifiers exist, the combination of those identifiers and the timekeeping data set form a nearly apolitical collection of data to which a naming layer can be cleanly applied. One can, for example, define a naming layer that exactly corresponds to the naming in use in the previous release of the tz database. With the exception of the implementation detail that the previous names become links to a new canonical identifier, the combination of that naming layer and that conception of the timekeeping data set is functionally identical to the previous tz release (except for the normal sorts of modifications for on-the-ground timekeeping changes). This may sound like a lot of work just to get back to where we already are, but with a pile of new, ugly names. But the point of such a change is that it now permits a separation of concerns and even potentially a separation of maintenance. The timekeeping data set is now a separate artifact that those whose primary interest is in timekeeping data can focus on without having to get involved in political naming discussions. It achieves the goal that Paul has been working towards (but which is impossible to fully achieve with the current naming) of separating the data from political and historical decisions about who got a timezone name and who didn't. And (very slowly, of course) there is now the possibility for consumers of the tz database to opt out of the naming conventions. One could, for instance, choose a timezone based on selection from a map and have that correspond to the unique, permanent timezone identifier. Meanwhile, clearly there is a strong interest in the naming layer and a strong desire to continue to maintain it along lines that Paul is not entirely comfortable with. Recently, that discussion has focused on naming stability, but other parties have expressed other interests in the past (adding new spellings of cities, ensuring a name exists for every ISO-recognized country, ensuring a name exists for regional capitals that are commonly referenced locally as the name for a timezone, etc.). Nothing is going to make those discussions go away, as the past many years of discussions here have shown, but now they are separable from the timekeeping data set and participants can decide which part of the maintenance they're interested in. If Paul (or any other contributor) wished, he could choose to focus on the part of the project that he finds the most interesting and leave maintenance of the naming layer largely to other parties. Given recent mailing list traffic, there is obviously substantial interest in that naming layer and thus I'm sure there will be no shortage of volunteers to help maintain it. And those who make decisions about the naming layer can then also absorb the consequences of those decisions, such as handling arguments over the spelling of cities. It would even be possible (although not necessary) to move discussion of the naming layer to a separate mailing list to more clearly separate political discussion from ruleset maintenance and technical work on the associated code libraries. The naming layer, which is now nearly devoid of technical decisions, could even be delegated to a more political body that deals with these sorts of conflicts constantly and is thus better equipped to handle them than the tz mailing list. Numerous options like that become possible. Even if a maintenance split doesn't happen, I think everyone may benefit from cleanly separating the spectacularly high-quality resource of rulesets and their accompanying exhaustive references, discussion, and human-readable descriptions of applicable regions from the politically fraught but technically quite small and simple naming layer. This idea may not be workable for reasons that aren't obvious to me at nearly 4:00am, but hopefully it will at least provide a different angle from which to look at the current arguments and possibly achieve some clarity about which portions of the overall tz project people are interested in working on and where the exact controversy lies. -- Russ Allbery (eagle(a)eyrie.org) <https://www.eyrie.org/~eagle/>

5 8

FW: Re: Preparing to fork tzdb
by dpatte Sept. 23, 2021

Sept. 23, 2021

I should add that no research scientist expects all historical data to be perfect before publishing. History always gets murkier the further you go back. All historical data is in fact best-guess, published so it can be improved upon We should be providing a forum for this.. See below..Sent from my Galaxy -------- Original message --------From: dpatte <dpatte(a)relativedata.com> Date: 2021-09-22 18:32 (GMT-05:00) To: Guy Harris <gharris(a)sonic.net> Cc: Watson Ladd <watson(a)cloudflare.com>, tz <tz(a)iana.org>, Eliot Lear <lear(a)lear.ch> Subject: Re: [tz] Preparing to fork tzdb I don't believe anyone has suggested that zones should be limited to 'only one zone per country'. I certainly never sugested that. In fact quite the opposite. But I believe there should be AT LEAST one zone per iso country, and it was the removal of the Montreal historical data a few years back that got me started.If it's THE tz database, it should be able to provide not only since-70 history, but be expandable to all tz history, potentially back to the 1800s when most cities implemented local mean time as local standards.I recognize many users of this db dont need pre1970 history, and perhaps they could filter for only recent data. But many apps need UT (gmt) before 1970 as I mentioned. Think astronomy apps, for example.Up until recently some of this data was available in the main tz file. We need that back, with the ability to expand and improve it. This should be possible without expanding the post1970 table.Sent from my Galaxy-------- Original message --------From: Guy Harris <gharris(a)sonic.net> Date: 2021-09-21 21:02 (GMT-05:00) To: dpatte <dpatte(a)relativedata.com> Cc: Watson Ladd <watson(a)cloudflare.com>, tz <tz(a)iana.org>, Eliot Lear <lear(a)lear.ch> Subject: Re: [tz] Preparing to fork tzdb On Sep 21, 2021, at 4:51 PM, dpatte via tz <tz(a)iana.org> wrote:> Date: 2021-09-21 18:49 (GMT-05:00)> To: dpatte <dpatte(a)relativedata.com>> Cc: Eliot Lear <lear(a)lear.ch>, "Clive D.W. Feather" <clive(a)davros.org>, tz <tz(a)iana.org>> Subject: Re: [tz] Preparing to fork tzdb> >> On Tue, Sep 21, 2021 at 3:42 PM dpatte <dpatte(a)relativedata.com> wrote:>> >>> The strategy used since tz was created has caused many political arguments and decisions in this group instead of deferring the decisions to the ISO that has this mandate.>> >> ISO countries doesn't solve some of the thorny political issues,>> because ISO codes don't take a position on boundary disputes or naming>> disputes. E.g. Crimea. When the invasion happened, the civil time in>> the region occupied changed. That means a new zone entry needed to be>> created. I don't know how defering to ISO resolves the naming of that>> one.>> >> The other example would be Palestine. Regardless of what ISO decides,>> the time in Palestine is what it is, and is different from Israel in>> funny ways, and the territories that have gone back and forth have>> gone back and forth and thus need new entries.> > Incorrect..> > Iso 3166> > Ramallah is recognized in the State of Palestine.And Hebron, presumably - it's the city used for West Bank Palestine.> Sevastopol is recognized as a city as being in Ukraine.But it's not a city used for a tzdb - Simferopol is.And Kyiv is also a city in Ukraine, but, as far as I know, it keeps different time from Simferopol, and the tzdb recognizes that.However, "deferring to ISO" doesn't mean "providing one *and only one* tzdb region per ISO country"; such a policy would not work very well for the three largest countries listed in the northamerica file, for example.If, indeed, Crimea and the rest of Ukraine do not, in practice, keep the same time, then, hopefully, "deferring to ISO" also wouldn't mean "giving Crimea the same offset and rules as the rest of Ukraine".

2 1

Re: [tz] Preparing to fork tzdb
by dpatte Sept. 23, 2021

Sept. 23, 2021

The Montreal data was moved out because an error was discovered in the montreal data post 1970 which made it equivalent to Toronto. Great. The data was improved.But people still want a way of getting at the data for montreal pre 1970.Is the data editable within the backzone file?Sent from my Galaxy -------- Original message --------From: Guy Harris via tz <tz(a)iana.org> Date: 2021-09-22 19:53 (GMT-05:00) To: Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Preparing to fork tzdb On Sep 20, 2021, at 1:06 AM, Stephen Colebourne via tz <tz(a)iana.org> wrote:> As most of you probably know, there is a dispute about the tzdb> maintainer's recent changes to merge large numbers of time-zones> [1][2]. These have the effect of wiping out historic time-zone> information on many locations where the data has been in tzdb for many> years.The comment at the beginning of 2021a's backzone says:# From Paul Eggert (2014-10-31):# This file contains data outside the normal scope of the tz database,# in that its zones do not differ from normal tz zones after 1970.# Links in this file point to zones in this file, superseding links in# the file 'backward'.# Although zones in this file may be of some use for analyzing# pre-1970 timestamps, they are less reliable, cover only a tiny# sliver of the pre-1970 era, and cannot feasibly be improved to cover# most of the era. Because the zones are out of normal scope for the# database, less effort is put into maintaining this file. Many of# the zones were formerly in other source files, but were removed or# replaced by links as their data entries were questionable and/or they# differed from other zones only in pre-1970 timestamps.so it's not as if this is the first time that historic information has been moved to backzone, which, although not "wiping it out" in the sense of making it no longer exist in any form in the tzdb repository or releases, removes it from any collection of compiled tzdb files not build using backzone, and removes it from any data set that applications get by reading tzdb source files and not reading backzone.One example of data that's in backzone in 2021a is the data for America/Montreal, the comment for which in 2021a backzone is:# Canada## From Paul Eggert (2015-03-24):# Since 1970 most of Quebec has been like Toronto; see# America/Toronto. However, earlier versions of the tz database# mistakenly relied on data from Shanks & Pottenger saying that Quebec# differed from Ontario after 1970, and the following rules and zone# were created for most of Quebec from the incorrect Shanks &# Pottenger data. The post-1970 entries have been corrected, but the# pre-1970 entries are unchecked and probably have errors.#The example that's being cited as a problem with the merge is Europe/Oslo, the comment for which in 2021a europe is:# Norway# http://met.no/met/met_lex/q_u/sommertid.html (2004-01) agrees with Shanks &# Pottenger.So one difference here appears to be that the pre-1970 data for Europe/Oslo may be accurate while the pre-1970 data for America/Montreal may be inaccurate.Another difference is that Toronto and Montreal are in the same country, while Oslo and Berlin aren't.So: Were there any complaints when America/Montreal was turned into a link in 2015c (if the NEWS file is to be believed)? Is the concern that there's software, processes, etc. that depend on Europe/Oslo having the correct pre-1970 data, because that data appears to match what The Norwegian Meteorological Institute says, whereas there may be less software, processes, etc. that depend on America/Montreal having pre-1970 data because that data might be bogus?

3 2

Fwd: New Version Notification for draft-murchison-rfc8536bis-02.txt
by Ken Murchison Sept. 22, 2021

Sept. 22, 2021

FYI, as a distraction from the fork/replace discussions. I have attached the side-by-side diff of this draft and RFC8536. I apologize for the non-substantive diffs in the examples - the latest xml2rfc tool adds separators between rows. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-rfc8536bis-02.txt Date: Sun, 19 Sep 2021 04:53:41 -0700 From: internet-drafts(a)ietf.org To: Arthur David Olson <arthurdavidolson(a)gmail.com>, Arthur Olson <arthurdavidolson(a)gmail.com>, Kenneth Murchison <murch(a)fastmailteam.com>, Paul Eggert <eggert(a)cs.ucla.edu> A new version of I-D, draft-murchison-rfc8536bis-02.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-rfc8536bis Revision: 02 Title: The Time Zone Information Format (TZif) Document date: 2021-09-19 Group: Individual Submission Pages: 45 URL: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-02.txt Status: https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/ Html: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-02.html Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis Diff: https://www.ietf.org/rfcdiff?url2=draft-murchison-rfc8536bis-02 Abstract: This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. The IETF Secretariat

1 0

Response to informal TZ database appeal
by Murray S. Kucherawy Sept. 22, 2021

Sept. 22, 2021

Colleagues, I am an IETF Area Director currently appointed to the Applications and Real Time (ART) area. On June 21, 2021, the ART Area Directors (ADs) received a request from Mr. Stephen Colebourne for intervention regarding a change made to the time zone database. I apologize for the delay in this response. The management of the time zone database is new to me and I wanted to ensure I had done a proper review with as much context as I could discover. Despite what I've learned, I may get some terminology below wrong; apologies if so, and I'm happy to be corrected. I take this to have been an informal appeal under the second step of RFC 6557 Section 5, which prescribes a public discussion with the participation of the ART ADs. As this was our first contact about this matter, I did not interpret the second step as having been completed, and thus this was not an appeal under the third step, which is a formal appeal to the full IESG with prescriptive results. That step, or indeed action under Section 4, remains available to you. This is a shortened version of a much longer discussion document that I have forwarded to the IESG for its reference should further appeals be lodged. Note that since this is being taken under the informal second step, nothing I say here is prescriptive. For context, RFC 6557 (also known as BCP 175) is the only normative document in force. The "theory.html" document is relevant but not normative; it has recorded an evolving set of guiding principles for the time zone database for decades, and they are maintained in the same repository as the data now in dispute. That document has been visible, and subject to discussion and proposed revisions by the community. In summary, I do not believe there is relief to be found for the instant complaint in RFC 6557. There appear to be three points comprising the complaint. Taking them in turn and citing from the message Mr. Colbourne posted to the list on June 3: (a) I contend that to date, the TZ coordinator has not actively shown any serious willingness to accept that the proposed changes are unacceptable to a significant segment of tzdb users. As such, the coordinator has not taken into account the views of the mailing list. I disagree. The TZ mailing list archive is testimonial to the contrary: The TZ Coordinator has engaged in good faith in several subsequent threads on the topic after the change was made, and has proposed other workarounds to accomplish the original goal while attempting to address the objections raised. RFC 6557 says, “... but SHOULD take into account views expressed on the mailing list.” ("SHOULD" is defined in RFC 2119.) This compels the TZ Coordinator to follow the community’s consensus, unless she/he fully understands the implications of not doing so. It is evident to me that in this case, that understanding exists. Therefore it is within the TZ Coordinator’s discretion to proceed. (b) I also contend that the "cleanup" being proposed is not within the charter of the project. Point 1 refers to new zones, thus is not applicable. Point 2 refers to correcting historical inaccuracies, yet it is clear that the proposed change *adds* historical inaccuracies. Point 3 refers to changes, but only in terms that reflect what people in the relevant location would have considered the time zone to have been, yet clearly the proposed change does not do that. No part of the charter permits the coordinator to willfully harm the database, nor to merge timezone regions, nor to increase the number of historical inaccuracies. Again, I disagree. It is worth noting at this point that RFC 6557 is over ten years old. As I reviewed it I became convinced that it, for better or worse, was written in the context of believing that the primary thing that needed to be sustained by the database is accurate time zone calculations as of 1970; aesthetics and "geopolitical" matters were a secondary consideration (if they were considered important at all). While I am sympathetic to the notion that this change may be disruptive to software or other agents that consume only the basic time zone data rather than the alternative representations also available, or may aggravate consumers on a personal level, I do not believe RFC 6557 provides a basis for demanding the change be reverted given my observation above. (c) Justifications for the proposed change based on "consistency" or "politics" are not rooted in the charter of tzdb and should be considered null and void. I disagree. I found no evidence of "political" motivation. If "consistency" is not an acceptable justification, I find it curious that the theory document has not been challenged in the years since the relevant guidelines in it became stable. I have some recommendations for additional paths forward to consider, apart from further action under Sections 4 and 5 of RFC 6557: On the topic of consensus, the IETF published RFC 7282 some years ago, which describes its view of what “consensus” means in our context. It is not a governing document, but may be informative for future discussions or operation of the TZ mailing list. It is clear that in the years since RFC 6557 was published, consumers of this database have come to rely on it for particular local representations of time zones. Mr. Colebourne refers to this as an important “geopolitical” aspect of the database and asserts that the removal of the data implemented by this change will be disruptive to these consumers, so much so that he predicts this will necessitate a forking of the database, with that set of consumers following the fork. This is far from an ideal outcome, and naturally I strongly recommend that this not be how this matter is resolved by those dissatisfied with this (or any other) outcome. Experience has shown that a forked software or data project will always diverge, even with well-intentioned management of the fork to avoid such a delta from forming. Thus, such action could be enormously disruptive to the community. It is furthermore unlikely that the fork will enjoy the same level of oversight, meticulous curation of the data, resolution of disputes, vetting of proposed changes, etc., with any assured longevity. I therefore struggle to see how such action serves anyone in the long term. In any event, and perhaps most importantly, there is the matter of the tension between what the database was originally meant to be for and how people are now consuming it. This clearly cannot be ignored. I propose the community review both RFC 6557 and the “theory” document, giving careful consideration to the principles in each and their respective impacts, and also careful consideration to how the use of this database has evolved, and propose revising either or both to reflect current usage or desired management principles. The IETF has a procedure for revising its process documents (i.e., BCPs) from time to time when the community needs something different, and it would seem that may be the case here. I will be happy to initiate that process within the IETF if a critical mass exists to take up that work. Of note, there are points in the “theory” document that appear to lack supporting language. For example, “annoyingly large” appears to be a subjective criterion, not a technical one. That is, it is unclear what technical or process degradation, if any, is caused by these extra records, so the relevance of this point is not obvious, and therefore it is not clear why this is an important guideline to have in a technical specification. Also of note, I find the “consensus on the ground” requirement of RFC 6557 is probably in need of revision or, at a minimum, clarification. It is apparent that the intent there is to assure quality service to the local communities affected by change, but it includes no practical guidance as to how to do so. Finally, I believe your next formal steps under RFC 6557, should you wish to press the issue, will be one or both of the following: (a) A formal appeal under step 3 of Section 5, which should be addressed to iesg(a)ietf.org stating clearly that this is the formal appeal; or (b) An informal request for the assistance of the ART Area Directors to reach consensus on a candidate under Section 4, which can be addressed to art-ads(a)ietf.org or to me directly. -MSK, ART Area Director

3 3

Replacing the TZ Coordinator
by SM Sept. 22, 2021

Sept. 22, 2021

Hi Stephen, On Tue, Sep 21, 2021 at 10:42:47PM +0100, Stephen Colebourne via tz wrote: >Is there consensus on the list that a change is >required? >Is there a candidate willing to take on the role of TZ Coordinator? My reading of the debate is that a change is being requested because of a dispute about a decision to merge a large number of time zones. Section 5 of RFC 6557 provides a resolution path in case such a dispute arises. In my opinion, it would be premature to invoke Section 4. Regards, -sm

1 0

Undoing the effect of the new alike-since-1970 patch
by Paul Eggert Sept. 21, 2021

Sept. 21, 2021

There's been a clear need expressed to support tzdb users who would rather not deal with the effects of the recently-proposed alike-since-1970 patch. On the other hand there are also fairness and guideline-oriented reasons for the patch, which was originally discussed and installed with more than our usual care and review. Because of the extensive followup discussions I don't see how a single version could be appealing to both sides of this disagreement. So I propose we add a Makefile or similar build-time option to let tzdb users have it either way. Set the flag one way, and it will be as if the recently-proposed changes did not occur. Set it the other way, and you'll get the changes. This will be similar to our vanguard/rearguard support, which helped address a similar disagreement back in 2018. We could even control things via the existing vanguard/rearguard build-time option; that might be simpler. If you have ideas about what the the option's specific effects should be, please let me know. If there is support for this idea, I expect to be able to implement this option soon, in plenty of time before any urgent change due to a real-world rule change arrives. Like most compromises, I expect this approach to not be entirely satisfactory to anybody. However, I hope it helps us move forward together.

15 39

Pacific/Apia no DST from 25/Sep/2021
by Geoffrey D. Bennett Sept. 20, 2021

Sept. 20, 2021

Hi there, tzdata 2021a has Pacific/Apia starting DST 26/Sep/2021 at 3am: # zdump -v Pacific/Apia | grep 2021 Pacific/Apia Sat Apr 3 13:59:59 2021 UT = Sun Apr 4 03:59:59 2021 +14 isdst=1 gmtoff=50400 Pacific/Apia Sat Apr 3 14:00:00 2021 UT = Sun Apr 4 03:00:00 2021 +13 isdst=0 gmtoff=46800 Pacific/Apia Sat Sep 25 13:59:59 2021 UT = Sun Sep 26 02:59:59 2021 +13 isdst=0 gmtoff=46800 Pacific/Apia Sat Sep 25 14:00:00 2021 UT = Sun Sep 26 04:00:00 2021 +14 isdst=1 gmtoff=50400 But according to https://www.facebook.com/MCILSamoa/posts/1666781486865573 and https://www.mcil.gov.ws/storage/2021/09/MCIL-Scan_20210920_120553.pdf DST has been cancelled for this year. Thanks, Geoffrey.

2 1

[PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
by Paul Eggert Sept. 18, 2021

Sept. 18, 2021

This fixes a longstanding ambiguity in the output of localtime in oddball timezones where a positive leap second occurs when the UTC offset is not a multiple of 60 seconds. See NEWS for details. * NEWS: Describe fix. * localtime.c (timesub): Use "??:??:60" at the end of the localtime minute containing the leap second, even when the second marked "??:??:60" is not itself a leap second. This avoids ambiguity in localtime output, at the cost of having the localtime leap second occur up to a minute away from the UTC leap second when the UTC offset is not a multiple of 60 seconds. * tzfile.5: Document the fixed and unfixed behaviors. --- NEWS | 18 ++++++++++++++++++ localtime.c | 22 +++++++++++++--------- tzfile.5 | 12 ++++++++++++ 3 files changed, 43 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 1bf9cf3..6a77932 100644 --- a/NEWS +++ b/NEWS @@ -109,6 +109,24 @@ Unreleased, experimental changes transition in the table, or when handling far-future timestamps in slim TZif files lacking leap seconds. + Fix localtime misbehavior involving positive leap seconds in a + timezone with a UTC offset that is not on a minute boundary. + (No such timezone exists in tzdb, luckily.) Without the fix, + the timestamp was ambiguous during a positive leap second. + With the fix, the localtime leap second appears at the end of the + localtime minute containing the UTC second just before the UTC + leap second, which means leapseconds roll slightly in these + oddball timezones. Here is how the fix affects timestamps in a + timezone with UTC offset +01:23:45 and with a positive leap second + 78796801 (1972-06-30 23:59:60 UTC): + + time_t without the fix with the fix + 78796800 1972-07-01 01:23:45 1972-07-01 01:23:45 + 78796801 1972-07-01 01:23:45 1972-07-01 01:23:46 + ... + 78796815 1972-07-01 01:23:59 1972-07-01 01:23:60 + 78796816 1972-07-01 01:24:00 1972-07-01 01:24:00 + Fix an unlikely bug that caused 'localtime' etc. to misbehave if civil time changes a few seconds before time_t wraps around, when leap seconds are enabled. diff --git a/localtime.c b/localtime.c index 88fd35d..6a687d7 100644 --- a/localtime.c +++ b/localtime.c @@ -1681,20 +1681,23 @@ timesub(const time_t *timep, int_fast32_t offset, register time_t tdays; register const int * ip; register int_fast32_t corr; - register bool hit; register int i; int_fast32_t idays, rem, dayoff, dayrem; time_t y; + /* If less than SECSPERMIN, the number of seconds since the + most recent positive leap second; otherwise, do not add 1 + to localtime tm_sec because of leap seconds. */ + time_t secs_since_posleap = SECSPERMIN; + corr = 0; - hit = false; i = (sp == NULL) ? 0 : sp->leapcnt; while (--i >= 0) { lp = &sp->lsis[i]; if (*timep >= lp->ls_trans) { corr = lp->ls_corr; - hit = (*timep == lp->ls_trans - && (i == 0 ? 0 : lp[-1].ls_corr) < corr); + if ((i == 0 ? 0 : lp[-1].ls_corr) < corr) + secs_since_posleap = *timep - lp->ls_trans; break; } } @@ -1761,11 +1764,12 @@ timesub(const time_t *timep, int_fast32_t offset, tmp->tm_hour = rem / SECSPERHOUR; rem %= SECSPERHOUR; tmp->tm_min = rem / SECSPERMIN; - /* - ** A positive leap second requires a special - ** representation. This uses "... ??:59:60" et seq. - */ - tmp->tm_sec = rem % SECSPERMIN + hit; + tmp->tm_sec = rem % SECSPERMIN; + + /* Use "... ??:??:60" at the end of the localtime minute containing + the second just before the positive leap second. */ + tmp->tm_sec += secs_since_posleap <= tmp->tm_sec; + ip = mon_lengths[isleap(y)]; for (tmp->tm_mon = 0; idays >= ip[tmp->tm_mon]; ++(tmp->tm_mon)) idays -= ip[tmp->tm_mon]; diff --git a/tzfile.5 b/tzfile.5 index ec78689..4a88b75 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -279,6 +279,10 @@ the purpose of skipping over them. Readers should calculate the total lengths of the headers and data blocks and check that they all fit within the actual file size, as part of a validity check for the file. +.PP +When a positive leap second occurs, readers should append a 60th +second to the local minute containing the second just before the leap +second. .SS Common interoperability issues This section documents common problems in reading or writing TZif files. Most of these are problems in generating TZif files for use by @@ -398,6 +402,14 @@ thus swapping standard and daylight saving time. Although this workaround misidentifies which part of the year uses daylight saving time, it records UT offsets and time zone abbreviations correctly. +.IP * +Some readers generate ambiguous timestamps for positive leap seconds +that occur when the UTC offset is not a multiple of 60 seconds. +For example, in a timezone with UTC offset +01:23:45 and with +a positive leap second 78796801 (1972-06-30 23:59:60 UTC), they +map both 78796800 and 78796801 to 01:23:45 local time the next day +instead of mapping the latter to 01:23:46, and they map 78796815 to +01:23:59 instead of to 01:23:60. .PP Some interoperability problems are reader bugs that are listed here mostly as warnings to developers of readers. -- 2.31.1

4 11

[PROPOSED] Match RFC 8536bis-01 better
by Paul Eggert Sept. 18, 2021

Sept. 18, 2021

* NEWS: Mention this. * tzfile.5: The draft RFC 8536bis-01 came out today; match its wording better. --- NEWS | 5 +++++ tzfile.5 | 20 +++++++++++--------- 2 files changed, 16 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 00dea3c..e5f5e90 100644 --- a/NEWS +++ b/NEWS @@ -182,6 +182,11 @@ Unreleased, experimental changes non-POSIX hosts where malloc doesn't set errno. (Problem reported by Jan Engelhardt.) + Changes to documentation + + tzfile.5 better matches a draft successor to RFC 8536 + <https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/01/>. + Release 2021a - 2021-01-24 10:54:57 -0800 diff --git a/tzfile.5 b/tzfile.5 index b1932bd..dd42660 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -152,13 +152,14 @@ Each pair denotes one leap second, either positive or negative, except that if the last pair has the same correction as the previous one, the last pair denotes the leap second table's expiration time. Each leap second is at the end of a UTC calendar month. -The first leap second is positive if and only if its correction is positive, -and the correction for each leap second after the first differs +The first leap second has a nonnegative occurrence time, +and is a positive leap second if and only if its correction is positive; +the correction for each leap second after the first differs from the previous leap second by either 1 for a positive leap second, or \-1 for a negative leap second. If the leap second table is empty, the leap-second correction is zero for all timestamps; -otherwise, for timestamps before the first correction time, +otherwise, for timestamps before the first occurrence time, the leap-second correction is zero if the first pair's correction is 1 or \-1, and is unspecified otherwise (which can happen only in files truncated at the start). @@ -255,11 +256,12 @@ any data that extends beyond the calculated end of the version .PP Other than version 1, writers should generate the lowest version number needed by a file's data. -For example, a writer should generate a version 3 file -if its leap second table neither expires nor is truncated at the start -and so does not use version 4 features, but +For example, a writer should generate a version 4 file +only if its leap second table either expires or is truncated at the start. +Likewise, a writer not generating a version 4 file +should generate a version 3 file only TZ string extensions are necessary to accurately -model transition times so the file does need version 3 features. +model transition times. .PP The sequence of time changes defined by the version 1 header and data block should be a contiguous sub-sequence @@ -433,9 +435,9 @@ abbreviations correctly. Some readers generate ambiguous timestamps for positive leap seconds that occur when the UTC offset is not a multiple of 60 seconds. For example, in a timezone with UTC offset +01:23:45 and with -a positive leap second 78796801 (1972-06-30 23:59:60 UTC), they +a positive leap second 78796801 (1972-06-30 23:59:60 UTC), some readers will map both 78796800 and 78796801 to 01:23:45 local time the next day -instead of mapping the latter to 01:23:46, and they map 78796815 to +instead of mapping the latter to 01:23:46, and they will map 78796815 to 01:23:59 instead of to 01:23:60. This has not yet been a practical problem, since no civil authority has observed such UTC offsets since leap seconds were -- 2.30.2

2 2

[PROPOSED] Improve leap second table truncation doc
by Paul Eggert Sept. 16, 2021

Sept. 16, 2021

* NEWS: Mention possible successor to RFC 8536, and relaxation on TZif reader’s restriction on gaps between leaps. * tzfile.5: Improve wording on leap second expiration. Specify correction before truncated leap second table more accurately, given how localtime.c behaves; for example, the first leap second is considered to be positive if and only if its correction is positive. Say what to do after leap second table expires. Add TZ="XXX3EDT4,0/0,J365/23" example. Say that positive leap seconds not at end of localtime minute have not been a practical problem yet. * tzfile.5, zic.8: Use \- (current font minus) instead of \(mi (math font minus). --- NEWS | 6 ++++- tzfile.5 | 77 ++++++++++++++++++++++++++++++++++++++------------------ zic.8 | 2 +- 3 files changed, 58 insertions(+), 27 deletions(-) diff --git a/NEWS b/NEWS index cc69995..00dea3c 100644 --- a/NEWS +++ b/NEWS @@ -86,7 +86,8 @@ Unreleased, experimental changes clients (including tzdb 2017c through 2021a) reject it, so "Expires" directives are currently disabled by default. To enable them, set the EXPIRES_LINE Makefile variable. If a TZif file uses - this new feature it is marked with a new TZif version number 4. + this new feature it is marked with a new TZif version number 4, + a format intended to be documented in a successor to RFC 8536. zic -L LEAPFILE -r @LO no longer generates an invalid TZif file that omits leap second information for the range LO..B when LO @@ -98,6 +99,9 @@ Unreleased, experimental changes correction other than -1 or +1, and to contain adjacent transitions with equal corrections. This supports TZif version 4. + The TZif reader now lets leap seconds occur less than 28 days + apart. This supports possible future TZif extensions. + Fix bug that caused 'localtime' etc. to crash when TZ was set to a all-year DST string like "EST5EDT4,0/0,J365/25" that does not conform to POSIX but does conform to Internet RFC 8536. diff --git a/tzfile.5 b/tzfile.5 index bab6390..b1932bd 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -142,16 +142,26 @@ pairs of four-byte values, written in network byte order; the first value of each pair gives the nonnegative time (as returned by .BR time (2)) -at which a leap second occurs; +at which a leap second occurs or at which the leap second table expires; the second is a signed integer specifying the correction, which is the .I total number of leap seconds to be applied during the time period starting at the given time. -The pairs of values are sorted in ascending order by time. -Each transition is for one leap second, either positive or negative; -transitions always separated by at least 28 days minus 1 second. -The first entry's correction is +1 (or \(mi1, for a hypothetical leap -second table where the first leap second was negative). +The pairs of values are sorted in strictly ascending order by time. +Each pair denotes one leap second, either positive or negative, +except that if the last pair has the same correction as the previous one, +the last pair denotes the leap second table's expiration time. +Each leap second is at the end of a UTC calendar month. +The first leap second is positive if and only if its correction is positive, +and the correction for each leap second after the first differs +from the previous leap second by either 1 for a positive leap second, +or \-1 for a negative leap second. +If the leap second table is empty, the leap-second correction is zero +for all timestamps; +otherwise, for timestamps before the first correction time, +the leap-second correction is zero if the first pair's correction is 1 or \-1, +and is unspecified otherwise (which can happen only in files +truncated at the start). .IP * .B tzh_ttisstdcnt standard/wall indicators, each stored as a one-byte boolean; @@ -201,7 +211,7 @@ POSIX-TZ-environment-variable-style string for use in handling instants after the last transition time stored in the file or for all instants if the file has no transitions. The POSIX-style TZ string is empty (i.e., nothing between the newlines) -if there is no POSIX representation for such instants. +if there is no POSIX-style representation for such instants. If nonempty, the POSIX-style TZ string must agree with the local time type after the last transition time if present in the eight-byte data; for example, given the string @@ -225,8 +235,8 @@ January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time. .SS Version 4 format For version-4-format TZif files, -the first leap second transition can have a correction that is neither -+1 nor \(mi1, to support TZif files with reduced timestamp range. +the first leap second record can have a correction that is neither ++1 nor \-1, to represent truncation of the TZif file at the start. Also, if two or more leap second transitions are present and the last entry's correction equals the previous one, the last entry denotes the expiration of the leap second table instead of a leap second; @@ -237,32 +247,37 @@ the added leap seconds will change how post-expiration timestamps are treated. Future changes to the format may append more data. .PP Version 1 files are considered a legacy format and -should be avoided, as they do not support transition +should not be generated, as they do not support transition times after the year 2038. -Readers that only understand Version 1 must ignore +Readers that understand only Version 1 must ignore any data that extends beyond the calculated end of the version 1 data block. .PP Other than version 1, writers should generate the lowest version number needed by a file's data. For example, a writer should generate a version 3 file -if the file does not contain a truncated leap second table +if its leap second table neither expires nor is truncated at the start and so does not use version 4 features, but TZ string extensions are necessary to accurately model transition times so the file does need version 3 features. .PP The sequence of time changes defined by the version 1 -header and data block should be a contiguous subsequence +header and data block should be a contiguous sub-sequence of the time changes defined by the version 2+ header and data block, and by the footer. This guideline helps obsolescent version 1 readers agree with current readers about timestamps within the -contiguous subsequence. It also lets writers not +contiguous sub-sequence. It also lets writers not supporting obsolescent readers use a .B tzh_timecnt of zero in the version 1 data block to save space. .PP +When a TZif file contains a leap second table expiration +time, TZif readers should either refuse to process +post-expiration timestamps, or process them as if the expiration +time did not exist (possibly with an error indication). +.PP Time zone designations should consist of at least three (3) and no more than six (6) ASCII characters from the set of alphanumerics, @@ -272,7 +287,7 @@ and This is for compatibility with POSIX requirements for time zone abbreviations. .PP -When reading a version 2+ file, readers +When reading a version 2 or higher file, readers should ignore the version 1 header and data block except for the purpose of skipping over them. .PP @@ -306,7 +321,7 @@ design goal has been that a reader can successfully use a TZif file even if the file is of a later TZif version than what the reader was designed for. When complete compatibility was not achieved, an attempt was -made to limit glitches to rarely-used timestamps, and to allow +made to limit glitches to rarely used timestamps and allow simple partial workarounds in writers designed to generate new-version data useful even for older-version readers. This section attempts to document these compatibility issues and @@ -323,24 +338,33 @@ version 2+ data even if the reader's native timestamps have only 32 bits. .IP * Some readers designed for version 2 might mishandle -timestamps after a version 3 file's last transition, because +timestamps after a version 3 or higher file's last transition, because they cannot parse extensions to POSIX in the TZ-like string. As a partial workaround, a writer can output more transitions than necessary, so that only far-future timestamps are mishandled by version 2 readers. .IP * Some readers designed for version 2 do not support -permanent daylight saving time, e.g., a TZ string +permanent daylight saving time with transitions after 24:00 +\(en e.g., a TZ string .q "EST5EDT,0/0,J365/25" -denoting permanent Eastern Daylight Time (\-04). -As a partial workaround, a writer can substitute standard time -for the next time zone east, e.g., +denoting permanent Eastern Daylight Time +(\-04). +As a workaround, a writer can substitute standard time +for two time zones east, e.g., +.q "XXX3EDT4,0/0,J365/23" +for a time zone with a never-used standard time (XXX, \-03) +and negative daylight saving time (EDT, \-04) all year. +Alternatively, +as a partial workaround a writer can substitute standard time +for the next time zone east \(en e.g., .q "AST4" -for permanent Atlantic Standard Time (\-04). +for permanent +Atlantic Standard Time (\-04). .IP * -Some readers designed for earlier versions reject version 4 files, -because they require complete leap second tables that do not record -expiration dates. +Some readers designed for version 2 or 3, and that require strict +conformance to RFC 8536, reject version 4 files whose leap second +tables are truncated at the start or that end in expiration times. .IP * Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. @@ -413,6 +437,9 @@ a positive leap second 78796801 (1972-06-30 23:59:60 UTC), they map both 78796800 and 78796801 to 01:23:45 local time the next day instead of mapping the latter to 01:23:46, and they map 78796815 to 01:23:59 instead of to 01:23:60. +This has not yet been a practical problem, since no civil authority +has observed such UTC offsets since leap seconds were +introduced in 1972. .PP Some interoperability problems are reader bugs that are listed here mostly as warnings to developers of readers. diff --git a/zic.8 b/zic.8 index 3149440..ea7bab9 100644 --- a/zic.8 +++ b/zic.8 @@ -550,7 +550,7 @@ using the shortest form that does not lose information, where .IR mm , and .I ss -are the hours, minutes, and seconds east (+) or west (\(mi) of UT. +are the hours, minutes, and seconds east (+) or west (\-) of UT. Alternatively, a slash (/) separates standard and daylight abbreviations. -- 2.30.2

1 0

[CfP][CalendarFest] Call for lightning talk proposals for CalendarFest 2021 - current topics in electronic calendaring
by Hans-Joerg Happel Sept. 15, 2021

Sept. 15, 2021

Hi, my apologies for being slightly off topic, but I guess this might be interesting to see some of you / related to some topics discussed on this list. Please feel also free to forward this to anybody you might have in mind, who is dealing with novel calendaring solutions and ideas and might be interested in community discussion. Thanks and best, Hans-Joerg ----- CalendarFest is a novel (virtual) event, which wants to let users and developers of (electronic) calendar applications, servers, and related groupware systems, share experiences and discuss novel ideas. CalendarFest will take place *18th of October*, 02:30h PM UTC virtually via Zoom, and is held in conjunction with the CalConnect virtual conference <https://www.calconnect.org/events/calconnect-virtual-conference-autumn-2021>. Lightning talks People who wish to discuss or present certain topics are invited to submit a *proposal for lightning talks*. Lightning Talk presentations will be a maximum of 15-20 minutes each. Presenters may use slides, but these must be submitted to the Lightning Talks chair a few days before the presentation. Proposals Lightning Talk proposals must be submitted in PDF format. The proposal is limited to 1 page, 500 words max. The full proposal contains a title, an abstract (maximum 250 words) and a description where you should explain your talk in more detail. It will be helpful for reviewers to know why you are excited about the topic, and why you think others will be interested too. Outline how you plan to present your topic. The proposal also may contain a link to a website with more information. Possible Topics * Enterprise calendaring * Public calendaring * Calendaring and Semantic Web/Linked Data * Calendar Interoperability and Migration * Calendaring Security and Privacy by Design * Personal information management (PIM) and groupware * AI in calendaring * Calendaring and scheduling in IoT * Mobile calendaring * Calendar visualization, user experience and usability * Novel applications of calendars * Calendaring standards (vCard, iCal, CalDAV, CardDAV, JMAP) * Date/Time representations and Time zones * Business models for calendaring and groupware Program committee Submissions will be reviewed by the following members of the CalConnect TC-CLIENT technical committee: * Mike Douglass * Hans-Jörg Happel * Alex Nimmervoll Timeline * Send your lightning talk proposal to *calendarfest(a)calconnect.org <mailto:calendarfest@calconnect.org>* until *October, 4th* * You will receive a notification of acceptance or reject by October, 11th * CalendarFest will take place on October, 18th Participation Participation at CalendarFest will be free for presenters of accepted talks. Other participants need to register <https://www.calconnect.org/news/2021/09/02/registration-open-october-2021-c…> for a small organizational fee, which also allows for participation at the “colocated” CalConnect Virtual Conference. About CalConnect (www.calconnect.org <http://www.calconnect.org>) is a non-profit partnership between vendors and users of collaboration systems and tools, in particular calendaring and scheduling. CalConnect members convene regularly to discuss and develop standards for electronic calendaring and related topics. The goal of CalendarFest, which is held in conjunction with the CalConnect Virtual Conference, is to provide an interdisciplinary discussion space for current topics in electronic calendaring from different perspectives. *CalendarFest website: https://public.calconnect.org/CalendarFest/*

1 0

[PROPOSED] Don't mistruncate TZif files at leap seconds
by Paul Eggert Sept. 14, 2021

Sept. 14, 2021

Without this fix, zic mishandles the command ‘zic -L leapseconds -r @1706745601 etcetera’ when ‘leapseconds’ is generated from the test data file mentioned in: https://mm.icann.org/pipermail/tz/2021-September/030385.html The resulting, incorrect TZif file causes ‘TZ=Etc/GMT date -r 1706745601’ to output "Thu Feb 1 00:00:01 GMT 2024" instead of the correct "Thu Feb 1 00:00:00 GMT 2024", because localtime misinterprets the leap second entry at 1706745601 to be a positive instead of a negative leap second. * NEWS: Mention the fix. * zic.c (limitrange): When omitting leading leap seconds, do not output a leap second table that starts with a positive leap second with a nonpositive correction (or with a negative leap second with a positive correction) as that will confuse TZif readers into thinking the positive leap second is negative or vice versa. Instead, keep otherwise-unnecessary leading leap seconds to avoid the confusion. --- NEWS | 6 ++++++ zic.c | 14 ++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 62a7ba2..9983f11 100644 --- a/NEWS +++ b/NEWS @@ -137,6 +137,12 @@ Unreleased, experimental changes last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3. + Fix a bug with 'zic -r @X' when X is a negative leap second that + has a nonnegative correction. Without the fix, the output file + was truncated so that X appeared to be a positive leap second. + Fix a similar, even-less-likely bug when truncating at a positive + leap second that has a nonpositive correction. + zic -r now reports an error if given rolling leap seconds, as this usage has never generally worked and is evidently unused. diff --git a/zic.c b/zic.c index b06ef66..c6feb8b 100644 --- a/zic.c +++ b/zic.c @@ -1972,12 +1972,22 @@ limitrange(struct timerange r, bool locut, zic_t lo, zic_t hi, r.base++; } - /* Omit as many leap seconds < LO as possible, such that the first - leap second in the truncated list is <= LO. */ + /* Omit as many initial leap seconds as possible, such that the + first leap second in the truncated list is <= LO, and is a + positive leap second if and only if it has a positive correction. + This supports common TZif readers that assume that the first leap + second is positive if and only if its correction is positive. */ while (1 < r.leapcount && trans[r.leapbase + 1] <= lo) { r.leapcount--; r.leapbase++; } + while (0 < r.leapbase + && ((corr[r.leapbase - 1] < corr[r.leapbase]) + != (0 < corr[r.leapbase]))) { + r.leapcount++; + r.leapbase--; + } + /* Omit ordinary and leap second transitions greater than HI + 1. */ if (hi < ZIC_MAX) { -- 2.30.2

1 0

Re: [tz] No leap second on 2021-12-31
by Kerry Shetline Sept. 14, 2021

Sept. 14, 2021

What’s interesting is that the Earth is undergoing an odd span of time during which it has been spinning a bit faster instead of slowing down. If this keeps up, not only will it be a while until we see another leap second, but in a few years we might experience the first negative leap second, where a second is dropped from the end of the last minute just before 00:00 UTC. > Per IERS, Bulletin C 62 (2021-07-05) > https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.62 > > ?and forwarded below. > > A patch updating leap-seconds.list from NIST is attached, and is installed > in the development repository. > > -- > Tim Parenti

3 2

Further fix for Niue
by Tim Parenti Sept. 14, 2021

Sept. 14, 2021

While working on the recent changes to historical timestamps for Sierra Leone, the unique -11:20 offset for Niue caught my eye in contemporaneous editions of The Air Almanac which P Chan had sourced: specifically, that it was no longer there by the late 1960s. FInding a few more editions, I eventually found -11:20 listed for Niue as of Apr 1964 but -11 as of Aug 1964: Apr 1964: https://books.google.com/books?id=_1So677Y5vUC&pg=SL1-PA23 Aug 1964: https://books.google.com/books?id=MbJloqd-zyUC&pg=SL1-PA23 This points to a likely transition sometime around July 1964. 1978 did seem awfully late for such a unique offset. Proposed patch attached, and installed in the development repository. -- Tim Parenti On Wed, 24 Mar 2021 at 15:28, Paul Eggert via tz <tz(a)iana.org> wrote: > Thanks for the additional info about Cook and Niue. Proposed further > patch attached, and installed into the development repository. >

1 0

Historical fix for Tonga
by Tim Parenti Sept. 14, 2021

Sept. 14, 2021

First, a quick clerical patch: 0001, attached, fixes the placement of a comment which got shuffled around in the lead-up to publishing the changes for South Sudan in 2021a. Patch 0003 relates to Tonga, and comes from some of the links P Chan shared to 1957–1963 editions of The Air Almanac: https://mm.icann.org/pipermail/tz/2021-February/029866.html On Thu, 25 Feb 2021 at 03:43, P Chan <legco(a)outlook.com> wrote: > 1960 Nov (1962.1-4) > https://books.google.com/books?id=bVgtWM6kPZUC&pg=SL1-PA20 > 1961 Mar (1962.5-8) > https://books.google.com/books?id=W2nItAul4g0C&pg=SL1-PA20 When looking around at how this data was presented for other regions, I noticed on the preceding pages (listing "Places Fast on GMT", i.e., east of Greenwich) in some of the earlier editions provided that Tonga was listed at GMT+12:20. The peculiar offset stuck out, and I quickly noticed that some of the later editions of the same tables had it at GMT+13. A quick bisection puts the changeover, as far as The Air Almanac contemporaneously reckoned it, between November 1960 and March 1961. Previously, our data had Tonga transitioning to UT+13 in 1941 based on a quotation from a 1997 news article. Although this differs from what the Almanac suggests by some 20 years, the article does mention a change coincident with the New Year, and that Tāufaʻāhau Tupou IV was Crown Prince at the time. As his predecessor and mother, Queen Sālote Tupou III, reigned from 1918-04-05 to 1965-12-16, a possible transition of 1961-01-01 still jives with the gist of the article, even if the specific year was perhaps wrong or just misprinted. For what it's worth, our commentary already noted that Shanks & Pottenger had put the transition even later, at 1968-10-01. Although of course we don't know how they arrived at that date, given that they did, 1961 seems rather less out-of-place than it otherwise might. The attached patch 0003 makes this adjustment, while more fully documenting and comparing the conflicting sources. Thanks again to P Chan for pointing us to these resources. I wasn't expecting to get a "bonus" correction out of it, but one never knows quite what will catch the eye… -- Tim Parenti

3 3

[PATCH 1/8] * tzfile.5: Fix prefix/suffix typo (thanks to Ian Abbott).
by Paul Eggert Sept. 14, 2021

Sept. 14, 2021

--- tzfile.5 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.5 b/tzfile.5 index b4952d5..ec78689 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -134,7 +134,7 @@ bytes that represent time zone designations, which are null-terminated byte strings, each indexed by the .B tt_desigidx values mentioned above. -The byte strings can overlap if one is a prefix of the other. +The byte strings can overlap if one is a suffix of the other. The encoding of these strings is not specified. .IP * .B tzh_leapcnt -- 2.27.0

2 8

[PROPOSED] zic -r is incompatible with rolling leaps
by Paul Eggert Sept. 13, 2021

Sept. 13, 2021

* NEWS, zic.8: Mention this. * zic.c (leapadd): Report an error if the user tries it. --- NEWS | 3 +++ zic.8 | 3 +++ zic.c | 4 ++++ 3 files changed, 10 insertions(+) diff --git a/NEWS b/NEWS index 1b5535a..62a7ba2 100644 --- a/NEWS +++ b/NEWS @@ -137,6 +137,9 @@ Unreleased, experimental changes last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3. + zic -r now reports an error if given rolling leap seconds, as this + usage has never generally worked and is evidently unused. + zic now generates a POSIX-conforming TZ string for TZif files where all-year DST is predicted for the indefinite future. For example, for all-year Eastern Daylight Time, zic now generates diff --git a/zic.8 b/zic.8 index b77841b..3023ebe 100644 --- a/zic.8 +++ b/zic.8 @@ -709,6 +709,9 @@ or .q "Rolling" if the leap second time given by the other fields should be interpreted as local (wall clock) time. +(Rolling leap seconds are not supported if the +.B \*-r +option is used.) .PP The expiration line, if present, has the form: .nf diff --git a/zic.c b/zic.c index e2a7e13..b06ef66 100644 --- a/zic.c +++ b/zic.c @@ -3144,6 +3144,10 @@ leapadd(zic_t t, int correction, int rolling) error(_("too many leap seconds")); exit(EXIT_FAILURE); } + if (rolling && (lo_time != min_time || hi_time != max_time)) { + error(_("Rolling leap seconds not supported with -r")); + exit(EXIT_FAILURE); + } for (i = 0; i < leapcnt; ++i) if (t <= trans[i]) break; -- 2.30.2

4 7

Re: [tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
by Paul Eggert Sept. 13, 2021

Sept. 13, 2021

On 9/13/21 2:45 AM, Robert Elz wrote: > do the changes in this proposal also correctly handle negative > leap seconds that are (for whatever bizarre reason) shoved into the middle > of a minute? Good question. I don't know of any problems in that area, though, as the proposed change does not affect negative leap seconds. The problem with 2021a and earlier is that localtime labels are ambiguous in a positive leap second inserted into the middle of a localtime minute; for example, if a leap second is inserted between seconds 11 and 12 the count is ... 9, 10, 11, 11, 12, 13,... which is problematic. With a negative leap second, the clock skips a second so there can be no ambiguity and there is no need for a fix. If the 11th second is skipped, for example, the localtime seconds is simply ... 9, 10, 12, 13,.... This has long been the case in the code, and the proposed change does not affect this.

1 0

[PROPOSED] Simplify zic's handling of -r
by Paul Eggert Sept. 13, 2021

Sept. 13, 2021

This is refactoring; it should not affect user-visible behavior. * zic.c (struct timerange): New member pretrans. (limitrange): New arg locut. Use it to set r.pretrans. All callers changed. (writezone): Initialize the new member, to avoid undefined behavior. Simplify by using the new member. --- zic.c | 70 +++++++++++++++++++++++++++++------------------------------ 1 file changed, 34 insertions(+), 36 deletions(-) diff --git a/zic.c b/zic.c index a4406cb..e2a7e13 100644 --- a/zic.c +++ b/zic.c @@ -1958,29 +1958,44 @@ struct timerange { int defaulttype; ptrdiff_t base, count; int leapbase, leapcount; - bool leapexpiry; + bool pretrans, leapexpiry; }; static struct timerange -limitrange(struct timerange r, zic_t lo, zic_t hi, +limitrange(struct timerange r, bool locut, zic_t lo, zic_t hi, zic_t const *ats, unsigned char const *types) { + /* Omit ordinary transitions < LO. */ while (0 < r.count && ats[r.base] < lo) { r.defaulttype = types[r.base]; r.count--; r.base++; } + + /* Omit as many leap seconds < LO as possible, such that the first + leap second in the truncated list is <= LO. */ while (1 < r.leapcount && trans[r.leapbase + 1] <= lo) { r.leapcount--; r.leapbase++; } + /* Omit ordinary and leap second transitions greater than HI + 1. */ if (hi < ZIC_MAX) { while (0 < r.count && hi + 1 < ats[r.base + r.count - 1]) r.count--; while (0 < r.leapcount && hi + 1 < trans[r.leapbase + r.leapcount - 1]) r.leapcount--; } + + /* Determine whether to keep the last too-low transition if no + transition is exactly at LO. The kept transition will be output + as a LO "transition"; see "Output a LO_TIME transition" below. + This is needed when the output is truncated at the start, and is + also useful when catering to buggy 32-bit clients that do not use + time type 0 for timestamps before the first transition. */ + r.pretrans = locut && ! (r.count && ats[r.base] == lo); + + /* Determine whether to append an expiration to the leap second table. */ r.leapexpiry = 0 <= leapexpires && leapexpires - 1 <= hi; return r; @@ -2092,9 +2107,11 @@ writezone(const char *const name, const char *const string, char version, rangeall.base = rangeall.leapbase = 0; rangeall.count = timecnt; rangeall.leapcount = leapcnt; - rangeall.leapexpiry = false; - range64 = limitrange(rangeall, lo_time, hi_time, ats, types); - range32 = limitrange(range64, INT32_MIN, INT32_MAX, ats, types); + rangeall.pretrans = rangeall.leapexpiry = false; + range64 = limitrange(rangeall, min_time < lo_time, + lo_time, hi_time, ats, types); + range32 = limitrange(range64, INT32_MIN < lo_time, + INT32_MIN, INT32_MAX, ats, types); /* TZif version 4 is needed if a no-op transition is appended to indicate the expiration of the leap second table, or if the first @@ -2129,7 +2146,7 @@ writezone(const char *const name, const char *const string, char version, register int thisleapi, thisleapcnt, thisleaplim; struct tzhead tzh; int currenttype, thisdefaulttype; - bool locut, hicut, thisleapexpiry; + bool hicut, pretrans, thisleapexpiry; zic_t lo; int old0; char omittype[TZ_MAX_TYPES]; @@ -2160,8 +2177,8 @@ writezone(const char *const name, const char *const string, char version, toomanytimes = thistimecnt >> 31 >> 1 != 0; thisleapi = range32.leapbase; thisleapcnt = range32.leapcount; + pretrans = range32.pretrans; thisleapexpiry = range32.leapexpiry; - locut = INT32_MIN < lo_time; hicut = hi_time < INT32_MAX; } else { thisdefaulttype = range64.defaulttype; @@ -2170,33 +2187,17 @@ writezone(const char *const name, const char *const string, char version, toomanytimes = thistimecnt >> 31 >> 31 >> 2 != 0; thisleapi = range64.leapbase; thisleapcnt = range64.leapcount; + pretrans = range64.pretrans; thisleapexpiry = range64.leapexpiry; - locut = min_time < lo_time; hicut = hi_time < max_time; } if (toomanytimes) error(_("too many transition times")); - /* Keep the last too-low transition if no transition is - exactly at LO. The kept transition will be output as - a LO "transition"; see "Output a LO_TIME transition" - below. This is needed when the output is truncated at - the start, and is also useful when catering to buggy - 32-bit clients that do not use time type 0 for - timestamps before the first transition. */ - if (0 < thistimei && ats[thistimei] != lo_time) { - thistimei--; - thistimecnt++; - locut = false; - } - thistimelim = thistimei + thistimecnt; - if (thistimecnt != 0) { - if (ats[thistimei] == lo_time) - locut = false; - if (hi_time < ZIC_MAX && ats[thistimelim - 1] == hi_time + 1) - hicut = false; - } + if (thistimecnt && hi_time < ZIC_MAX + && ats[thistimelim - 1] == hi_time + 1) + hicut = false; memset(omittype, true, typecnt); omittype[thisdefaulttype] = false; for (i = thistimei; i < thistimelim; i++) @@ -2291,11 +2292,9 @@ writezone(const char *const name, const char *const string, char version, indmap[desigidx[i]] = j; } if (pass == 1 && !want_bloat()) { - thisleapcnt = 0; - thisleapexpiry = false; - thistimecnt = - (locut + hicut); + pretrans = hicut = thisleapexpiry = false; + thistimecnt = thisleapcnt = 0; thistypecnt = thischarcnt = 1; - thistimelim = thistimei; } #define DO(field) fwrite(tzh.field, sizeof tzh.field, 1, fp) memset(&tzh, 0, sizeof tzh); @@ -2304,7 +2303,7 @@ writezone(const char *const name, const char *const string, char version, convert(utcnt, tzh.tzh_ttisutcnt); convert(stdcnt, tzh.tzh_ttisstdcnt); convert(thisleapcnt + thisleapexpiry, tzh.tzh_leapcnt); - convert(locut + thistimecnt + hicut, tzh.tzh_timecnt); + convert(pretrans + thistimecnt + hicut, tzh.tzh_timecnt); convert(thistypecnt, tzh.tzh_typecnt); convert(thischarcnt, tzh.tzh_charcnt); DO(tzh_magic); @@ -2331,16 +2330,15 @@ writezone(const char *const name, const char *const string, char version, for this pass. */ lo = pass == 1 && lo_time < INT32_MIN ? INT32_MIN : lo_time; - if (locut) + if (pretrans) puttzcodepass(lo, fp, pass); for (i = thistimei; i < thistimelim; ++i) { - zic_t at = ats[i] < lo ? lo : ats[i]; - puttzcodepass(at, fp, pass); + puttzcodepass(ats[i], fp, pass); } if (hicut) puttzcodepass(hi_time + 1, fp, pass); currenttype = 0; - if (locut) + if (pretrans) putc(currenttype, fp); for (i = thistimei; i < thistimelim; ++i) { currenttype = typemap[types[i]]; -- 2.31.1

1 0

[PATCH] Use https: for opengroup in zic.8
by Paul Eggert Sept. 12, 2021

Sept. 12, 2021

--- zic.8 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.8 b/zic.8 index 800fb8b..b77841b 100644 --- a/zic.8 +++ b/zic.8 @@ -252,7 +252,7 @@ zero or more lines, each ending in a newline byte and containing at most 511 bytes, and without any NUL bytes. The input text's encoding is typically UTF-8 or ASCII; it should have a unibyte representation for the POSIX Portable Character Set (PPCS) -\*<http://pubs\*:.opengroup\*:.org/\*:onlinepubs/\*:9699919799/\*:basedefs/\*:…> +\*<https://pubs\*:.opengroup\*:.org/\*:onlinepubs/\*:9699919799/\*:basedefs/\*…> and the encoding's non-unibyte characters should consist entirely of non-PPCS bytes. Non-PPCS characters typically occur only in comments: although output file names and time zone abbreviations can contain -- 2.31.1

1 0

[PATCH] Port ‘check_time_t_alternatives’ to oddball hosts
by Paul Eggert Sept. 12, 2021

Sept. 12, 2021

* Makefile (TIME_T_ALTERNATIVES): Use int_least64_t instead of int64_t, as int64_t is not required by the C standard. Similarly for int32_t, uint32_t, uint64_t. --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index b00ac05..8a7436a 100644 --- a/Makefile +++ b/Makefile @@ -122,8 +122,8 @@ LIBDIR = $(TOPDIR)/$(USRDIR)/lib # Types to try, as an alternative to time_t. TIME_T_ALTERNATIVES = $(TIME_T_ALTERNATIVES_HEAD) $(TIME_T_ALTERNATIVES_TAIL) -TIME_T_ALTERNATIVES_HEAD = int64_t -TIME_T_ALTERNATIVES_TAIL = int32_t uint32_t uint64_t +TIME_T_ALTERNATIVES_HEAD = int_least64_t +TIME_T_ALTERNATIVES_TAIL = int_least32_t uint_least32_t uint_least64_t # What kind of TZif data files to generate. (TZif is the binary time # zone data format that zic generates; see Internet RFC 8536.) @@ -976,7 +976,7 @@ $(TIME_T_ALTERNATIVES): $(VERSION_DEPS) mkdir $@.dir ln $(VERSION_DEPS) $@.dir case $@ in \ - int32_t) range=-2147483648,2147483648;; \ + int*32_t) range=-2147483648,2147483648;; \ u*) range=0,4294967296;; \ *) range=-4294967296,4294967296;; \ esac && \ -- 2.31.1

1 0

request
by Cool Gab19 Sept. 12, 2021

Sept. 12, 2021

I request Etc/GMT-15 or +15 be included in your database https://github.com/gabtimezone15/tz/blob/d0970deeac9041a1e8a585782ccec3a1ef…

2 2

[PROPOSED] Omit some casts
by Paul Eggert Sept. 11, 2021

Sept. 11, 2021

* localtime.c (getsecs, localsub, timesub): * strftime.c (_fmt): * zdump.c (dumptime): * zic.c (rcomp, atcomp): Rely on automatic conversions instead of casts, which are more error-prone. --- localtime.c | 13 +++++++------ strftime.c | 12 +++++++----- zdump.c | 17 ++++++----------- zic.c | 11 +++++------ 4 files changed, 25 insertions(+), 28 deletions(-) diff --git a/localtime.c b/localtime.c index cc972ef..88fd35d 100644 --- a/localtime.c +++ b/localtime.c @@ -862,6 +862,7 @@ static const char * getsecs(register const char *strp, int_fast32_t *const secsp) { int num; + int_fast32_t secsperhour = SECSPERHOUR; /* ** 'HOURSPERDAY * DAYSPERWEEK - 1' allows quasi-Posix rules like @@ -872,7 +873,7 @@ getsecs(register const char *strp, int_fast32_t *const secsp) strp = getnum(strp, &num, 0, HOURSPERDAY * DAYSPERWEEK - 1); if (strp == NULL) return NULL; - *secsp = num * (int_fast32_t) SECSPERHOUR; + *secsp = num * secsperhour; if (*strp == ':') { ++strp; strp = getnum(strp, &num, 0, MINSPERHOUR - 1); @@ -1544,7 +1545,7 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, hi = mid; else lo = mid + 1; } - i = (int) sp->types[lo - 1]; + i = sp->types[lo - 1]; } ttisp = &sp->ttis[i]; /* @@ -1757,18 +1758,18 @@ timesub(const time_t *timep, int_fast32_t offset, tmp->tm_wday %= DAYSPERWEEK; if (tmp->tm_wday < 0) tmp->tm_wday += DAYSPERWEEK; - tmp->tm_hour = (int) (rem / SECSPERHOUR); + tmp->tm_hour = rem / SECSPERHOUR; rem %= SECSPERHOUR; - tmp->tm_min = (int) (rem / SECSPERMIN); + tmp->tm_min = rem / SECSPERMIN; /* ** A positive leap second requires a special ** representation. This uses "... ??:59:60" et seq. */ - tmp->tm_sec = (int) (rem % SECSPERMIN) + hit; + tmp->tm_sec = rem % SECSPERMIN + hit; ip = mon_lengths[isleap(y)]; for (tmp->tm_mon = 0; idays >= ip[tmp->tm_mon]; ++(tmp->tm_mon)) idays -= ip[tmp->tm_mon]; - tmp->tm_mday = (int) (idays + 1); + tmp->tm_mday = idays + 1; tmp->tm_isdst = 0; #ifdef TM_GMTOFF tmp->TM_GMTOFF = offset; diff --git a/strftime.c b/strftime.c index 4f871cd..5273155 100644 --- a/strftime.c +++ b/strftime.c @@ -335,11 +335,13 @@ label: && tm.tm_sec == tm_1.tm_sec)) return NULL; } - if (TYPE_SIGNED(time_t)) - sprintf(buf, "%"PRIdMAX, - (intmax_t) mkt); - else sprintf(buf, "%"PRIuMAX, - (uintmax_t) mkt); + if (TYPE_SIGNED(time_t)) { + intmax_t n = mkt; + sprintf(buf, "%"PRIdMAX, n); + } else { + uintmax_t n = mkt; + sprintf(buf, "%"PRIuMAX, n); + } pt = _add(buf, pt, ptlim); } continue; diff --git a/zdump.c b/zdump.c index 9d22b26..e198b04 100644 --- a/zdump.c +++ b/zdump.c @@ -1155,8 +1155,6 @@ dumptime(register const struct tm *timeptr) "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; - register const char * wn; - register const char * mn; register int lead; register int trail; @@ -1169,16 +1167,13 @@ dumptime(register const struct tm *timeptr) ** values in tm_wday or tm_mon, but since this code might be compiled ** with other (perhaps experimental) versions, paranoia is in order. */ - if (timeptr->tm_wday < 0 || timeptr->tm_wday >= - (int) (sizeof wday_name / sizeof wday_name[0])) - wn = "???"; - else wn = wday_name[timeptr->tm_wday]; - if (timeptr->tm_mon < 0 || timeptr->tm_mon >= - (int) (sizeof mon_name / sizeof mon_name[0])) - mn = "???"; - else mn = mon_name[timeptr->tm_mon]; printf("%s %s%3d %.2d:%.2d:%.2d ", - wn, mn, + ((0 <= timeptr->tm_wday + && timeptr->tm_wday < sizeof wday_name / sizeof wday_name[0]) + ? wday_name[timeptr->tm_wday] : "???"), + ((0 <= timeptr->tm_mon + && timeptr->tm_mon < sizeof mon_name / sizeof mon_name[0]) + ? mon_name[timeptr->tm_mon] : "???"), timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec); #define DIVISOR 10 diff --git a/zic.c b/zic.c index 4c55f1c..a4406cb 100644 --- a/zic.c +++ b/zic.c @@ -1225,8 +1225,8 @@ itssymlink(char const *name) static int rcomp(const void *cp1, const void *cp2) { - return strcmp(((const struct rule *) cp1)->r_name, - ((const struct rule *) cp2)->r_name); + struct rule const *r1 = cp1, *r2 = cp2; + return strcmp(r1->r_name, r2->r_name); } static void @@ -1949,10 +1949,9 @@ puttzcodepass(zic_t val, FILE *fp, int pass) static int atcomp(const void *avp, const void *bvp) { - const zic_t a = ((const struct attype *) avp)->at; - const zic_t b = ((const struct attype *) bvp)->at; - - return (a < b) ? -1 : (a > b); + struct attype const *ap = avp, *bp = bvp; + zic_t a = ap->at, b = bp->at; + return a < b ? -1 : a > b; } struct timerange { -- 2.31.1

1 0

[PATCH] Fix tzfile.h comment
by Paul Eggert Sept. 11, 2021

Sept. 11, 2021

* tzfile.h (struct tzhead): Update comment for version 4. --- tzfile.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.h b/tzfile.h index ee91104..9c3ea4e 100644 --- a/tzfile.h +++ b/tzfile.h @@ -44,7 +44,7 @@ struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ - char tzh_version[1]; /* '\0' or '2' or '3' as of 2013 */ + char tzh_version[1]; /* '\0' or '2'-'4' as of 2021 */ char tzh_reserved[15]; /* reserved; must be zero */ char tzh_ttisutcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ -- 2.31.1

1 0

[PATCH] Change is_digit from macro to function
by Paul Eggert Sept. 11, 2021

Sept. 11, 2021

This is cleaner and should be no slower with modern optimizers. * localtime.c, zdump.c (is_digit): New static function, replacing the old macro. * private.h (is_digit): Remove this macro. --- localtime.c | 7 +++++++ private.h | 3 --- zdump.c | 8 ++++++-- 3 files changed, 13 insertions(+), 5 deletions(-) diff --git a/localtime.c b/localtime.c index 5f362d4..cc972ef 100644 --- a/localtime.c +++ b/localtime.c @@ -778,6 +778,13 @@ static const int year_lengths[2] = { DAYSPERNYEAR, DAYSPERLYEAR }; +/* Is C an ASCII digit? */ +static bool +is_digit(char c) +{ + return '0' <= c && c <= '9'; +} + /* ** Given a pointer into a timezone string, scan until a character that is not ** a valid character in a time zone abbreviation is found. diff --git a/private.h b/private.h index 98ead55..4c03324 100644 --- a/private.h +++ b/private.h @@ -225,9 +225,6 @@ #define R_OK 4 #endif /* !defined R_OK */ -/* Unlike <ctype.h>'s isdigit, this also works if c < 0 | c > UCHAR_MAX. */ -#define is_digit(c) ((unsigned)(c) - '0' <= 9) - /* ** Define HAVE_STDINT_H's default value here, rather than at the ** start, since __GLIBC__ and INTMAX_MAX's values depend on diff --git a/zdump.c b/zdump.c index 3c71894..9d22b26 100644 --- a/zdump.c +++ b/zdump.c @@ -99,8 +99,12 @@ static void showtrans(char const *, struct tm const *, time_t, char const *, static const char *tformat(void); static time_t yeartot(intmax_t) ATTRIBUTE_PURE; -/* Unlike <ctype.h>'s isdigit, this also works if c < 0 | c > UCHAR_MAX. */ -#define is_digit(c) ((unsigned)(c) - '0' <= 9) +/* Is C an ASCII digit? */ +static bool +is_digit(char c) +{ + return '0' <= c && c <= '9'; +} /* Is A an alphabetic character in the C locale? */ static bool -- 2.31.1

1 0

[PROPOSED] Relax leap-second pickiness
by Paul Eggert Sept. 10, 2021

Sept. 10, 2021

* localtime.c (tzloadbody): Relax requirements on the leap second table in a TZif file, to accommodate truncation at the start that is less than 28 days before a leap second, or (unlikely, though theoretically possible) expiration less than 28 days after the last leap second. --- localtime.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/localtime.c b/localtime.c index e4f1a87..5f362d4 100644 --- a/localtime.c +++ b/localtime.c @@ -436,7 +436,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, for (stored = 4; stored <= 8; stored *= 2) { int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); - int_fast64_t prevtr = 0; + int_fast64_t prevtr = -1; int_fast32_t prevcorr; int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); @@ -526,24 +526,21 @@ tzloadbody(char const *name, struct state *sp, bool doextend, int_fast64_t tr = stored == 4 ? detzcode(p) : detzcode64(p); int_fast32_t corr = detzcode(p + stored); p += stored + 4; - /* Leap seconds cannot occur before the Epoch. */ - if (tr < 0) + /* Leap seconds cannot occur before the Epoch, + or out of order. */ + if (tr <= prevtr) return EINVAL; if (tr <= TIME_T_MAX) { - /* Leap seconds cannot occur more than once per UTC month, - and UTC months are at least 28 days long (minus 1 - second for a negative leap second). Each leap second's + /* To avoid other botches in this code, each leap second's correction must differ from the previous one's by 1 second or less, except that the first correction can be any value; these requirements are more generous than RFC 8536, to allow future RFC extensions. */ - if (tr - prevtr < 28 * SECSPERDAY - 1 - || ((timecnt == 0 || sp->ats[0] < tr) - && ! (i == 0 - || (prevcorr < corr - ? corr == prevcorr + 1 - : (corr == prevcorr - || corr == prevcorr - 1))))) + if (! (i == 0 + || (prevcorr < corr + ? corr == prevcorr + 1 + : (corr == prevcorr + || corr == prevcorr - 1)))) return EINVAL; sp->lsis[leapcnt].ls_trans = prevtr = tr; sp->lsis[leapcnt].ls_corr = prevcorr = corr; -- 2.31.1

1 0

Format for Asia/Bangkok
by Danilo Spinella Sept. 10, 2021

Sept. 10, 2021

Hi there! I have noticed that the format for the zone Asia/Bangkok is shown as "+07" instead of Indochina Time (ICT), Western Indonesian Time (WIB) or Thailand Standard Time (THA). Is this because none of the above is standard? Best Regards, Danilo Spinella

2 1

[PATCH] White space fixes
by Paul Eggert Sept. 10, 2021

Sept. 10, 2021

--- localtime.c | 2 +- zdump.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/localtime.c b/localtime.c index a70b67a..e4f1a87 100644 --- a/localtime.c +++ b/localtime.c @@ -2379,7 +2379,7 @@ time(time_t *p) if (r != (time_t) -1) { int_fast32_t offset = EPOCH_LOCAL ? (daylight ? timezone : altzone) : 0; if (increment_overflow32(&offset, -EPOCH_OFFSET) - || increment_overflow_time (&r, offset)) { + || increment_overflow_time(&r, offset)) { errno = EOVERFLOW; r = -1; } diff --git a/zdump.c b/zdump.c index f2ff442..3c71894 100644 --- a/zdump.c +++ b/zdump.c @@ -73,7 +73,7 @@ extern int optind; #endif /* The minimum and maximum finite time values. */ -enum { atime_shift = CHAR_BIT * sizeof (time_t) - 2 }; +enum { atime_shift = CHAR_BIT * sizeof(time_t) - 2 }; static time_t const absolute_min_time = ((time_t) -1 < 0 ? (- ((time_t) ~ (time_t) 0 < 0) -- 2.30.2

1 0

Re: [tz] ICANN News Alert - ICANN to Manage Time Zone Database
by Parsam Parham Sept. 10, 2021

Sept. 10, 2021

=======

3 2

Timezone change detection
by Edward Tomasz Napierała Sept. 4, 2021

Sept. 4, 2021

Hello. I'm working on upstreaming a patch, which originally came from NetApp, to modify localtime.c to automatically detect changes to the time zone. The use case is to make the applications handle moving between timezones, or changing the default system timezone. The idea is pretty simple: just stat(2) the timezone file inode to make sure it still refers to the same file it previously did, and make sure to do this at most once per minute. The patch (with the FreeBSD-specific build glue stripped) follows; previous discussion can be found at https://reviews.freebsd.org/D30183. The patch was written for FreeBSD version of localtime.c, which differs a bit from upstream, but as there seems to be an effort underway to sync FreeBSD with upstream, I believe it also makes sense to ask for comments here before commiting it to FreeBSD. Any feedback is welcome. Thanks :-) diff --git a/contrib/tzcode/stdtime/localtime.c b/contrib/tzcode/stdtime/localtime.c index e221c1fa396..926b24470e1 100644 --- a/contrib/tzcode/stdtime/localtime.c +++ b/contrib/tzcode/stdtime/localtime.c @@ -354,6 +354,45 @@ settzname(void) } } +#ifdef DETECT_TZ_CHANGES +/* + * Determine if there's a change in the timezone since the last time we checked. + * Returns: -1 on error + * 0 if the timezone has not changed + * 1 if the timezone has changed + */ +static int +change_in_tz(const char *name) +{ + static char old_name[PATH_MAX]; + static struct stat old_sb; + struct stat sb; + int error; + + error = stat(name, &sb); + if (error != 0) + return -1; + + if (strcmp(name, old_name) != 0) { + strlcpy(old_name, name, sizeof(old_name)); + old_sb = sb; + return 1; + } + + if (sb.st_dev != old_sb.st_dev || + sb.st_ino != old_sb.st_ino || + sb.st_ctime != old_sb.st_ctime || + sb.st_mtime != old_sb.st_mtime) { + old_sb = sb; + return 1; + } + + return 0; +} +#else /* !DETECT_TZ_CHANGES */ +#define change_in_tz(X) 0 +#endif /* !DETECT_TZ_CHANGES */ + static int differ_by_repeat(const time_t t1, const time_t t0) { @@ -379,6 +418,7 @@ register const int doextend; int stored; int nread; int res; + int ret; union { struct tzhead tzhead; char buf[2 * sizeof(struct tzhead) + @@ -427,6 +467,22 @@ register const int doextend; (void) strcat(fullname, name); name = fullname; } + if (doextend == TRUE) { + /* + * Detect if the timezone file has changed. Check + * 'doextend' to ignore TZDEFRULES; the change_in_tz() + * function can only keep state for a single file. + */ + ret = change_in_tz(name); + if (ret <= 0) { + /* + * Returns -1 if there was an error, + * and 0 if the timezone had not changed. + */ + free(fullname); + return ret; + } + } if ((fid = _open(name, OPEN_MODE)) == -1) { free(fullname); return -1; @@ -1209,12 +1265,43 @@ gmtload(struct state *const sp) (void) tzparse(gmt, sp, TRUE); } +#ifdef DETECT_TZ_CHANGES +static int +recheck_tzdata() +{ + static time_t last_checked; + struct timespec now; + time_t current_time; + int error; + + /* + * We want to recheck the timezone file every 61 sec. + */ + error = clock_gettime(CLOCK_MONOTONIC, &now); + if (error <= 0) { + /* XXX: Can we somehow report this? */ + return 0; + } + + current_time = now.tv_sec; + if ((current_time - last_checked > 61) || + (last_checked > current_time)) { + last_checked = current_time; + return 1; + } + + return 0; +} +#else /* !DETECT_TZ_CHANGES */ +#define recheck_tzdata() 0 +#endif /* !DETECT_TZ_CHANGES */ + static void tzsetwall_basic(int rdlocked) { if (!rdlocked) _RWLOCK_RDLOCK(&lcl_rwlock); - if (lcl_is_set < 0) { + if (lcl_is_set < 0 && recheck_tzdata() == 0) { if (!rdlocked) _RWLOCK_UNLOCK(&lcl_rwlock); return;

5 10

New tzexplorer.org website
by Kerry Shetline Sept. 2, 2021

Sept. 2, 2021

I’ve created a new website, http://tzexplorer.org <http://tzexplorer.org/>, that makes it easy to do conversions among IANA timezones and other time standards like TAI, view the history of time transitions in any timezone, and download TZ code and data in .zip format. There are also links to open-source JavaScript code for the related data/time library, timezone compiler, and Angular components. Please let me know what you think, and if you have any suggestions for changes or additions to the website.

3 2

tz-announce GPG key renewed
by Paul Eggert Sept. 2, 2021

Sept. 2, 2021

The GPG key I use in tz-announce notices expired on August 31. I renewed it for another five years, and the renewed version is appended to this email. Copies of the key are also available for download from my UCLA home directory <https://www.cs.ucla.edu/~eggert/public-key.gpg> and from my Savannah.gnu.org web page <https://savannah.gnu.org/users/eggert>. -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqf hpxxdGA9Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9Xm AAtmXqeZVIYX/UFS96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Y gd7gx07Auwp7iw7eNvnoDTAlKAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kgh y+P6au6PrIIhYraeua7XDdb2LS1en3SsmE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6 x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZKQMr9amVPknjfPmJISqdhgB1D lEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2Sf1tk5eU8MBiyN/b Z03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujCOJVxq2kl jBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6C nrQzvJbBn6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQAB tCBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PokCVQQTAQgAPwIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQR+N5Kp2Kz31jO8FYjtl+kOYqp+NAUC YTAc/AUJHhWsGAAKCRDtl+kOYqp+NBKwD/9Qise9/wZsD8Nyl+ADOCIAFZY5qlSl /5SyCjJIRc6cx/Z0fm4yJVH2Tf3GlSBk1uW24z8+mB2ZxFQUGjio/2iDndSqxYR4 qvPGudo4RGvdvhw6LLqTdRsAY4947xLpNUO6gDtZsRpn4isn+ViX85XfGJrIFjBm zj70eMxEZZrz1IMfUB5I/2oNGDsXDZlCUU30RFMYChGA1ofpIHWdAs+lW2jVBfeE Lbi2su+oUpqrx83u0eJQg3RY3jmPjw8snHS4ieXpvS0e89qziBlNCqS59qJHaf4G XCjz+o5gap2e0NEeQYqcyCqAfqjI78KEpVJNQx5D/zSOvnNs6KuzWD7No4nb5A3p A6KA1JAwJW0H3F2+RhTEg+kFxpcCen0jjuFBnE3TfO3RSpSGqZN0j4AkuR6h/+I7 uUfaQAAope4mso/9VBEElaHYTQmA/m4/AXb2Kt/qkt6QgUIyJtSKcMCVTbfL6iIj rzu4EzkjtZJkbAfvU8lpkUsWX2Qwo25MwyxyzsHMUq9ccIRPEiI0hVu7jeFAql6c ql/3KUWvSr8QCyn7KWhfxyzy6j0+2xtQ29LHAOhboawJJoZd+PtintzHSSZ6G+8T Xn3EbjmHHlXWWfnvWyaJCuJzf1PybRgNYqL6EXCHRHCIb4S9Av8sJpJzZiskG1v5 WUkv79aHb1ol14kCHAQQAQIABgUCVi604AAKCRDNVPzj2WS++xxpD/4hZPbOUfcF LwePuSD3tqKrcmAq0vmyND1aNSOht0OlUbnHtsWxJmThEVEF25VfPbWhD+DZjRj8 hkQNzgkdeLJXJNj8JqS/MedrVa3j3wzHAnSt6fIQ8VvLmZDYg2gCpZrlU/y15Oby OrPkgOCC6MC2PFwHnEpAfR0d6AdbZ+ZeLqbvkB/tkMsqroNMSlPtgq8AWCKX++WJ TBpSw0o/iZjNkq7jW/BWgEVn51oTH8mgS2QN7mxltlaGG3x0AINjKcawfTX+lPks dZ5h9Fy+2QD9MoeAoEKsrS1zFYSVAVwrVAGwvAvz7sFxYzAh0Z+IO80Vwvm8VWfK rKr+483dzR7MzqfQyuCfMwEWg+hQ8r26qCRbe5KgNozVLsV3f1Sj5PwwnT5KE7jg ikYHGk+kSti1V/PiiKfCn9VAHvDad4P+o11R7aH4PaoZYb0M+S7FmKaQfeWcpymH LmpfG8JA7MCsQY0U7ix2jYHIjRZZgolYJ8T2JFf4VlzhiwsMwFNycPqNmGHF4da1 dm248ugKqLFls2aVdb9mTlFYrUQOtLN/FizELEv8dXt4A1bjoK9pO1ZFwffgfP5a fmFjHMSX6Z3KcXGmXZ1tYQocco7S4J4PyERGFhTyT7skXIzuml59+2G4WxGiatJI 3hhxaN0237vot5sIVDl1TpCMLr/02+qKfbkCDQRMgHJkARAApoXrvxP3DIfjCNOt XU/PdwMShKdX/RlSs5PfunV1wbKP8herXHrvQdFVqECaTSxmlhzbk8X0PkY9gcVa U2O49T3qsOd1cHeF52YFGEt0LhsBeMjgNX5uZ1V76r8gyeVlFpWWb0SIwJUBHrDX exF67upeRb2vdHBjYDNeySn+0B7gFEqvVmZu+LadudDp6kQLjatFvHQHUSGNshBn kkcaTbiI9Pst0GCc2aiznBiPPA2WQxAPlPRh3OGTsn5THADmbjqY6FEMLasVX8DS CblMvLwNeO/8SxziBidhqLpJCqdQRWHku5XxgIkGeKOz5OLDvXHWJyafrEYjjkS6 Ak6B5z6svKliClWnjHQcjlPzyoFFgKTEfcqDxCj4RY0D0DgtFD0NfyeOidrSB/Sz Te2hwryQE3rpSiqo+0cGdzh4yAHKYJ+UrXZ4p93ZhjGfKD1xlrNYDlWyW9PGmbvq FuDmiIAQf9WD/wzEfICc+F+uDDI+uYkRxUFp92ykmdhDEFg1yjYsU8iGU69aHyvh q36z4zctvbqhRNzOWB1bVJ/dIMDvsExGcXQVDIT7sDNXv0wE3jKSKpp7NDG1oXUX L+2+SF99Kjy753AbQSAmH617fyBNwhJWvQYg+mUvPpiGOtses9EXUI3lS4v0MEaP G43flEs1UR+1rpFQWVHo1y1OO+sAEQEAAYkCPAQYAQgAJgIbDBYhBH43kqnYrPfW M7wViO2X6Q5iqn40BQJhMB1RBQkeFaxtAAoJEO2X6Q5iqn40d5QP/iRm1LyrCKbM dqgP9ShOcPH7UfFEr4SY2TDdQgE4L+QItP16RNgTxAkxaBxK95I0nletr03inRKw sb0dIw/BH2LXbG2DjI6yKJK6UThVhWWBXYuGjSv2i6bVIzHLRY3IOQF+8dyVJ+vo eaOtxdV1lYR1ke/Dv6pFqUGGNBsSVu/2R03uCffTA9OsRzbuV5mJrFgxVFmBAguL N/cT5Ffh77x3LsA61Ro3hIX4399GFFBQ3h4RfMA1nNWiU0KjNy/GtW0amxn26zhq Qvy0W0hEJRA6ts+e/4ZHwcX3U7NTnPTckbCyy71d7U8/AVHkoy7EB8ROcDbJHTJc KlG9f6eYlPZ2aYVqBd9n1Yj4NYT1zobrQjvHQRCUAx0naKscN2es9x/rWvg4BnnB cXRaT2a8Wy3pKzLGD61dstvUM7tnyvdBxHk7aLlbdsfZP+flP2tbHkFNZWH5myPE lPMcQGFYyi9to+4YZU28G3rnzxmKFWkYAEMaxPZPunOZnOBHURFhgk/qs6GYSTPv g0u/kd1JV2yOKHb8+SB/Dpk/gx9KybTUC3TtbW1b2X94ErB8LCmpMi26a3ZvyxrE 5DJx2GdUoj2QkKTSFQV7MOo1tJ9vwtSfHnpT/+E6yKtzCLl9CNiVjd57puN1BhWC VvLwfAzUC2UvpPYh8u3maJaMAC6BgK78 =JpE/ -----END PGP PUBLIC KEY BLOCK-----

1 0

tzcode: uninitialized sp->charcnt gives clang analyzer warning
by Jan Engelhardt Aug. 11, 2021

Aug. 11, 2021

When building tzcode commit 7f74206b39673b1a110285c6992f70507e211060 with -DALL_STATE, clang reports a loop with a undefined termination condition because sp->charcnt is not set before its use. There should probably be a sp->charcnt=0 in zoneinit. >> clang --analyze -Xanalyzer -analyzer-output=text localtime.c -DALL_STATE localtime.c:321:16: warning: The right operand of '<' is a garbage value [core.UndefinedBinaryOperatorResult] for (i = 0; i < sp->charcnt; ++i) ^ localtime.c:2210:7: note: 'err' is 0 if (err) { ^~~ localtime.c:2210:3: note: Taking false branch if (err) { ^ localtime.c:2214:3: note: Calling 'tzset_unlocked' tzset_unlocked(); ^~~~~~~~~~~~~~~~ localtime.c:1383:13: note: Assuming 'name' is null int lcl = name ? strlen(name) < sizeof lcl_TZname : -1; ^~~~ localtime.c:1383:13: note: '?' condition is false localtime.c:1384:7: note: 'lcl' is < 0 if (lcl < 0 ^~~ localtime.c:1384:7: note: '?' condition is true localtime.c:1385:9: note: Assuming 'lcl_is_set' is >= 0 ? lcl_is_set < 0 ^~~~~~~~~~~~~~ localtime.c:1384:3: note: Taking false branch if (lcl < 0 ^ localtime.c:1389:7: note: Assuming 'sp' is null if (! sp) ^~~~ localtime.c:1389:3: note: Taking true branch if (! sp) ^ localtime.c:1390:19: note: Uninitialized value stored to field 'charcnt' lclptr = sp = malloc(sizeof *lclptr); ^~~~~~~~~~~~~~~~~~~~~~ localtime.c:1392:7: note: Assuming 'sp' is non-null if (sp) { ^~ localtime.c:1392:3: note: Taking true branch if (sp) { ^ localtime.c:1393:9: note: Calling 'zoneinit' if (zoneinit(sp, name) != 0) ^~~~~~~~~~~~~~~~~~ localtime.c:1355:7: note: 'name' is null if (name && ! name[0]) { ^~~~ localtime.c:1355:12: note: Left side of '&&' is false if (name && ! name[0]) { ^ localtime.c:1369:15: note: Calling 'tzload' int err = tzload(name, sp, true); ^~~~~~~~~~~~~~~~~~~~~~ localtime.c:739:7: note: Assuming 'lsp' is null if (!lsp) ^~~~ localtime.c:739:3: note: Taking true branch if (!lsp) ^ localtime.c:740:5: note: Returning without writing to 'sp->charcnt' return errno; ^ localtime.c:1369:15: note: Returning from 'tzload' int err = tzload(name, sp, true); ^~~~~~~~~~~~~~~~~~~~~~ localtime.c:1370:9: note: Assuming 'err' is equal to 0 if (err != 0 && name && name[0] != ':' && tzparse(name, sp, NULL)) ^~~~~~~~ localtime.c:1370:18: note: Left side of '&&' is false if (err != 0 && name && name[0] != ':' && tzparse(name, sp, NULL)) ^ localtime.c:1372:9: note: 'err' is equal to 0 if (err == 0) ^~~ localtime.c:1372:5: note: Taking true branch if (err == 0) ^ localtime.c:1373:7: note: Calling 'scrub_abbrs' scrub_abbrs(sp); ^~~~~~~~~~~~~~~ localtime.c:321:16: note: The right operand of '<' is a garbage value for (i = 0; i < sp->charcnt; ++i) ^ ~~~~~~~~~~~ localtime.c:1277:4: warning: Value stored to 'theiroffset' is never read [deadcode.DeadStores] theiroffset = theirstdoffset; ^ ~~~~~~~~~~~~~~ localtime.c:1277:4: note: Value stored to 'theiroffset' is never read theiroffset = theirstdoffset; ^ ~~~~~~~~~~~~~~ 2 warnings generated.

5 11

No leap second on 2021-12-31
by Tim Parenti July 22, 2021

July 22, 2021

Per IERS, Bulletin C 62 (2021-07-05) https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.62 …and forwarded below. A patch updating leap-seconds.list from NIST is attached, and is installed in the development repository. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Mon, 5 Jul 2021 at 05:54 Subject: Bulletin C number 62 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 05 July 2021 Bulletin C 62 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of December 2021. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0

Need input - minimal tzdata install
by Patsy Griffin July 21, 2021

July 21, 2021

Hi, We are trying to reduce the required base installation on containers. We are looking at ways to reduce the amount of timezone data needed. Specifically, we are considering providing a minimal/UTC-only tzdata package. Is this something that the tz project would consider providing? Would the tz project be willing to document a recommended minimum set of files for such an installation? Thanks, Patsy

3 3

[PROPOSED] Do not include sys/wait.h
by Paul Eggert July 15, 2021

July 15, 2021

This cleans up some code no longer needed now that we’ve dropped support for zic -y. Issue noted by spazmodius in: https://github.com/eggert/tz/commit/284e877d7511d964249ecfd2e75a9cab85e2741… * Makefile, NEWS: Update commentary. * private.h (HAVE_SYS_WAIT_H): Remove. All uses removed. * zic.c: Do not include sys/wait.h. (WIFEXITED, WEXITSTATUS): Remove; unused. --- Makefile | 1 - NEWS | 3 +++ private.h | 4 ---- zic.c | 11 ----------- 4 files changed, 3 insertions(+), 16 deletions(-) diff --git a/Makefile b/Makefile index 77ef331..f441fce 100644 --- a/Makefile +++ b/Makefile @@ -222,7 +222,6 @@ LDLIBS= # -DHAVE_STRTOLL=0 if your system lacks the strtoll function # -DHAVE_SYMLINK=0 if your system lacks the symlink function # -DHAVE_SYS_STAT_H=0 if your compiler lacks a <sys/stat.h> -# -DHAVE_SYS_WAIT_H=0 if your compiler lacks a <sys/wait.h> # -DHAVE_TZSET=0 if your system lacks a tzset function # -DHAVE_UNISTD_H=0 if your compiler lacks a <unistd.h> # -Dlocale_t=XXX if your system uses XXX instead of locale_t diff --git a/NEWS b/NEWS index 53890a7..f53e431 100644 --- a/NEWS +++ b/NEWS @@ -124,6 +124,9 @@ Unreleased, experimental changes "EST5EDT,0/0,J365/25" or "". (Thanks to Michael Deckers for noting the possibility of POSIX conformance.) + zic.c no longer requires sys/wait.h (thanks to spazmodius for + noting it wasn't needed). + When reading slim TZif files, zdump no longer mishandles leap seconds on the rare platforms where time_t counts leap seconds, fixing a bug introduced in 2014g. diff --git a/private.h b/private.h index 340a354..6425298 100644 --- a/private.h +++ b/private.h @@ -90,10 +90,6 @@ #define HAVE_SYS_STAT_H 1 #endif /* !defined HAVE_SYS_STAT_H */ -#ifndef HAVE_SYS_WAIT_H -#define HAVE_SYS_WAIT_H 1 -#endif /* !defined HAVE_SYS_WAIT_H */ - #ifndef HAVE_UNISTD_H #define HAVE_UNISTD_H 1 #endif /* !defined HAVE_UNISTD_H */ diff --git a/zic.c b/zic.c index 77a5698..8d1ea03 100644 --- a/zic.c +++ b/zic.c @@ -48,17 +48,6 @@ typedef int_fast64_t zic_t; #define MKDIR_UMASK 0755 #endif -#if HAVE_SYS_WAIT_H -#include <sys/wait.h> /* for WIFEXITED and WEXITSTATUS */ -#endif /* HAVE_SYS_WAIT_H */ - -#ifndef WIFEXITED -#define WIFEXITED(status) (((status) & 0xff) == 0) -#endif /* !defined WIFEXITED */ -#ifndef WEXITSTATUS -#define WEXITSTATUS(status) (((status) >> 8) & 0xff) -#endif /* !defined WEXITSTATUS */ - /* The maximum ptrdiff_t value, for pre-C99 platforms. */ #ifndef PTRDIFF_MAX static ptrdiff_t const PTRDIFF_MAX = MAXVAL(ptrdiff_t, TYPE_BIT(ptrdiff_t)); -- 2.31.1

1 0

Fwd: FORMAT Missing in Africa/Windhoek & America/Belize
by vaibhav shrivastava June 28, 2021

June 28, 2021

Please check below mail ---------- Forwarded message --------- From: vaibhav shrivastava <vaibhav.sh17(a)gmail.com> Date: Fri, 25 Jun 2021, 09:07 Subject: Re: [tz] FORMAT Missing in Africa/Windhoek & America/Belize To: Arthur David Olson <arthurdavidolson(a)gmail.com> Daylight Saving Time (DST) Not Observed in Year 2021 Windhoek currently observes Central Africa Time (CAT) all year. DST is no longer in use. Clocks do not change in Windhoek, Namibia. The previous DST change in Windhoek was on 24 October 2017 Why WAT is mentioned? Why it is different from other rule and format? Regards, Vaibhav On Thu, 24 Jun 2021, 16:30 Arthur David Olson, <arthurdavidolson(a)gmail.com> wrote: > A bare "%s" in a zone line such as ... > Zone Africa/Windhoek 2:00 Namibia %s > ...means that the abbreviations are completely specified in the Rule lines > being used. In this case, the operative Rule lines are... > Rule Namibia 1994 only - Mar 21 0:00 -1:00 > WAT > Rule Namibia 1994 2017 - Sep Sun>=1 2:00 0 > CAT > Rule Namibia 1995 2017 - Apr Sun>=1 2:00 -1:00 > WAT > ...and so the abbreviations "WAT" and "CAT" are the result. > > @dashdashado > > On Thu, Jun 24, 2021 at 4:09 AM vaibhav shrivastava via tz <tz(a)iana.org> > wrote: > >> Please check FORMAT is marked as %s for these 2 timezone >> Africa/Windhoek & America/Belize >> >> >> Zone Africa/Windhoek 2:00 Namibia %s >> >> Same for >> >> America/Belize -6:00 Belize %s >> >> >> Regards, >> Vaibhav >> >>

3 8

FORMAT Missing in Africa/Windhoek & America/Belize
by vaibhav shrivastava June 24, 2021

June 24, 2021

Please check FORMAT is marked as %s for these 2 timezone Africa/Windhoek & America/Belize Zone Africa/Windhoek 2:00 Namibia %s Same for America/Belize -6:00 Belize %s Regards, Vaibhav

2 1

Tzdata - timedatectl issue
by Prasanth Ramesh June 23, 2021

June 23, 2021

Hi, I am facing an issue with the timedatectl command outputs which were wrong from 2020b version tzdata (Local time & Time zone) values were wrong are there any changes happened relevant to this? *From- tzdata-2020b version - Broken* #timedatectl * Local time: Fri 2019-11-29 16:42:57 * Universal time: Fri 2019-11-29 16:42:57 UTC RTC time: n/a * Time zone: Asia/Kolkata (, +0000)* System clock synchronized: no NTP service: inactive RTC in local TZ: no *Before tzdata-2020a - Good*#timedatectl * Local time: Fri 2019-11-29 22:03:40 IST* Universal time: Fri 2019-11-29 16:33:40 UTC RTC time: n/a * Time zone: Asia/Kolkata (IST, +0530)* System clock synchronized: no NTP service: inactive RTC in local TZ: no Thanks & Regards, Prasanth

1 1

Destruction of timezone history - please revert (typos corrected)
by Alois Treindl June 15, 2021

June 15, 2021

I consider the decision to merge zones of multiple countries, just because they share a common post-1970 history, one of the worst decisions ever made for the TZ project. There used to be Zone Europe/Copenhagen, which represented the exact timezone history of Copenhagen, in fact of all of Denmark, since the introduction of standard time in Denmark in 1890. Now the file 'europe' says # For Denmark see Europe/Berlin. But zone Europe/Berlin is a bad representation of Denmark's timezone history. It gives false data from 1949 backward. The decision to remove zones like Europe/Copenhagen from the main zone files destroys the work of a whole generation of timezone history researchers. It is a completely unnecessary step, forced by nothing. I urge the responsible persons to revert this step.

3 7

Question about invalid timezone file: no timezone found in OlsonData
by Joe Culler June 14, 2021

June 14, 2021

Hello, I have a program running on Yocto. When it runs, I get an error: /usr/share/zoneinfo/Israel: invalid timezone file: no timezone found in OlsonData If I copy zoneinfo's directory from Linux distros (Debian, Ubutnu, ArchLinux), the program runs without an error. I downloaded tzdb-2021a.tar.lz and installed it, encountered the same error. Did I miss something? Thanks. - Joe

3 3

[PROPOSED] Avoid backward links in zone.tab
by Paul Eggert June 12, 2021

June 12, 2021

Recent changes caused zone.tab to refer to links defined in the 'backward' file, which means it no longer works in the now-rare case where 'backward' is not used. Fix this by changing zone.tab to refer to the primary name of each zone. * checktab.awk: Adjust to check the new setup. * zone.tab: Replace backward links in the 3rd column with the primary zone names. This lets us fix a longstanding problem with Vietnam, as zone.tab can now have a separate entry for north Vietnam's different time zone history in the 1970s (this was already true of zone1970.tab). --- checktab.awk | 48 +++++++-------- zone.tab | 161 ++++++++++++++++++++++++++------------------------- 2 files changed, 105 insertions(+), 104 deletions(-) diff --git a/checktab.awk b/checktab.awk index 54ac0a6..d5317ac 100644 --- a/checktab.awk +++ b/checktab.awk @@ -58,11 +58,12 @@ BEGIN { zone_table, zone_NR >>"/dev/stderr" status = 1 } - split($1, cca, /,/) - cc = cca[1] + ccs = input_ccs[zone_NR] = $1 coordinates = $2 tz = $3 - comments = $4 + comments = input_comments[zone_NR] = $4 + split(ccs, cca, /,/) + cc = cca[1] # Don't complain about a special case for Crimea in zone.tab. # FIXME: zone.tab should be removed, since it is obsolete. @@ -77,12 +78,9 @@ BEGIN { cc0 = cc tz0 = tz tztab[tz] = 1 - tz2comments[tz] = comments tz2NR[tz] = zone_NR for (i in cca) { cc = cca[i] - cctz = cc tz - cctztab[cctz] = 1 if (cc2name[cc]) { cc_used[cc]++ } else { @@ -99,27 +97,27 @@ BEGIN { } } - for (cctz in cctztab) { - cc = substr (cctz, 1, 2) - tz = substr (cctz, 3) - if (1 < cc_used[cc]) { - comments_needed[tz] = cc - } - } - for (cctz in cctztab) { - cc = substr (cctz, 1, 2) - tz = substr (cctz, 3) - if (!comments_needed[tz] && tz2comments[tz]) { + for (i = 1; i <= zone_NR; i++) { + ccs = input_ccs[i] + if (!ccs) continue + comments = input_comments[i] + split(ccs, cca, /,/) + used_max = 0 + for (j in cca) { + cc = cca[j] + if (used_max < cc_used[cc]) { + used_max = cc_used[cc] + } + } + if (used_max <= 1 && comments) { printf "%s:%d: unnecessary comment '%s'\n", \ - zone_table, tz2NR[tz], tz2comments[tz] \ - >>"/dev/stderr" - tz2comments[tz] = 0 + zone_table, i, comments \ + >>"/dev/stderr" status = 1 - } else if (comments_needed[tz] && !tz2comments[tz]) { + } else if (1 < cc_used[cc] && !comments) { printf "%s:%d: missing comment for %s\n", \ - zone_table, tz2NR[tz], comments_needed[tz] \ + zone_table, i, cc \ >>"/dev/stderr" - tz2comments[tz] = 1 status = 1 } } @@ -172,14 +170,12 @@ END { status = 1 } } - if (zone_table != "zone.tab") { - for (tz in tztab) { + for (tz in tztab) { if (!zoneSeen[tz]) { printf "%s:%d: no Zone table for '%s'\n", \ zone_table, tz2NR[tz], tz >>"/dev/stderr" status = 1 } - } } if (0 < want_warnings) { for (cc in cc2name) { diff --git a/zone.tab b/zone.tab index 14fceb9..fe53f0a 100644 --- a/zone.tab +++ b/zone.tab @@ -16,6 +16,10 @@ # clocks have agreed since 1970; this is a narrower definition than # that of zone1970.tab. # +# Unlike zone1970.tab, this file's third column can contain duplicates, +# and a row's third column does not necessarily name a location within +# the country identified by the row's first column. +# # This table is intended as an aid for users, to help them select timezones # appropriate for their practical needs. It is not intended to take or # endorse any position on legal or territorial claims. @@ -25,12 +29,12 @@ AD +4230+00131 Europe/Andorra AE +2518+05518 Asia/Dubai AF +3431+06912 Asia/Kabul -AG +1703-06148 America/Antigua -AI +1812-06304 America/Anguilla +AG +1703-06148 America/Port_of_Spain +AI +1812-06304 America/Port_of_Spain AL +4120+01950 Europe/Tirane AM +4011+04430 Asia/Yerevan -AO -0848+01314 Africa/Luanda -AQ -7750+16636 Antarctica/McMurdo New Zealand time - McMurdo, South Pole +AO -0848+01314 Africa/Lagos +AQ -7750+16636 Pacific/Auckland New Zealand time - McMurdo, South Pole AQ -6617+11031 Antarctica/Casey Casey AQ -6835+07758 Antarctica/Davis Davis AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville @@ -66,23 +70,23 @@ AU -3455+13835 Australia/Adelaide South Australia AU -1228+13050 Australia/Darwin Northern Territory AU -3157+11551 Australia/Perth Western Australia (most areas) AU -3143+12852 Australia/Eucla Western Australia (Eucla) -AW +1230-06958 America/Aruba -AX +6006+01957 Europe/Mariehamn +AW +1230-06958 America/Curacao +AX +6006+01957 Europe/Helsinki AZ +4023+04951 Asia/Baku -BA +4352+01825 Europe/Sarajevo +BA +4352+01825 Europe/Belgrade BB +1306-05937 America/Barbados BD +2343+09025 Asia/Dhaka BE +5050+00420 Europe/Brussels -BF +1222-00131 Africa/Ouagadougou +BF +1222-00131 Africa/Abidjan BG +4241+02319 Europe/Sofia -BH +2623+05035 Asia/Bahrain -BI -0323+02922 Africa/Bujumbura -BJ +0629+00237 Africa/Porto-Novo -BL +1753-06251 America/St_Barthelemy +BH +2623+05035 Asia/Qatar +BI -0323+02922 Africa/Maputo +BJ +0629+00237 Africa/Lagos +BL +1753-06251 America/Port_of_Spain BM +3217-06446 Atlantic/Bermuda BN +0456+11455 Asia/Brunei BO -1630-06809 America/La_Paz -BQ +120903-0681636 America/Kralendijk +BQ +120903-0681636 America/Curacao BR -0351-03225 America/Noronha Atlantic islands BR -0127-04829 America/Belem Para (east); Amapa BR -0343-03830 America/Fortaleza Brazil (northeast: MA, PI, CE, RN, PB) @@ -101,7 +105,7 @@ BR -0640-06952 America/Eirunepe Amazonas (west) BR -0958-06748 America/Rio_Branco Acre BS +2505-07721 America/Nassau BT +2728+08939 Asia/Thimphu -BW -2439+02555 Africa/Gaborone +BW -2439+02555 Africa/Maputo BY +5354+02734 Europe/Minsk BZ +1730-08812 America/Belize CA +4734-05243 America/St_Johns Newfoundland; Labrador (southeast) @@ -133,17 +137,17 @@ CA +6043-13503 America/Whitehorse MST - Yukon (east) CA +6404-13925 America/Dawson MST - Yukon (west) CA +4916-12307 America/Vancouver Pacific - BC (most areas) CC -1210+09655 Indian/Cocos -CD -0418+01518 Africa/Kinshasa Dem. Rep. of Congo (west) -CD -1140+02728 Africa/Lubumbashi Dem. Rep. of Congo (east) -CF +0422+01835 Africa/Bangui -CG -0416+01517 Africa/Brazzaville +CD -0418+01518 Africa/Lagos Dem. Rep. of Congo (west) +CD -1140+02728 Africa/Maputo Dem. Rep. of Congo (east) +CF +0422+01835 Africa/Lagos +CG -0416+01517 Africa/Lagos CH +4723+00832 Europe/Zurich CI +0519-00402 Africa/Abidjan CK -2114-15946 Pacific/Rarotonga CL -3327-07040 America/Santiago Chile (most areas) CL -5309-07055 America/Punta_Arenas Region of Magallanes CL -2709-10926 Pacific/Easter Easter Island -CM +0403+00942 Africa/Douala +CM +0403+00942 Africa/Lagos CN +3114+12128 Asia/Shanghai Beijing Time CN +4348+08735 Asia/Urumqi Xinjiang Time CO +0436-07405 America/Bogota @@ -156,10 +160,10 @@ CY +3510+03322 Asia/Nicosia Cyprus (most areas) CY +3507+03357 Asia/Famagusta Northern Cyprus CZ +5005+01426 Europe/Prague DE +5230+01322 Europe/Berlin Germany (most areas) -DE +4742+00841 Europe/Busingen Busingen -DJ +1136+04309 Africa/Djibouti +DE +4742+00841 Europe/Zurich Swiss time +DJ +1136+04309 Africa/Nairobi DK +5540+01235 Europe/Copenhagen -DM +1518-06124 America/Dominica +DM +1518-06124 America/Port_of_Spain DO +1828-06954 America/Santo_Domingo DZ +3647+00303 Africa/Algiers EC -0210-07950 America/Guayaquil Ecuador (mainland) @@ -167,11 +171,11 @@ EC -0054-08936 Pacific/Galapagos Galapagos Islands EE +5925+02445 Europe/Tallinn EG +3003+03115 Africa/Cairo EH +2709-01312 Africa/El_Aaiun -ER +1520+03853 Africa/Asmara +ER +1520+03853 Africa/Nairobi ES +4024-00341 Europe/Madrid Spain (mainland) ES +3553-00519 Africa/Ceuta Ceuta, Melilla ES +2806-01524 Atlantic/Canary Canary Islands -ET +0902+03842 Africa/Addis_Ababa +ET +0902+03842 Africa/Nairobi FI +6010+02458 Europe/Helsinki FJ -1808+17825 Pacific/Fiji FK -5142-05751 Atlantic/Stanley @@ -180,22 +184,22 @@ FM +0658+15813 Pacific/Pohnpei Pohnpei/Ponape FM +0519+16259 Pacific/Kosrae Kosrae FO +6201-00646 Atlantic/Faroe FR +4852+00220 Europe/Paris -GA +0023+00927 Africa/Libreville +GA +0023+00927 Africa/Lagos GB +513030-0000731 Europe/London -GD +1203-06145 America/Grenada +GD +1203-06145 America/Port_of_Spain GE +4143+04449 Asia/Tbilisi GF +0456-05220 America/Cayenne -GG +492717-0023210 Europe/Guernsey +GG +492717-0023210 Europe/London GH +0533-00013 Africa/Accra GI +3608-00521 Europe/Gibraltar GL +6411-05144 America/Nuuk Greenland (most areas) GL +7646-01840 America/Danmarkshavn National Park (east coast) GL +7029-02158 America/Scoresbysund Scoresbysund/Ittoqqortoormiit GL +7634-06847 America/Thule Thule/Pituffik -GM +1328-01639 Africa/Banjul -GN +0931-01343 Africa/Conakry -GP +1614-06132 America/Guadeloupe -GQ +0345+00847 Africa/Malabo +GM +1328-01639 Africa/Abidjan +GN +0931-01343 Africa/Abidjan +GP +1614-06132 America/Port_of_Spain +GQ +0345+00847 Africa/Lagos GR +3758+02343 Europe/Athens GS -5416-03632 Atlantic/South_Georgia GT +1438-09031 America/Guatemala @@ -204,7 +208,7 @@ GW +1151-01535 Africa/Bissau GY +0648-05810 America/Guyana HK +2217+11409 Asia/Hong_Kong HN +1406-08713 America/Tegucigalpa -HR +4548+01558 Europe/Zagreb +HR +4548+01558 Europe/Belgrade HT +1832-07220 America/Port-au-Prince HU +4730+01905 Europe/Budapest ID -0610+10648 Asia/Jakarta Java, Sumatra @@ -213,29 +217,29 @@ ID -0507+11924 Asia/Makassar Borneo (east, south); Sulawesi/Celebes, Bali, Nusa ID -0232+14042 Asia/Jayapura New Guinea (West Papua / Irian Jaya); Malukus/Moluccas IE +5320-00615 Europe/Dublin IL +314650+0351326 Asia/Jerusalem -IM +5409-00428 Europe/Isle_of_Man +IM +5409-00428 Europe/London IN +2232+08822 Asia/Kolkata IO -0720+07225 Indian/Chagos IQ +3321+04425 Asia/Baghdad IR +3540+05126 Asia/Tehran IS +6409-02151 Atlantic/Reykjavik IT +4154+01229 Europe/Rome -JE +491101-0020624 Europe/Jersey +JE +491101-0020624 Europe/London JM +175805-0764736 America/Jamaica JO +3157+03556 Asia/Amman JP +353916+1394441 Asia/Tokyo KE -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek -KH +1133+10455 Asia/Phnom_Penh +KH +1133+10455 Asia/Bangkok KI +0125+17300 Pacific/Tarawa Gilbert Islands KI -0308-17105 Pacific/Enderbury Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands -KM -1141+04316 Indian/Comoro -KN +1718-06243 America/St_Kitts +KM -1141+04316 Africa/Nairobi +KN +1718-06243 America/Port_of_Spain KP +3901+12545 Asia/Pyongyang KR +3733+12658 Asia/Seoul -KW +2920+04759 Asia/Kuwait -KY +1918-08123 America/Cayman +KW +2920+04759 Asia/Riyadh +KY +1918-08123 America/Panama KZ +4315+07657 Asia/Almaty Kazakhstan (most areas) KZ +4448+06528 Asia/Qyzylorda Qyzylorda/Kyzylorda/Kzyl-Orda KZ +5312+06337 Asia/Qostanay Qostanay/Kostanay/Kustanay @@ -243,13 +247,13 @@ KZ +5017+05710 Asia/Aqtobe Aqtobe/Aktobe KZ +4431+05016 Asia/Aqtau Mangghystau/Mankistau KZ +4707+05156 Asia/Atyrau Atyrau/Atirau/Gur'yev KZ +5113+05121 Asia/Oral West Kazakhstan -LA +1758+10236 Asia/Vientiane +LA +1758+10236 Asia/Bangkok LB +3353+03530 Asia/Beirut -LC +1401-06100 America/St_Lucia -LI +4709+00931 Europe/Vaduz +LC +1401-06100 America/Port_of_Spain +LI +4709+00931 Europe/Zurich LK +0656+07951 Asia/Colombo LR +0618-01047 Africa/Monrovia -LS -2928+02730 Africa/Maseru +LS -2928+02730 Africa/Johannesburg LT +5441+02519 Europe/Vilnius LU +4936+00609 Europe/Luxembourg LV +5657+02406 Europe/Riga @@ -257,26 +261,26 @@ LY +3254+01311 Africa/Tripoli MA +3339-00735 Africa/Casablanca MC +4342+00723 Europe/Monaco MD +4700+02850 Europe/Chisinau -ME +4226+01916 Europe/Podgorica -MF +1804-06305 America/Marigot -MG -1855+04731 Indian/Antananarivo +ME +4226+01916 Europe/Belgrade +MF +1804-06305 America/Port_of_Spain +MG -1855+04731 Africa/Nairobi MH +0709+17112 Pacific/Majuro Marshall Islands (most areas) MH +0905+16720 Pacific/Kwajalein Kwajalein -MK +4159+02126 Europe/Skopje -ML +1239-00800 Africa/Bamako +MK +4159+02126 Europe/Belgrade +ML +1239-00800 Africa/Abidjan MM +1647+09610 Asia/Yangon MN +4755+10653 Asia/Ulaanbaatar Mongolia (most areas) MN +4801+09139 Asia/Hovd Bayan-Olgiy, Govi-Altai, Hovd, Uvs, Zavkhan MN +4804+11430 Asia/Choibalsan Dornod, Sukhbaatar MO +221150+1133230 Asia/Macau -MP +1512+14545 Pacific/Saipan +MP +1512+14545 Pacific/Guam MQ +1436-06105 America/Martinique -MR +1806-01557 Africa/Nouakchott -MS +1643-06213 America/Montserrat +MR +1806-01557 Africa/Abidjan +MS +1643-06213 America/Port_of_Spain MT +3554+01431 Europe/Malta MU -2010+05730 Indian/Mauritius MV +0410+07330 Indian/Maldives -MW -1547+03500 Africa/Blantyre +MW -1547+03500 Africa/Maputo MX +1924-09909 America/Mexico_City Central Time MX +2105-08646 America/Cancun Eastern Standard Time - Quintana Roo MX +2058-08937 America/Merida Central Time - Campeche, Yucatan @@ -293,7 +297,7 @@ MY +0133+11020 Asia/Kuching Sabah, Sarawak MZ -2558+03235 Africa/Maputo NA -2234+01706 Africa/Windhoek NC -2216+16627 Pacific/Noumea -NE +1331+00207 Africa/Niamey +NE +1331+00207 Africa/Lagos NF -2903+16758 Pacific/Norfolk NG +0627+00324 Africa/Lagos NI +1209-08617 America/Managua @@ -304,7 +308,7 @@ NR -0031+16655 Pacific/Nauru NU -1901-16955 Pacific/Niue NZ -3652+17446 Pacific/Auckland New Zealand (most areas) NZ -4357-17633 Pacific/Chatham Chatham Islands -OM +2336+05835 Asia/Muscat +OM +2336+05835 Asia/Dubai PA +0858-07932 America/Panama PE -1203-07703 America/Lima PF -1732-14934 Pacific/Tahiti Society Islands @@ -359,32 +363,32 @@ RU +4658+14242 Asia/Sakhalin MSK+08 - Sakhalin Island RU +6728+15343 Asia/Srednekolymsk MSK+08 - Sakha (E); North Kuril Is RU +5301+15839 Asia/Kamchatka MSK+09 - Kamchatka RU +6445+17729 Asia/Anadyr MSK+09 - Bering Sea -RW -0157+03004 Africa/Kigali +RW -0157+03004 Africa/Maputo SA +2438+04643 Asia/Riyadh SB -0932+16012 Pacific/Guadalcanal SC -0440+05528 Indian/Mahe SD +1536+03232 Africa/Khartoum SE +5920+01803 Europe/Stockholm SG +0117+10351 Asia/Singapore -SH -1555-00542 Atlantic/St_Helena -SI +4603+01431 Europe/Ljubljana -SJ +7800+01600 Arctic/Longyearbyen -SK +4809+01707 Europe/Bratislava -SL +0830-01315 Africa/Freetown -SM +4355+01228 Europe/San_Marino -SN +1440-01726 Africa/Dakar -SO +0204+04522 Africa/Mogadishu +SH -1555-00542 Africa/Abidjan +SI +4603+01431 Europe/Belgrade +SJ +7800+01600 Europe/Oslo +SK +4809+01707 Europe/Prague +SL +0830-01315 Africa/Abidjan +SM +4355+01228 Europe/Rome +SN +1440-01726 Africa/Abidjan +SO +0204+04522 Africa/Nairobi SR +0550-05510 America/Paramaribo SS +0451+03137 Africa/Juba ST +0020+00644 Africa/Sao_Tome SV +1342-08912 America/El_Salvador -SX +180305-0630250 America/Lower_Princes +SX +180305-0630250 America/Curacao SY +3330+03618 Asia/Damascus -SZ -2618+03106 Africa/Mbabane +SZ -2618+03106 Africa/Johannesburg TC +2128-07108 America/Grand_Turk TD +1207+01503 Africa/Ndjamena TF -492110+0701303 Indian/Kerguelen -TG +0608+00113 Africa/Lome +TG +0608+00113 Africa/Abidjan TH +1345+10031 Asia/Bangkok TJ +3835+06848 Asia/Dushanbe TK -0922-17114 Pacific/Fakaofo @@ -396,12 +400,12 @@ TR +4101+02858 Europe/Istanbul TT +1039-06131 America/Port_of_Spain TV -0831+17913 Pacific/Funafuti TW +2503+12130 Asia/Taipei -TZ -0648+03917 Africa/Dar_es_Salaam +TZ -0648+03917 Africa/Nairobi UA +5026+03031 Europe/Kiev Ukraine (most areas) UA +4837+02218 Europe/Uzhgorod Transcarpathia UA +4750+03510 Europe/Zaporozhye Zaporozhye and east Lugansk -UG +0019+03225 Africa/Kampala -UM +2813-17722 Pacific/Midway Midway Islands +UG +0019+03225 Africa/Nairobi +UM +2813-17722 Pacific/Pago_Pago Midway Islands UM +1917+16637 Pacific/Wake Wake Island US +404251-0740023 America/New_York Eastern (most areas) US +421953-0830245 America/Detroit Eastern - MI (most areas) @@ -435,17 +439,18 @@ US +211825-1575130 Pacific/Honolulu Hawaii UY -345433-0561245 America/Montevideo UZ +3940+06648 Asia/Samarkand Uzbekistan (west) UZ +4120+06918 Asia/Tashkent Uzbekistan (east) -VA +415408+0122711 Europe/Vatican -VC +1309-06114 America/St_Vincent +VA +415408+0122711 Europe/Rome +VC +1309-06114 America/Port_of_Spain VE +1030-06656 America/Caracas -VG +1827-06437 America/Tortola -VI +1821-06456 America/St_Thomas -VN +1045+10640 Asia/Ho_Chi_Minh +VG +1827-06437 America/Port_of_Spain +VI +1821-06456 America/Port_of_Spain +VN +1045+10640 Asia/Bangkok Vietnam (north) +VN +1045+10640 Asia/Ho_Chi_Minh Vietnam (south) VU -1740+16825 Pacific/Efate WF -1318-17610 Pacific/Wallis WS -1350-17144 Pacific/Apia -YE +1245+04512 Asia/Aden -YT -1247+04514 Indian/Mayotte +YE +1245+04512 Asia/Riyadh +YT -1247+04514 Africa/Nairobi ZA -2615+02800 Africa/Johannesburg -ZM -1525+02817 Africa/Lusaka -ZW -1750+03103 Africa/Harare +ZM -1525+02817 Africa/Maputo +ZW -1750+03103 Africa/Maputo -- 2.27.0

21 80

Regarding TimezoneDb page on Wiki
by Sachin Mahajan June 12, 2021

June 12, 2021

Dear Folks at IANA, Todays Greetings!!, I really appreciate your efforts to design & maintain TimezoneDb While searching on the net, I couldn't find any list where there is a mapping between 2 different set of timezone record schemes. For example "Europe/Vienna" maps to "(CET) Central European Time" So, I prepared a list for the same.(see the screenshot attached), along with relevant record like timeOffsets, countryCode, hasDST, etc., & want to share it with you IF it is of any value for the cause.I used wiki references & some PHP code for the same. If you think that my list is of any value, I will be glad to share the Excel worksheet it with you.. Thanks & Regards, Sachin M PS: Is there any reason why you haven't differentiated between North America & South America in the tz database?

1 0

Destruction of timezone history - please revert
by Alois Treindl June 12, 2021

June 12, 2021

I consider the decision to merge zones of multiple countries, just because they share a common post-1970 history, one of the worst decisions ever made for the TZ project. There used to be Zone Europe/Copenhagen, which represented the exact timezone history of Copenhagen, in fact all of Denmark, since the introduction of standard time in Denmark in 1890. Not the file 'europe' says # For Denmark see Europe/Berlin. But zone Europe/Berlin is a bad representation Denmark's timezone history. It gives false data from 1949 backward. The decision to remove zones like Europe/Copenhagen from the main zone files destroys the work of a whole generation of timezone history researchers. It is a completely unnecessary step, forced by nothing. I urge the responsible persons top revert this step.

1 0

Re: [tz] Vanguard vs. "main" vs. rearguard
by Paul Eggert June 9, 2021

June 9, 2021

On 5/20/21 10:50 AM, Kerry Shetline wrote: > Is there a particular reason that the following situation is handled with bespoke awk processing: The goal was to keep the data source simple, and put hacks into ziguard.awk when that's easy. I would rather not have these hacks bleed into the data source. > It would be great if the special comments would be all one needed to parse the data for rearguard, main, or vanguard. I see where you're coming from, but that's not the goal here. I didn't want to invent a preprocessor for zic, creating technology that would have to be documented and supported and have backwards-compatibility problems of its own. The vanguard/main/rearguard stuff is just a hopefully-temporary hack that, once it evaporates, will require zero maintenance. By the way, is anybody still using rearguard format? If not, perhaps it's time to retire this stuff now. (That would save us all the hassle of conversations like this one. :-)

4 7

What data should TZDB offer?
by Stephen Colebourne June 7, 2021

June 7, 2021

TZDB has seen recent difficulties due to conflicting desires and expectations of the dataset. This is an attempt to capture some of these: 1) LMT LMT is confusing for many downstream users because they don't understand the concept. Recent threads have noted queries from Postgres users, I can attest to confusion in various Java libraries. In fact, earlier versions of Java removed the LMT concept. I think the time is right to properly consider an alternative to LMT. I believe we can define an offset for each region that the region has most typically been associated with post 1970. For example, Europe/Paris is most associated with +01:00 since 1970. This provides the "normal looking" offset that most users desire for the LMT period. 2) Negative DST Negative DST in the source files continues to be a problem, but we should address other issues first. 3) Links At present, it is not possible to identify which region names are deprecated (such as spelling changes) and which represent important data. Having such a distinction would allow permanent deprecations to be removed from some downstream systems, and would also allow downstream systems to provide functionality to normalize IDs from old to new in a correct and consistent way. 4) Pre-1970 history There is general, though not compete, agreement that TZDB's main focus is on post-1970 data. However I and others have an expectation that pre-1970 data is retained and not be removed. I don't want to get into a position where pre-1970 history is basically completely unreliable relative to the name of the ID. Getting Germany's pre-1970 rules when you have an ID for Oslo or Sweden is not acceptable. (We already have some of that, but the recent proposal would have greatly increased the issue. I feel that there is the potential to achieve an agreeable solution, but it does require acceptance that full pre-1970 history is needed for some places that have the same zone history post-1970. 5) Compatibility guarantee Changes need to be made with more consideration of the implications of compatibility on downstream users that do not use the makefile. Proposal ------------ That TZDB shall adopt the principle that the main geographic files (africa to southamerica) shall contain data with full history for locations where zone history has differed since 1970 subject to the minimum requirement that there is at least one full zone with history defined for each independent country as defined by ISO-3166-1. Dependent territories in ISO-3166-1 that are within 1/24th of the earth circumference of another dependent territory or parent country with the same sovereignty shall be combined if their post-1970 history is identical. That TZDB shall replace LMT with the offset that best represents standard time for the location during the period 1970 to 2021. That TZDB shall define a non-makefile mechanism, which may involve a new file, to identify permanently deprecated IDs, such as "Turkey" or "W-SU". That TZDB shall offer a command line makefile flag that filters the data to reduce the binary output where data is the same post-1970. That consideration is given to whether this flag should erase pre-1970 history as part of it's truncation process. That these rules shall be encoded in the theory file along with an explicit statement of backwards compatibility. ----- It is my belief that this proposal meets the issues expressed above while also respecting the concerns of fairness, guidelines and politics expressed by others. For example, TZDB would not include a full zone with history for Kosovo until ISO-3166-1 includes it. This provides a straightforward defence against the worst issues of politics. The dependent territory rules are designed to allow locations that are close to each other in distance and sovereignty to be combined, such as Jersey and London. I have not analyzed how many zones of full history can be saved by this mechanism. I acknowledge that the above is a significant change to TZBD, but it does more fully align TZDB with the Governmental authorities that actually define time zones. I also believe it more closely aligns TZDB with the expectations of downstream users. Stephen

13 25

[PATCH] Update Android URL on tz-link page
by Almaz Mingaleev June 7, 2021

June 7, 2021

The APK-based time zone date update mechanism was deprecated so the current link to Play Store is misleading. The new link gives relevant information and is kept up-to-date.

1 0

Breach of tzdb charter: Merging timezones is not within the charter
by Stephen Colebourne June 4, 2021

June 4, 2021

This is a formal request to revert the recent patch to merge country timezones. I, and others, consider the patch to be utterly unacceptable. The patch causes meaningful harm to the status of tzdb, and will cause downstream projects significant pain to effectively revert the changes - amounting to an effective fork of the project. Specifically, the patch merges the timezone history of completely separate countries, effectively wiping places like Norway and Sweden off the map to replace them by Germany. (Many other countries are also proposed to be wiped off the map). The reversion MUST occur as soon as possible, and MUST be before the next tzdb release. The tzdb coordinator is expected to operate by this charter: https://datatracker.ietf.org/doc/html/rfc6557 """ The TZ Coordinator is empowered to decide, as the designated expert, appropriate changes, but SHOULD take into account views expressed on the mailing list. ... The criteria for updates to the database include the following: 1. New TZ names (e.g., locations) are only to be created when the scope of the region a name was envisioned to cover is no longer accurate. 2. In order to correct historical inaccuracies, a new TZ name MAY be added when it is necessary to indicate what was the consensus view at a given time and location. Such TZ names are usually not added when the inaccuracy was prior to 1970. 3. Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry. To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was. """ I contend that to date, the TZ coordinator has not actively shown any serious willingness to accept that the proposed changes are unacceptable to a significant segment of tzdb users. As such, the coordinator has not taken into account the views of the mailing list. I also contend that the "cleanup" being proposed is not within the charter of the project. Point 1 refers to new zones, thus is not applicable. Point 2 refers to correcting historical inaccuracies, yet it is clear that the proposed change *adds* historical inaccuracies. Point 3 refers to changes, but only in terms that reflect what people in the relevant location would have considered the time zone to have been, yet clearly the proposed change does not do that. No part of the charter permits the coordinator to willfully harm the database, nor to merge timezone regions, nor to increase the number of historical inaccuracies. Justifications for the proposed change based on "consistency" or "politics" are not rooted in the charter of tzdb and should be considered null and void. Given the above, I contend that the actions of the tzdb coordinator are in breach of the charter of the project, I therefore request that the changes are reverted immediately. Stephen Colebourne

13 17

New JavaScript/Node.js timezone compiler
by Kerry Shetline June 4, 2021

June 4, 2021

https://github.com/kshetline/tubular_time_tzdb I spoke about this new tz compiler a while back, when I released my @tubular/time date-time library, but the compiler was only at the level of a tool for personal use, without decent documentation or all of the features I’d want for a general-purpose utility. At first this compiler only produced data for use with @tubular/time, but now it can output zoneinfo/zic binaries too. One nice feature is that this tool, by default, reaches right out to https://www.iana.org/time-zones/ for data, with no need to download a release before using the compiler. There’s a JavaScript/TypeScript API and a CLI command. I’ll show the CLI command help, just so people can get an idea of the options available. Anyone can go to https://github.com/kshetline/tubular_time_tzdb for more info. npm install -g @tubular/time-tzdb Usage: tzc [options] [output_file_name_or_directory] Downloads and compiles IANA timezone data, converting to text, zoneinfo binary files, or @tubular/time-compatible data. Options: -v, --version output the version number -5, --systemv Include the SystemV timezones from the systemv file by uncommenting the commented-out zone descriptions. -b, --binary Output binary files to a directory, one file per timezone -B, --bloat Equivalent to the zic "--bloat fat" option. -f Filter out Etc/GMTxxx and other timezones that are either redundant or covered by options for creating fixed-offset timezones. -i Include leap seconds in binary files. -j, --javascript Output JavaScript instead of JSON. --large Apply presets for "large" timezone definitions. --large-alt Apply presets for "large-alt" timezone definitions. --list List available tz database versions. -m Round all UTC offsets to whole minutes. -n, --no-backward Skip the additional aliases in the backward file. -o Overwrite existing file/directory. -q Display no progress messages, fewer warning messages. -R, --rearguard Rearguard mode (skip vanguard features like negative DST). -r Remove 'calendar rollbacks' from time zone transitions -- that is modify time zone data to prevent situations where the calendar date goes backwards as well as the hour and/or minute of the day. -p, --packrat Add additional timezones from the backzone file. -s <zone-id> ID/name for a single timezone/region to be rendered. --small Apply presets for "small" timezone definitions. -t, --typescript Output TypeScript instead of JSON. --text Output (somewhat) human-readable text -u, --url <url> URL or version number, such as '2018c', to parse and compile. Default: https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz -V, --vanguard Vanguard mode (use vanguard features like negative DST). -y <year-span> <min_year,max_year> Year range for explicit time zone transitions. Default: 1850,2050 -z <zone-info-dir> Validate this tool's output against output from the standard zic tool stored in the given directory. (Validation is done before applying the -r option.) -h, --help display help for command -, Use dash by itself to output to stdout.

2 1

Demetrios Matsakis of USNO on NPR
by Steve Allen June 2, 2021

June 2, 2021

Today NPR has a 2 minute musical interview about daylight time with Demetrios Matsakis of USNO https://www.npr.org/2021/06/02/1002368937/an-expert-has-the-answers-to-dayl… -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

2 1

Re: [tz] [PROPOSED] Merge timezones that are alike since 1970
by Stephen Trainor June 2, 2021

June 2, 2021

> To me, the two tables provide very different needs to two very different sets of users. Let the O/S teams use table 1, let the history-related app developers use a constantly improving backtable. As a history-related app developer (astronomy), I can only speak authoritatively for my own code, but I suspect the same applies to the vast majority of similar apps out there: I’ve never consumed tzdb data directly, but rely instead on OS implementations for historical data in native applications (and NPM libraries for web applications). I’m doubtful this distinction between sets of users is actually valid in practical terms, even though consumption of historical data is likely a drop in the overall ocean. Even if developers could consume backzone information directly, will they? Reimplementing tz-related logic in order to do so would be a big task from my perspective. Stephen Sent from my iPhone

1 0

research on TZ list
by BASTIAN Michelle June 1, 2021

June 1, 2021

Hi all, I'm a researcher at the University of Edinburgh, currently working on a book about redesigning clocks. My background is in philosophy, though quite interdisciplinary. I'm interested in the disparity between those responsible for the technical aspects of time keeping, who generally understand clock time to be malleable and adjustable, and wider perceptions in the arts and humanities that clocks are objective. The TZ list is a great case study to show this malleability, so I'm hoping to draw on the archives to develop a chapter for the book, where I'll also be talking about leap smearing. I've been in touch with the owners and the list is regarded as being in the public domain and transparent ie ICANN and its subsidiaries are allowed to "Maintain archival records of a User's participation for historical and research purposes, subject to retention limits imposed by applicable laws" and "To publish a User's comments or feedback along with a User's name for the benefit of others and otherwise to comply with our accountability and transparency principles". However, in terms of transparency from my side I wanted to let you all know about this project and that once the section is drafted, I will contact those that I reference to ensure that you are okay for quotes to be used in the way I have. No need to respond to me if you are okay with it, but I did want to offer the opportunity to correct me, to remove the quote, or to be anonymised as preferred. I could then share the paper with the group if that was of interest. I'm very happy to answer any questions, do contact me directly if you'd like to, and thanks for all the great work you are doing. Finally, if anyone is interested in the project more widely, I wrote a short paper that was published as part of the Science of Time conference at Harvard in 2016 which can be accessed here https://link.springer.com/chapter/10.1007%2F978-3-319-59909-0_41 Best wishes, Michelle. --- Dr Michelle Bastian Senior Lecturer in Environmental Humanities ESALA, Edinburgh College of Art, University of Edinburgh Level 1, Room 303B, The Maltings | Minto House, 20-22 Chambers Street, Edinburgh, EH1 1JZ | 0131 651 5779 Work hours: I normally work 7am-3pm M-F. Latest publications: Whale falls, suspended ground, and extinctions never known<https://read.dukeupress.edu/environmental-humanities/article/12/2/454/16699…> (Environmental Humanities, 2020) Open access Retelling Time in Grassroots Sustainable Economy Movements<https://doi-org.ezproxy.is.ed.ac.uk/10.1080/2373566X.2019.1583589> (Geohumanities, 2019) Open access Time & Society<https://journals.sagepub.com/home/tas> | Edinburgh Environmental Humanities Network<http://www.environmentalhumanities.ed.ac.uk/> | Temporal Belongings<http://www.temporalbelongings.org/> | Extinction Studies<http://extinctionstudies.org/> | ESALA Declares<http://extinctionstudies.org/> | The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.

1 0

[PROPOSED] * northamerica: Comment on Attu+Kiska 1942/3.
by Paul Eggert May 28, 2021

May 28, 2021

--- northamerica | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/northamerica b/northamerica index 7edd8ef..a2f2b43 100644 --- a/northamerica +++ b/northamerica @@ -729,7 +729,11 @@ Zone America/Adak 12:13:22 - LMT 1867 Oct 19 12:44:35 -11:00 US B%sT 1983 Oct 30 2:00 -10:00 US AH%sT 1983 Nov 30 -10:00 US H%sT -# The following switches don't quite make our 1970 cutoff. +# The following switches don't make our 1970 cutoff. +# +# Kiska observed Tokyo date and time during Japanese occupation from +# 1942-06-06 to 1943-07-29, and similarly for Attu from 1942-06-07 to +# 1943-05-29 (all dates American). Both islands are now uninhabited. # # Shanks writes that part of southwest Alaska (e.g. Aniak) # switched from -11:00 to -10:00 on 1968-09-22 at 02:00, -- 2.27.0

1 0

[PROPOSED] Replace Pacific/Enderbury with Pacific/Kanton
by Paul Eggert May 28, 2021

May 28, 2021

When I added Pacific/Enderbury in 1993, I thought it was the most-populous location in its timezone. I was wrong - it has been uninhabited since 1942. I discovered my mistake this week when doing the recent timezone-coalescing changes. It shouldn’t be surprising that this problem has not been reported, as only two dozen people live in the timezone, they’re rotated in and out, and they likely don’t have a good Internet connection. Leaving the name alone wouldn’t work because Pacific/Enderbury should be at -00 now, our convention for uninhabited locations. So, replace the name with Pacific/Kanton. By strange coincidence, Kanton has been in the news recently, for reasons similar to why Enderbury was in the news in the 1930s; see: https://www.thedrive.com/the-war-zone/40471/china-wants-to-revive-a-strateg… * NEWS: Mention this. * australasia, zone.tab, zone1970.tab (Pacific/Kanton): New zone, replacing ... * backward (Pacific/Enderbury): New backward-compatibility link * backzone: Copy of old data, with fixes for uninhabited times, which includes the current time. --- NEWS | 13 +++++++++++-- australasia | 19 ++++++++++++++++++- backward | 1 + backzone | 12 ++++++++++++ zone.tab | 2 +- zone1970.tab | 2 +- 6 files changed, 44 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 04c45e9..53890a7 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,13 @@ News for the tz database Unreleased, experimental changes + Changes to zone name + + Rename Pacific/Enderbury to Pacific/Kanton. When we added + Enderbury in 1993, we did not know that it is uninhabited and that + Kanton (population two dozen) is the only inhabited location in + that timezone. The old name is now a backward-compatility link. + Changes to past timestamps Correct many pre-1993 transitions, fixing entries originally @@ -14,11 +21,13 @@ Unreleased, experimental changes - Guyana: corrected LMT for Georgetown; the introduction of standard time in 1911, not 1915; and corrections to 1975 and 1992 transitions + - Kanton: uninhabited before 1937-08-31 - Niue: observed -11:20 in 1951-1978 - Portugal: DST was observed in 1950 - Tonga: adopted standard time in 1945 not 1901, and moved from +12:20 to +13 in 1961 not 1941 Additional fixes to entries in the 'backzone' file include: + - Enderbury: inhabited only 1860/1885 and 1938-03-06/1942-02-09 - The Gambia: 1933 and 1942 transitions - Malawi: several 1911 through 1925 transitions - Sierra Leone: several 1913 through 1941 transitions, and DST @@ -955,8 +964,8 @@ Release 2018d - 2018-03-22 07:05:46 -0700 Institute in Montevideo. (Thanks to Jeremie Bonjour, Tim Parenti, and Michael Deckers.) - Enderbury and Kiritimati skipped New Year's Eve 1994, not - New Year's Day 1995. (Thanks to Kerry Shetline.) + East Kiribati skipped New Year's Eve 1994, not New Year's Day 1995. + (Thanks to Kerry Shetline.) Fix the 1912-01-01 transition for Portugal and its colonies. This transition was at 00:00 according to the new UT offset, not diff --git a/australasia b/australasia index 8e952ad..5cbc0c8 100644 --- a/australasia +++ b/australasia @@ -457,7 +457,7 @@ Zone Pacific/Guam -14:21:00 - LMT 1844 Dec 31 # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki 12:00 - +12 -Zone Pacific/Enderbury -11:24:20 - LMT 1901 +Zone Pacific/Kanton 0 - -00 1937 Aug 31 -12:00 - -12 1979 Oct -11:00 - -11 1994 Dec 31 13:00 - +13 @@ -1735,6 +1735,23 @@ Zone Pacific/Efate 11:13:16 - LMT 1912 Jan 13 # Vila # One source for this is page 202 of: Bartky IR. One Time Fits All: # The Campaigns for Global Uniformity (2007). +# Kanton + +# From Paul Eggert (2021-05-27): +# Kiribati's +13 timezone is represented by Kanton, its only populated +# island. (It was formerly spelled "Canton", but Gilbertese lacks "C".) +# Kanton was settled on 1937-08-31 by two British radio operators +# <https://history.state.gov/historicaldocuments/frus1937v02/d94>; +# Americans came the next year and built an airfield, partly to +# establish airline service and perhaps partly anticipating the +# next war. Aside from the war, the airfield was used by commercial +# airlines until long-range jets became standard; although currently +# for emergency use only, China says it is considering rebuilding the +# airfield for high-end niche tourism. Kanton has about two dozen +# people, caretakers who rotate in from the rest of Kiribati in 2-5 +# year shifts, and who use some of the leftover structures +# <http://pipa.neaq.org/2012/06/images-of-kanton-island.html>. + # Kwajalein # From an AP article (1993-08-22): diff --git a/backward b/backward index 9e22754..0fec5e4 100644 --- a/backward +++ b/backward @@ -208,6 +208,7 @@ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC Link Pacific/Port_Moresby Pacific/Chuuk +Link Pacific/Kanton Pacific/Enderbury Link Pacific/Tarawa Pacific/Funafuti Link Pacific/Honolulu Pacific/Johnston Link Pacific/Tarawa Pacific/Majuro diff --git a/backzone b/backzone index f5b20fa..4d69a3f 100644 --- a/backzone +++ b/backzone @@ -1566,6 +1566,18 @@ Zone Pacific/Chuuk -13:52:52 - LMT 1844 Dec 31 Link Pacific/Chuuk Pacific/Truk Link Pacific/Chuuk Pacific/Yap +# Phoenix Islands, Kiribati +# From Paul Eggert (2021-05-27): +# Enderbury was inhabited 1860/1880s to mine guano, and 1938-03-06/1942-02-09 +# for aviation (ostensibly commercial, but military uses foreseen). +# The 19th-century dates are approximate. See Pacific/Kanton for +# the currently-inhabited representative for this timezone. +Zone Pacific/Enderbury 0 - -00 1860 + -11:24:20 - LMT 1885 + 0 - -00 1938 Mar 6 + -12:00 - -12 1942 Feb 9 + 0 - -00 + # Tuvalu Zone Pacific/Funafuti 11:56:52 - LMT 1901 12:00 - +12 diff --git a/zone.tab b/zone.tab index cbf4b91..e2062cf 100644 --- a/zone.tab +++ b/zone.tab @@ -232,7 +232,7 @@ KE -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek KH +1133+10455 Asia/Bangkok KI +0125+17300 Pacific/Tarawa Gilbert Islands -KI -0308-17105 Pacific/Enderbury Phoenix Islands +KI -0247-17143 Pacific/Kanton Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands KM -1141+04316 Africa/Nairobi KN +1718-06243 America/Puerto_Rico diff --git a/zone1970.tab b/zone1970.tab index a02d94d..6b9d288 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -188,7 +188,7 @@ JP +353916+1394441 Asia/Tokyo KE,DJ,ER,ET,KM,MG,SO,TZ,UG,YT -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek KI,MH,TV,UM,WF +0125+17300 Pacific/Tarawa Gilberts, Marshalls, Tuvalu, Wallis & Futuna, Wake -KI -0308-17105 Pacific/Enderbury Phoenix Islands +KI -0247-17143 Pacific/Kanton Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands KP +3901+12545 Asia/Pyongyang KR +3733+12658 Asia/Seoul -- 2.27.0

1 0

So, about those LMT offsets
by Tom Lane May 24, 2021

May 24, 2021

As long as we're considering decreasing the historical fidelity of assorted pre-1970 timestamps, I'd like to make a modest suggestion: forget all the "LMT" offsets for years before standardized timezones prevailed, and just assume that the oldest documented standard-time offset in each zone goes back indefinitely far. The reason I suggest this is that we regularly get questions on the Postgres lists from novices who are confused by this behavior (pardon the SQL-isms): postgres=# set timezone = 'UTC'; SET postgres=# select timestamptz '1884-01-01 12:00 America/New_York'; timestamptz ------------------------ 1884-01-01 17:00:00+00 (1 row) This is, of course, saying that noon in New York translates to 1700 UT ... postgres=# select timestamptz '1883-01-01 12:00 America/New_York'; timestamptz ------------------------ 1883-01-01 16:56:02+00 (1 row) ... uh, what? The novices are definitely not expecting that, and they don't find it helpful. We have to explain it away as "that's what tzdb says", but it's still unhelpful. It's even sillier when you consider postgres=# select timestamptz '1752-09-10 12:00 America/New_York'; timestamptz ------------------------ 1752-09-10 16:56:02+00 (1 row) as calendar experts will recall that no such date was recognized in the British colonies. So although it's debatable whether we even know what day it is, for sure we know the UTC offset to the second. So basically, if we're willing to use proleptic Gregorian calendar for years before anyone was actually using that calendar, it's not very clear why we shouldn't use proleptic standard time too. I'd be willing to consider implementing that behavior in Postgres if I could tell (a) that a given offset is LMT not standardized time and (b) what the zone's oldest standardized offset is. But AFAICT that's not possible without mucking with the behavior of localtime.c, which I'd much prefer not to. So ... how about just dropping this oddity from the source data? regards, tom lane

9 17

Re: [tz] Vanguard vs. "main" vs. rearguard
by Paul Eggert May 20, 2021

May 20, 2021

On 5/19/21 4:35 PM, Kerry Shetline wrote: > Can you show me an example of what the format of a three-mode set of data would look like? I doubt it. I don't think we've ever done it. If we were to do it (I hope not), we'd probably have to change ziguard.awk to implement it. There may be an expectation here that the vanguard/main/rearguard formats are well-specified. They're not. They're purely a hack, they're implemented only by ziguard.awk, we don't even need vanguard any more, and I hope the need for rearguard goes away as well. Perhaps in the future we'll need to do this sort of delayed-implementation again; when that happens we may do it in an entirely different way.

1 0

Re: [tz] Vanguard vs. "main" vs. rearguard
by Kerry Shetline May 19, 2021

May 19, 2021

I think I’ve answered my own question. First of all, I can select between the various versions by reading from one of the vanguard.zi, rearguard.zi, or main.zi files. (I had been reading all of the files like africa, europe, northamerica, etc., separately at first.) Then whatever I want or don’t want to use is already commented out or uncommented as needed. Secondly, even if I’m reading those other files rather than the .zi files, I gather that, in my Europe/Dublin example, the vanguard and main data are the same, but if rearguard and main had been the same, it would be the vanguard section that was commented out, and the rearguard section would have been uncommented. I take it from this that, for any given vanguard/rearguard section, you can’t have all three formats defined differently, but rather “main” will either be identical to one of vanguard or rearguard.

2 1

Vanguard vs. "main" vs. rearguard
by Kerry Shetline May 19, 2021

May 19, 2021

As far as I can tell, their are only four sections in the current tzdb marked as vanguard/rearguard, two sections in the europe for Europe/Dublin and Europe/Prague, and two in the africa file for Africa/Windhoek. What I’m confused about is references I’ve seen to a “main” format, like this: > Changes to future timestamps > > Guess that Morocco will continue to fall back just before and > spring forward just after Ramadan, the practice since 2012. > (Thanks to Maamar Abdelkader.) This means Morocco will observe > negative DST during Ramadan in main and vanguard formats, and in > rearguard format it stays in the +00 timezone and observes > ordinary DST in all months other than Ramadan… At least from the current examples, it looks like one would have to choose either Vanguard or Rearguard, period. There is no middle ground of “main” when I look at a case like this below: # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00s -0:25:21 1:00 IST 1916 Oct 1 2:00s 0:00 GB-Eire %s 1921 Dec 6 # independence 0:00 GB-Eire GMT/IST 1940 Feb 25 2:00s 0:00 1:00 IST 1946 Oct 6 2:00s 0:00 - GMT 1947 Mar 16 2:00s 0:00 1:00 IST 1947 Nov 2 2:00s 0:00 - GMT 1948 Apr 18 2:00s 0:00 GB-Eire GMT/IST 1968 Oct 27 # Vanguard section, for zic and other parsers that support negative DST. 1:00 Eire IST/GMT # Rearguard section, for parsers lacking negative DST; see ziguard.awk. # 1:00 - IST 1971 Oct 31 2:00u # 0:00 GB-Eire GMT/IST 1996 # 0:00 EU GMT/IST # End of rearguard section. If there is a middle ground here, neither Vanguard or Rearguard, what is it? And if there are no current examples with such a middle ground, what would a middle ground of neither Vanguard or Rearguard look like?

1 0

DKIM misconfiguration of this mailing list
by Yves Goergen May 18, 2021

May 18, 2021

Hello, I'm having trouble receiving messages from this mailing list because many of them have a broken DKIM signature. I guess that's because the mailing list is not configured properly to survive in today's e-mail world. If a message with a DKIM signature is sent to this list (like mine), they're forwarded to all subscribers without correcting that signature but at the same time modifying subject, body or sender. Maybe somebody would like to take a look at that to ensure that messages from this list can still be delivered. This is an article I found about the topic, it might be helpful in fixing the problems. https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html I'm writing to the list directly because list owners never seem to respond to such issues. Several other mailing lists I'm subscribed to have the same issue. If you'd like me to read your reply, please CC me as well to make sure your message arrives here. -Yves

2 1

Time Zone and Daylight Saving Time Customer Service Stories
by Brian Inglis May 13, 2021

May 13, 2021

Just came across a source of articles about Time Zones and Daylight Saving Time from the perspective of Customer Service, or other staff dealing with them, across the globe, at NotAlwaysRight.com. The tone reminds me of articles in The Register. My attention was first drawn by a series of articles entitled "No Fortitude for Longitude" and I have attached some links to that series and to results from search queries on the topics. -- 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 binary units and prefixes, physical quantities in SI.]

1 0

Re: [tz] IANA .tar.gz files with incorrect checksums
by Paul Eggert May 13, 2021

May 13, 2021

On 5/12/21 4:30 PM, Peter Adelman wrote: > I am contacting you to let you know that some of the old releases of the > IANA time zones databases are missing (or perhaps have incorrect) > checksums in their .tars. The Julia language uses the IANA Time Zone > Databases for its TimeZones.jl package, and in the language's most > recent minor release (1.6) they started failing extractions where the > header checksum didn't match the standard. > > Here are two related tickets: > * https://github.com/JuliaTime/TimeZones.jl/issues/325 > <https://github.com/JuliaTime/TimeZones.jl/issues/325> > * https://github.com/JuliaIO/Tar.jl/issues/111 > <https://github.com/JuliaIO/Tar.jl/issues/111> > > Of the tzdata___.tar.gzs that I have looked at (I think that I explored > all of them while trying to build my Julia package), these have > problematic tar checksums: > 93g > 94a/b/d/e/f/h > 95b/c/d/e/f/g/h/i/k/l/m > 96a/b/c/d/e/h/i > 1996n > 1997b/c > 1999f > > I checked two of them by hand (1997b and one other that I didn't note) > and both had blank header checksum bytes (0). ( > https://www.gnu.org/software/tar/manual/html_node/Standard.html > <https://www.gnu.org/software/tar/manual/html_node/Standard.html> ) > > Anyway, the glory of standards releases is that they don't change so > obviously I understand not changing it, but I thought I'd reach out with > the information anyway. Those old tarballs were built by old SunOS tar, which computed some checksums incompatibly with POSIX <https://www.gnu.org/software/tar/manual/html_node/Checksumming.html> and which put leading spaces into numeric fields, contra POSIX. GNU Tar is generous and accepts these old tarballs, but perhaps TimeZones.jl has never had to deal with old SunOS tar, or maybe Julia's tarball-extracting library has a "let's be generous in what we accept" option that TimeZones.jl could enable. I installed the attached to tz-link to document some of this. This patch assumes that 1999g and later are OK (I haven't checked this).

2 1

About missing country in your Time Zone Database?
by Sadiku, Besnik May 11, 2021

May 11, 2021

Hello there IANA personnel, I am currently taking a Python class and learning about using Time Zone and noticed that Kosovo is missing in the Time Zone Database list. Please, I would to request to add in your Time Zone Database the country KOSOVO and its capital PRISHTINA? Thank you and I appreciated. Sincerely, ******************************************* * Besnik Sadiku, BS in M.C.S. and Web Dev. & Admin. * Business Analyst 2 / Certified * Office: (608) 741-5629 * Cell: (262) 473-9511 * e-mail: bsadiku(a)mhemail.org<mailto:bsadiku@mhemail.org> ******************************************* [cid:image001.png@01D201CE.DEAEBCD0]

4 6

(no subject)
by Cool Gab19 May 11, 2021

May 11, 2021

can you add UTC+15:00 "Future Standard Time" time zone it was 1 hour ahead from all 24 hour world time zone and it doesn't have any current region or countries same to Universal Time which can be used anywhere and i do really know that we need calculations for these but please put this thing on your database so i can able to see this on my devices settings.

2 1

[PATCH] Definite article for Bahamas, Gambia
by Paul Eggert May 10, 2021

May 10, 2021

* NEWS, backzone, iso3166.tab, northamerica: Put "The" in front of "Bahamas" and "Gambia"; this is a common style and is preferred by the respective governments. --- NEWS | 4 ++-- backzone | 2 +- iso3166.tab | 4 ++-- northamerica | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 67fb000..6d1cd09 100644 --- a/NEWS +++ b/NEWS @@ -19,7 +19,7 @@ Unreleased, experimental changes - Tonga: adopted standard time in 1945 not 1901, and moved from +12:20 to +13 in 1961 not 1941 Additional fixes to entries in the 'backzone' file include: - - Gambia: 1933 and 1942 transitions + - The Gambia: 1933 and 1942 transitions - Malawi: several 1911 through 1925 transitions - Sierra Leone: several 1913 through 1941 transitions, and DST was NOT observed in 1957 through 1962 @@ -148,7 +148,7 @@ Release 2020e - 2020-12-22 15:14:34 -0800 Correct many pre-1986 transitions, fixing entries originally derived from Shanks. The fixes include: - Australia: several 1917 through 1971 transitions - - Bahamas: several 1941 through 1945 transitions + - The Bahamas: several 1941 through 1945 transitions - Bermuda: several 1917 through 1956 transitions - Belize: several 1942 through 1968 transitions - Ghana: several 1915 through 1956 transitions diff --git a/backzone b/backzone index 9ebf9d2..8e4f97a 100644 --- a/backzone +++ b/backzone @@ -101,7 +101,7 @@ Zone Africa/Bamako -0:32:00 - LMT 1912 Zone Africa/Bangui 1:14:20 - LMT 1912 1:00 - WAT -# Gambia +# The Gambia # From P Chan (2020-12-09): # Standard time of GMT-1 was adopted on 1933-04-01. On 1942-02-01, GMT was # adopted as a war time measure. This was made permanent in 1946. diff --git a/iso3166.tab b/iso3166.tab index a4ff61a..e7ab54d 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -54,7 +54,7 @@ BN Brunei BO Bolivia BQ Caribbean NL BR Brazil -BS Bahamas +BS The Bahamas BT Bhutan BV Bouvet Island BW Botswana @@ -107,7 +107,7 @@ GG Guernsey GH Ghana GI Gibraltar GL Greenland -GM Gambia +GM The Gambia GN Guinea GP Guadeloupe GQ Equatorial Guinea diff --git a/northamerica b/northamerica index c7d9274..b27311a 100644 --- a/northamerica +++ b/northamerica @@ -2931,7 +2931,7 @@ Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 0:11:56 # Antigua and Barbuda # See America/Port_of_Spain. -# Bahamas +# The Bahamas # # For 1899 Milne gives -5:09:29.5; round that. # -- 2.27.0

2 1

[PROPOSED 1/2] Omit duplicate Link lines in ziguard output
by Paul Eggert May 10, 2021

May 10, 2021

* ziguard.awk: Later Link lines now comment out earlier ones. Formerly, we relied on ‘zic’ to ignore the earlier lines, but this made for more-confusing ziguard output. This change does not affect zic’s output. --- ziguard.awk | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/ziguard.awk b/ziguard.awk index 7d6f7c9..6888c27 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -114,15 +114,16 @@ DATAFORM != "main" { } } -# If a Link line is followed by a Zone line for the same data, comment +# If a Link line is followed by a Link or Zone line for the same data, comment # out the Link line. This can happen if backzone overrides a Link -# with a Zone. -/^Link/ { - linkline[$3] = NR -} +# with a Zone or a different Link. /^Zone/ { sub(/^Link/, "#Link", line[linkline[$2]]) } +/^Link/ { + sub(/^Link/, "#Link", line[linkline[$3]]) + linkline[$3] = NR +} { line[NR] = $0 } -- 2.27.0

1 1

JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Kerry Shetline April 29, 2021

April 29, 2021

About two months ago I released the first major version of @tubular/time, a JavaScript/TypeScript npm package for date/time handling, with solid support for IANA timezones, including dealing with weird edge cases like 47-hour days and negative DST and such. I’ve just finished up adding a feature I’ve always wanted to have in a date/time package, and that’s the ability to properly handle and represent leap seconds. Along with that comes conversion to and from TAI (International Atomic Time) and astronomical time systems. https://www.npmjs.com/package/@tubular/time One interesting issue was how to handle a broad range of years (thousands of years forward and backward in time) in a way that was nicely integrated with Universal Coordinated Time. The idea for UTC got something of a wobbly start around 1960, and wasn’t implemented in its current form until 1972. Going forward in time, UTC is only strictly defined for up to six months beyond the next announced leap second, or next announced lack of any leap second on the way. I settled on the following scheme for resolving these issues, and I’m curious what others might think about it: * For all dates prior to 1957, estimated UT1 is in effect. This is most accurate back to 1600, for which there is sufficient astronomical data for reasonable approximate conversions from UT1 to TAI and dynamical time. Further back in time less accurate approximations are in effect. * From 1957-1958, using a sliding weighted average, UT1 transitions to proleptic UTC. * From 1958-1972 proleptic UTC, as proposed by Tony Finch (https://fanf.livejournal.com/69586.html) is used, with the first non-official leap second occurring at 1959-06-30 23:59:60. * From 1972 up until the latest updates provided by the International Bureau of Weights and Measures, well-defined UTC prevails, with the first official leap second occurring at 1972-06-30 23:59:60. * For a year to 18 months after the current time, or after the last defined leap second (whichever is later), a presumed leap-second-free span of UTC is projected to occur. * A sliding weighted average transition from UTC to estimated UT1 follows for the next 365 days. * Formulaic predicted UT1 is used for all later dates and times thereafter. Another project I’ve been working on (which isn’t quite ready for prime time because it’s utterly without documentation) is a new JavaScript timezone compiler. This has replaced an old Java project I used for generating the timezone data used by @tubular/time: https://github.com/kshetline/tubular_time_tzdb

7 16

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Kerry Shetline April 27, 2021

April 27, 2021

On Mon, 26 Apr 2021 16:03:59 -0400, John_Sauter via tz wrote: > Based on the way the Earth has been rotating recently, the next leap > second will be around the end of this decade, and it will be a negative > leap second. What kind of hopeless nerd does it make me that I find this an exciting prospect? I’ve taken negative leap seconds to be a nearly completely hypothetical idea, even though I have nevertheless coded diligently to account for the possibility.

2 1

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Kerry Shetline April 27, 2021

April 27, 2021

On Mon, 26 Apr 2021 15:06:12 -0600, Paul Gilmartin <PaulGBoulder(a)aim.com> wrote: >> POSIX time is really just UTC without the leap seconds, isn?t it? >> > More precisely, POSIX time counts non-leap seconds since 1972-01-01t00:00:00 UTC. That would be 1970-01-01T00:00:00 UTC. 1972 is, however, the year that the first official leap second (for POSIX not to count) occurred.

1 1

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Steve Allen April 26, 2021

April 26, 2021

On Mon 2021-04-26T17:17:13+0100 Tony Finch via tz hath writ: > My aim back then was to sketch what might be a reasonable way to bridge > between pre-atomic time and UTC, for code that can only support an integer > offset between UTC and TAI. If your code supports rubber seconds then it > should probably use the USNO table that records the rate and phase offsets > between 1962 and 1972. (I don't know another source of that table, nor > where you can get a copy while maia.usno.navy.mil is down.) Keep in mind that the USNO numbers only apply to time signals broadcast in the US, and before 1968 they ignore the many microseconds of offset between NBS and USNO. Germany did not start to broadcast the old UTC until the late 1960s, until 1974-01-01 broadcast both old UTC and SAT, and stopped providing old UTC as of 1970-04-01 because it had been deemed illegal. Soviet and Chinese time signals never used the old UTC. Sussing out the particulars for individual cases of national time signals needs finding remnants of the high-acid paper that each national time service used for bulletins issued to its users, and/or diving through the BIH Bulletin Horaire and Circular D to pull out the received timing of each official broadcast. It is much simpler to ignore the 50 to 200 ms jumps that were put into old UTC and say that before 1972 all available sources of civil time provided UT (nevermind the particular flavor, nobody set their clock that accurately) and after 1972 UTC with leap seconds. For civil time I do not see any advantage in a model with greater complexity than just plain UT as the basis time scale before 1972-01-01. This is adequate for any IANA tz library. For precise time no general model applies. Each precise timestamp must be meticulously referenced to the particulars of the clocks that were used to obtain it. No available clocks were using TAI before 1972-01-01, and this does not belong in any IANA tz library. Constructing a model that supposes it is possible to do better is akin to writing The Silmarillion. Look at the BIH plots of the accuracy of clocks https://www.ucolick.org/~sla/leapsecs/BHsHn05p142.html millisecond agreement between different national authorities was not achieved until 1960 during the UK/US experiment that became old UTC. > * TAI is a retrospective timescale; it isn't defined in the future. TAI also cannot be defined prior to mid 1955, and it was not generally availble for use by any system until 1972-01-01 when broadcast time signals began to be based on TAI. The BIPM will never tolerate TAI becoming part of an international agreement. The best that can be hoped for in a new international agreement on time is one (or more) new TAI-like uniform scale which will be offset by some integer number of seconds from TAI. The reason we use UTC is because it is what is in the current international agreement. Everybody involved in the technical aspects eschewed the use of UTC for their systems from before 1972-01-01. Look at the ATSC agreement for a technically-competent time scale. They chose GPS time because it is practically available. ATSC was not bound by international bureaucratic requirements, so they could make that choice. Because it is ultimately controlled by USNO GPS system time will never become part of an international agreement. On Mon 2021-04-26T12:42:19-0400 John Sauter via tz hath writ: > In looking at historical estimates of the rotation of the Earth based > on astronomical observations of occulations and eclipses, I found that > the values of UT1 are reliabe only since 1825. (Nevertheless, my table > of proleptic leap seconds goes back to the year -2000.) Morrison, L. V.; Stephenson, F. R.; Hohenkerk, C. Y.; Zawilski, M. DOI: 10.1098/rspa.2020.0776 Bibliographic Code: 2021RSPSA.47700776M Proceedings of the Royal Society A, Volume 477, Issue 2246, id.20200776 all tabulated at http://astro.ukho.gov.uk/nao/lvm/ That is the place to look, and it will continue to be so for the lifetime of the authors. But what is it mean to ask reliable? That is very much the question given that prior to "reliable" everybody's clock was set to local apparent time. What exactly is the question that is trying to be answered by an algorithm like this? Ultimately it is necessary to model two kinds of time: 1) earth rotation time (which before the 20th century differed by a second or more depending on who was setting the clock) because that is a subdivision of internationally agreed calendar days 2) uniform time (which becomes possible to interpret as atomic time beginning in 1955). -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

3 3

[PROPOSED] Do not assume bytes have 8 bits
by Paul Eggert April 26, 2021

April 26, 2021

* zic.c (convert, convert64): Mask bytes with 0xff before storing them, for portability to machines where bytes have more than 8 bits. Although this is surely only of theoretical interest, we might as well be portable. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 88b1531..77a5698 100644 --- a/zic.c +++ b/zic.c @@ -1927,7 +1927,7 @@ convert(uint_fast32_t val, char *buf) unsigned char *const b = (unsigned char *) buf; for (i = 0, shift = 24; i < 4; ++i, shift -= 8) - b[i] = val >> shift; + b[i] = (val >> shift) & 0xff; } static void @@ -1938,7 +1938,7 @@ convert64(uint_fast64_t val, char *buf) unsigned char *const b = (unsigned char *) buf; for (i = 0, shift = 56; i < 8; ++i, shift -= 8) - b[i] = val >> shift; + b[i] = (val >> shift) & 0xff; } static void -- 2.27.0

4 5

[PATCH] Fix potential integer overflow in differ_by_repeat
by Paul Eggert April 26, 2021

April 26, 2021

* localtime.c (differ_by_repeat): Remove, since the subtraction t1 - t0 could in theory overflow in 64-bit TZif data. (tzloadbody): Redo to avoid integer overflow. * private.h (SECSPERREPEAT_BITS): Remove; no longer used. --- localtime.c | 30 ++++++++++++++---------------- private.h | 3 +-- 2 files changed, 15 insertions(+), 18 deletions(-) diff --git a/localtime.c b/localtime.c index 9dd496d..9840b89 100644 --- a/localtime.c +++ b/localtime.c @@ -334,14 +334,6 @@ scrub_abbrs(struct state *sp) } } -static bool -differ_by_repeat(const time_t t1, const time_t t0) -{ - if (TYPE_BIT(time_t) - TYPE_SIGNED(time_t) < SECSPERREPEAT_BITS) - return 0; - return t1 - t0 == SECSPERREPEAT; -} - /* Input buffer for data read from a compiled tz file. */ union input_buffer { /* The first part of the buffer, interpreted as a header. */ @@ -660,20 +652,26 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (sp->typecnt == 0) return EINVAL; if (sp->timecnt > 1) { + if (sp->ats[0] <= TIME_T_MAX - SECSPERREPEAT) { + time_t repeatat = sp->ats[0] + SECSPERREPEAT; + int repeattype = sp->types[0]; for (i = 1; i < sp->timecnt; ++i) - if (typesequiv(sp, sp->types[i], sp->types[0]) && - differ_by_repeat(sp->ats[i], sp->ats[0])) { + if (sp->ats[i] == repeatat + && typesequiv(sp, sp->types[i], repeattype)) { sp->goback = true; break; - } + } + } + if (TIME_T_MIN + SECSPERREPEAT <= sp->ats[sp->timecnt - 1]) { + time_t repeatat = sp->ats[sp->timecnt - 1] - SECSPERREPEAT; + int repeattype = sp->types[sp->timecnt - 1]; for (i = sp->timecnt - 2; i >= 0; --i) - if (typesequiv(sp, sp->types[sp->timecnt - 1], - sp->types[i]) && - differ_by_repeat(sp->ats[sp->timecnt - 1], - sp->ats[i])) { + if (sp->ats[i] == repeatat + && typesequiv(sp, sp->types[i], repeattype)) { sp->goahead = true; break; - } + } + } } /* Infer sp->defaulttype from the data. Although this default diff --git a/private.h b/private.h index cee3b11..340a354 100644 --- a/private.h +++ b/private.h @@ -642,7 +642,7 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; #define TIME_T_MAX_NO_PADDING MAXVAL(time_t, TYPE_BIT(time_t)) /* The extreme time values. These are macros, not constants, so that - any portability problem occur only when compiling .c files that use + any portability problems occur only when compiling .c files that use the macros, which is safer for applications that need only zdump and zic. This implementation assumes no padding if time_t is signed and either the compiler lacks support for _Generic or time_t is not one @@ -727,7 +727,6 @@ char *ctime_r(time_t const *, char *); #define YEARSPERREPEAT 400 /* years before a Gregorian repeat */ #define DAYSPERREPEAT ((int_fast32_t) 400 * 365 + 100 - 4 + 1) #define SECSPERREPEAT ((int_fast64_t) DAYSPERREPEAT * SECSPERDAY) -#define SECSPERREPEAT_BITS 34 /* ceil(log2(SECSPERREPEAT)) */ #define AVGSECSPERYEAR (SECSPERREPEAT / YEARSPERREPEAT) #define TM_SUNDAY 0 -- 2.27.0

1 0

[PROPOSED 1/2] Do not assume unsigned->signed conversion style
by Paul Eggert April 23, 2021

April 23, 2021

* localtime.c (detzcode64): Use int_fast64_t, not uint_fast64_t, for local variable, to avoid an implementation-defined conversion when the variable’s value is returned. --- localtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 6c88b6e..9dd496d 100644 --- a/localtime.c +++ b/localtime.c @@ -237,7 +237,7 @@ detzcode(const char *const codep) static int_fast64_t detzcode64(const char *const codep) { - register uint_fast64_t result; + register int_fast64_t result; register int i; int_fast64_t one = 1; int_fast64_t halfmaxval = one << (64 - 2); -- 2.27.0

1 1

[PROPOSED 1/2] * SECURITY: New file.
by Paul Eggert April 20, 2021

April 20, 2021

--- SECURITY | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 SECURITY diff --git a/SECURITY b/SECURITY new file mode 100644 index 0000000..40128bc --- /dev/null +++ b/SECURITY @@ -0,0 +1,15 @@ +Please report any sensitive security-related bugs via email to the +tzdb designated coordinators, currently Paul Eggert +<eggert(a)cs.ucla.edu> and Tim Parenti <tim(a)timtimeonline.com>. +Put "tzdb security" at the start of your email's subject line. +We prefer communications to be in English. + +You should receive a response within a week. If not, please follow up +via email to make sure we received your original message. + +If we confirm the bug, we plan to notify affected third-party services +or software that we know about, prepare an advisory, commit fixes to +the main development branch as quickly as is practical, and finally +publish the advisory on tz(a)iana.org. As with all tzdb contributions, +we give credit to security contributors unless they wish to remain +anonymous. -- 2.27.0

1 1

Wisconsin daylight savings 1957
by TJ April 17, 2021

April 17, 2021

Hey everyone, I was doing some digging and found the following referendum in 1957 for Wisconsin. - https://ballotpedia.org/Wisconsin_Daylight_Saving_Time,_Question_1_(April_1… The text of the measure that passed was: "Shall section 175.095 (2) of the statutes, which proposes a statewide daylight saving time of one hour per day from the last Sunday in April to the last Sunday in September in each year be law beginning with the last Sunday in April 1957?" However, the 1947 ballot to use daylight savings was defeated: https://ballotpedia.org/Wisconsin_Daylight_Saving_Time_Referendum,_Question… In the tz db for North America, it looks like Wisconsin is using America/Chicago which has a few rules for the time period in question: Rule Chicago 1922 1954 - Sep lastSun 2:00 0 S Rule Chicago 1955 1966 - Oct lastSun 2:00 0 S It appears to me that Wisconsin might need some modification? Is this the correct mailing list for this discussion? Thanks, TJ

3 3

Ref: What time is it: managing time in the internet
by Brian Inglis April 17, 2021

April 17, 2021

"What time is it: managing time in the internet", p37–44, July 2019, "Proceedings of the Applied Networking Research Workshop" https://dl.acm.org/doi/10.1145/3340301.3341125 "investigation of how current local time is reported accurately by devices connected to the internet", analysis of tzdb and updates, "proposals for enhancing TZDB management and reducing vulnerabilities in the system." -- 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 binary units and prefixes, physical quantities in SI.]

2 2

Terminology: “Central European Summer Time” vs “Europe/Berlin”
by Michael[tm] Smith April 15, 2021

April 15, 2021

In the time zone taxonomy, if the term for “Europe/Berlin” is clearly “time zone”, and “GMT+2” is precisely a “timezone offset”, is there a term (other than “time zone”) for what “Central European Summer Time” is — either an authoritative/ normative term, or else at least a best-practice term that’s commonly used? The context is, I’m updating some of the MDN documentation related to JavaScript methods and properties for dealing with dates, including these articles: * https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/… * https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/… And in particular, I’m working on trying to describe the timeZoneName property, in the context of the following behavior: Consider the following code: TZ=Europe/Berlin node -e "console.log(new Intl.DateTimeFormat('en-us', \ { timeZoneName: 'short' }).formatToParts())" When you run that, what you get back is this: [ { type: 'month', value: '4' }, { type: 'literal', value: '/' }, { type: 'day', value: '13' }, { type: 'literal', value: '/' }, { type: 'year', value: '2021' }, { type: 'literal', value: ', ' }, { type: 'timeZoneName', value: 'GMT+2' } ] So part of what I want to explain in the MDN articles is: When you specify “timeZoneName: 'short'”, what you get back as the value for the 'timeZoneName' field in the output is actually a time zone *offset* — not a time zone. But along with that, I need to deal with describing this case: TZ=Europe/Berlin node -e "console.log(new Intl.DateTimeFormat('en-us', { timeZoneName: 'long' }).formatToParts())" When you run that, what you get back is this: [ { type: 'month', value: '4' }, { type: 'literal', value: '/' }, { type: 'day', value: '13' }, { type: 'literal', value: '/' }, { type: 'year', value: '2021' }, { type: 'literal', value: ', ' }, { type: 'timeZoneName', value: 'Central European Summer Time' } ] That’s the particular thing I’m struggling with — that is, when you specify “timeZoneName: 'long'”, what do I call the 'Central European Summer Time' that you get back in the output? Something like “a localized long name for the associated time zone offset” is the best I’ve been able to come up with. But I’ve been hoping there might be some authoritative term for it that I’ve not managed to find yet. And I realize there’s no “Central European Summer Time” in the zoneinfo data itself — and so implementations get that by doing some kind of lookup against (I guess) CLDR. So I guess it’s expected that the documentation for the IANA timezone database itself doesn’t have a term for it. And I guess it’s also unsurprising that CLDR seems to just use the term “time zone” to refer to it — since CLDR doesn’t need to bee more precise and since because CLDR doesn’t need to do anything with the actual canonical time zone names such as Europe/Berlin, it doesn’t have the problem of distinguishing between what a time zone is and what time zone offset is. But from what I’ve seen in issues and questions reported by developers at MDN and Stack Overflow, probably the single biggest source of chronic frustration that developers have when dealing with date-related methods and properties in programming languages comes down to a fundamental misunderstanding of what a time zone is, and how it differs from time zone offset. So I’ve admired what Matt Johnson-Pint has done at Stack Overflow in answering many questions — and in putting the https://stackoverflow.com/tags/timezone/info and https://stackoverflow.com/tags/timezone-offset/info pages together — to provide developers with the kind of clarity they need to solve their problems. And so what I’m hoping to do with my MDN changes is to bring similar clarity to developers through MDN. And so also that’s why it seems important to get the terminology right at MDN when explaining to developers exactly what “Central European Summer Time” is. –Mike -- Michael[tm] Smith https://people.w3.org/mike

6 10

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

News article about EU DST
by Matt Johnson-Pint April 1, 2021

April 1, 2021

Good article from Bloomberg about how the pandemic has put the EU's plans to stop daylight saving time on hold. https://www.bloomberg.com/news/articles/2021-03-11/will-daylight-saving-tim… (It covers a bit about the recent US bill as well.) It also links to a humorous bit about time in Iceland from 2009 that may be worthy of our tz-art.html page: https://www.youtube.com/watch?v=q5q77MQzU2Q Cheers! -Matt

1 0

Relation between Time Zone Abbreviation and Offset in Asia
by Evgheni Antropov March 30, 2021

March 30, 2021

Dear Tzdata Maintainers, Is it historically appeared in Asia, that several Locations have Offset only instead of Time Zone Abbreviation? I mean next location: Bangkok<https://www.timeanddate.com/time/zone/thailand/bangkok> from Thailand<https://www.timeanddate.com/time/zone/thailand> which is related with Vientiane<https://www.timeanddate.com/time/zone/laos/vientiane> from Laos<https://www.timeanddate.com/time/zone/laos> and Phnom Penh<https://www.timeanddate.com/time/zone/cambodia/phnom-penh> from Cambodia<https://www.timeanddate.com/time/zone/cambodia> - all of them is in Indochina Time<https://www.timeanddate.com/time/zones/ict>, but in repository for file asia they have only offset: https://github.com/eggert/tz/blob/main/asia#L3823 I don't know is it issue or typo, cause I didn't find any info when this Abbreviation was added https://en.wikipedia.org/wiki/UTC%2B07:00 For our customers, I added this step before compiling tzdata sources: # set Asia/Bangkok for Thailand to use name instead of digits in timezone, affecting on Asia/Vientiane for Laos and Asia/Phnom_Penh for Cambodia sed -i -e '/# Thailand/,/Vientiane/s/+07/ICT/' $(pwd)/asia but maybe it doesn't require and you will add corresponding changes in the main source code. BTW, during my investigation, I observed that several time zones have same behavior, ex.: Tajikistan<timeanddate.com/time/zone/tajikistan> - Asia/Dushanbe<https://www.timeanddate.com/time/zone/tajikistan/dushanbe> - TJT - Tajikistan Time<https://www.timeanddate.com/time/zones/tjt> https://github.com/eggert/tz/blob/main/asia#L3817 Turkmenistan<https://www.timeanddate.com/time/zone/turkmenistan> - Asia/Ashgabat<https://www.timeanddate.com/time/zone/turkmenistan/ashgabat> - TMT - Turkmenistan Time<https://www.timeanddate.com/time/zones/tmt> https://github.com/eggert/tz/blob/main/asia#L3834 United Arab Emirates<https://www.timeanddate.com/time/zone/united-arab-emirates> - Asia/Dubai<https://www.timeanddate.com/time/zone/united-arab-emirates/dubai> - GST - Gulf Standard Time<https://www.timeanddate.com/time/zones/gst> https://github.com/eggert/tz/blob/main/asia#L3839 Uzbekistan - Asia/Samarkand | Asia/Tashkent - UZT - Uzbekistan Time<https://www.timeanddate.com/time/zones/uzt> https://github.com/eggert/tz/blob/main/asia#L3851 Vietnam - Asia/Ho_Chi_Minh - ICT - Indochina Time<https://www.timeanddate.com/time/zones/ict> https://github.com/eggert/tz/blob/main/asia#L3920 Sri Lanka - Asia/Colombo - IST - India Standard Time<https://www.timeanddate.com/time/zones/ist> https://github.com/eggert/tz/blob/main/asia#L3645 Singapore - Asia/Singapore - SGT - Singapore Time<https://www.timeanddate.com/time/zones/sgt> https://github.com/eggert/tz/blob/main/asia#L3581 Saudi Arabia - Asia/Riyadh - AST - Arabia Standard Time<https://www.timeanddate.com/time/zones/ast-arabia> https://github.com/eggert/tz/blob/main/asia#L3565 Qatar - Asia/Qatar - AST - Arabia Standard Time<https://www.timeanddate.com/time/zones/ast-arabia> https://github.com/eggert/tz/blob/main/asia#L3518 Please give me explanation of this, is it correct to use Offset instead of Abbreviation or it will be fixed in future? Best regards, [cid:image001.jpg@01D72579.B94CFD20] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/>

2 1

[PATCH] Update Crimea country codes in line with UN A/RES/73/263
by Dimitri John Ledkov March 27, 2021

March 27, 2021

"the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, temporarily occupied by the Russian Federation" is the preffered way to refer to the Crimean Peninsula as called upon by the A/RES/73/263 point 11. [1] Unfortunately there is no two letter country code to state precisely that. For internet & computer users however whenever any locale & location is derived from the zone.tab & zone1970.tab file formats results in most appropriate UX with a temporary RU country code. [1] https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/73/263 Note, that it is best read in conjuction with resolutions from previous and subsequent sessions. I.e. https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/68/262 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/71/205 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/72/190 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/73/194 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/73/263 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/74/17 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/75/29 Signed-off-by: Dimitri John Ledkov <xnox(a)ubuntu.com> --- Users from the Crimean Pensinsula are reporting issues when using computer systems. Many pieces of software derive and display location/country based on the zone.tab file format which doesn't reflect the widely internationally acknowledged (as ratified by UN general assembly resolutions) temporary occupation of the pensinsula by the Russian Federation. Currently, the currency in use is rubles; telephone country codes switch to +7, with old ones defunct; MasterCard/Visa networks replaced by MIR network; car license plates are issues with Russian area codes; local government *.gov.ua websites are defunct, replaced with *.gov.ru, e.g. https://sev.gov.ua/ => https://sev.gov.ru/; and so on. As this issue is causing distress to the users of the Internet, I hope that this proposed temporary updated could be included in the tzdata update. zone.tab | 8 ++++---- zone1970.tab | 6 ++++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/zone.tab b/zone.tab index 14fceb9..35e2493 100644 --- a/zone.tab +++ b/zone.tab @@ -331,10 +331,10 @@ RO +4426+02606 Europe/Bucharest RS +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area -# The obsolescent zone.tab format cannot represent Europe/Simferopol well. -# Put it in RU section and list as UA. See "territorial claims" above. -# Programs should use zone1970.tab instead; see above. -UA +4457+03406 Europe/Simferopol Crimea +# "the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, +# temporarily occupied by the Russian Federation" +# Temporarily list as RU. See "territorial claims" above. +RU +4457+03406 Europe/Simferopol Crimea RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan diff --git a/zone1970.tab b/zone1970.tab index ddb2321..d699388 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -288,8 +288,10 @@ RO +4426+02606 Europe/Bucharest RS,BA,HR,ME,MK,SI +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area -# Mention RU and UA alphabetically. See "territorial claims" above. -RU,UA +4457+03406 Europe/Simferopol Crimea +# "the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, +# temporarily occupied by the Russian Federation" +# Temporarily list as RU. See "territorial claims" above. +RU +4457+03406 Europe/Simferopol Crimea RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan -- 2.27.0

3 5

time zone history for the Cook Islands - Christmas Day Act 1899
by wtz＠worldtimezone.com March 25, 2021

March 25, 2021

Cook Islands changed its date from the west (Asia, New Zealand, Australia) side to the east (American) side on Christmas day 1899. In 1899 the Cook Islands celebrated Christmas twice to correct the calendar. According to the old books, missionaries were unaware of the International Date line, when they came from Sydney. Thus the Cook Islands were one day ahead. ".... The Christmas Day Act was designed to change the time to that of Tahiti and all other civilised places east of the 180th degree of longitude: it is a measure that has been strongly opposed by the Maoris on previous occasions ..." (Lieut-Colonel Gudgeon, 14 Sep, 1899) See references below: Discoverers of the Cook Islands and the Names They Gave (Victoria University of Wellington) Christmas Day Act 1899 http://nzetc.victoria.ac.nz/tm/scholarly/tei-KloDisc-t1-body-d18.html (page 60) PACIFIC ISLANDS. PROCEEDINGS OF THE BRITISH RESIDENT, RAROTONGA. (National Library of New Zealand) Appendix to the Journals of the House of Representatives, 1900 https://atojs.natlib.govt.nz/cgi-bin/atojs?a=d&d=AJHR1900-I.2.1.2.3 (page 20) I guess, Zone Pacific/Rarotonga was +13:20:56 before Christmas 1899 and on Christmas Day 1899 time zone has been changed to -10:39:04 (text Christmas Day Act 1899 on our web site): https://www.worldtimezone.com/dst_news/dst_news_cook-islands01.html (or Christmas Day Act 1899 screenshot): https://www.worldtimezone.com/images/1899-cook-island.gif Regards, Alexander Krivenyshev, https://www.worldtimezone.com

4 5

Palestine summer time 2021
by Sharef Mustafa March 24, 2021

March 24, 2021

Hi, Palestine to start summer time on Sat Mar 27th after midnight as per cabinet announcement "وأقر مجلس الوزراء بدء التوقيت الصيفي في دولة فلسطين، بتقديم عقارب الساعة 60 دقيقة، اعتبارا من منتصف ليل الجمعة/ السبت الموافق 27-3-2021" "The Council of Ministers approved the start of daylight saving time in the State of Palestine, by presenting the clock at 60 minutes, starting at midnight Friday / Saturday 27-3-2021 " https://www.facebook.com/PMO.Palestine/posts/4198242146875242 https://www.maannews.net/news/2035719.html BR

3 2

[PROPOSED] Fix ‘make check_time_t_alternatives’
by Paul Eggert March 24, 2021

March 24, 2021

* zic.c (EPOCH_LOCAL, EPOCH_OFFSET, time_tz): #undef, so that zic uses the system ‘time’ function instead of relying on any replacement. That way, zic doesn’t depend on localtime.c. This fixes a problem introduced in 2021-02-23T07:03:07Z!eggert@cs.ucla.edu when zic.c started using the ‘time’ function to generate crude random numbers. --- zic.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/zic.c b/zic.c index 6c38bd7..d1e9a97 100644 --- a/zic.c +++ b/zic.c @@ -5,6 +5,12 @@ ** 2006-07-17 by Arthur David Olson. */ +/* Use the system 'time' function, instead of any private replacement. + This avoids creating an unnecessary dependency on localtime.c. */ +#undef EPOCH_LOCAL +#undef EPOCH_OFFSET +#undef time_tz + #include "version.h" #include "private.h" #include "tzfile.h" -- 2.27.0

1 0

[PATCH] Restore simpler delta_nonneg code.
by Paul Eggert March 24, 2021

March 24, 2021

* zdump.c (delta_nonneg): Undo previous change to this area that inadvertently installed an unnecessary ‘if’. --- zdump.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/zdump.c b/zdump.c index e1db329..918d09c 100644 --- a/zdump.c +++ b/zdump.c @@ -716,16 +716,10 @@ hunt(timezone_t tz, char *name, time_t lot, struct tm *lotmp, time_t hit, static intmax_t delta_nonneg(struct tm *newp, struct tm *oldp) { - register intmax_t result; - register int tmy; - - result = 0; - tmy = oldp->tm_year; - if (newp->tm_year - tmy > YEARSPERREPEAT) { - intmax_t cycles = (newp->tm_year - tmy) / YEARSPERREPEAT; - result = cycles * (YEARSPERREPEAT * DAYSPERNYEAR + 100 - 4 + 1); - tmy += cycles * YEARSPERREPEAT; - } + intmax_t oldy = oldp->tm_year; + int cycles = (newp->tm_year - oldy) / YEARSPERREPEAT; + intmax_t sec = SECSPERREPEAT, result = cycles * sec; + int tmy = oldp->tm_year + cycles * YEARSPERREPEAT; for ( ; tmy < newp->tm_year; ++tmy) result += DAYSPERNYEAR + isleap_sum(tmy, TM_YEAR_BASE); result += newp->tm_yday - oldp->tm_yday; -- 2.27.0

1 0

zoneinfo generating issues
by 汪蒙蒙（木之） March 17, 2021

March 17, 2021

Hi: Recently, I wanted to write a program to watch the change of timezone database. I got newest version from this address: https://data.iana.org/time-zones/releases/tzdata2021a.tar.gz. I used zic (version: zic (tzcode) 2020c, system: CentOS Linux release 7.6.1810 (Core)) to generate the zoneinfo. I pick up some zones with local timeto calculate utc time to verify the changes using both the new and currently used version tzdata, here is diff: zone local time by 2021a utc time by 2020d utc time America/Adak 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 America/Anchorage 2022-11-01 00:00:00 2022-11-01 08:00:00 2022-11-01 09:00:00 America/Asuncion 2022-10-01 00:00:00 2022-10-01 04:00:00 2022-10-01 03:00:00 America/Atka 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 Those zones are not changed from version 2020d to 2021a. I am very confused and not sure if I generated the zoneinfo in the right way. Here was what do: # mkdir zoneinfo # cd tzdata2021a # zic -d ../zoneinfo -L ./leapseconds africa antarctica asia australasia europe northamerica southamerica etcetera backward factory I was wondering if you could provide me some help. I really appreciate your reply. Sincerely, wangmm

11 27

Should tzfile.5 list the time zone designations field more explicitly?
by Ian Abbott March 17, 2021

March 17, 2021

The description of the local time types entries mentions the array of time zone abbreviation bytes in passing, but that probably deserves its own list item. On skimming over the man page, it looks like the local time type entries are immediately followed by the leap-second correction records. -- -=( Ian Abbott <abbotti(a)mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

2 2

[PROPOSED] Improve coverage of version 4 interoperability
by Paul Eggert March 17, 2021

March 17, 2021

* tzfile.5: Mention problems with version 3-only readers and version 4 files, and update other interoperability coverage. --- tzfile.5 | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/tzfile.5 b/tzfile.5 index 8ee6cfb..b4952d5 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -243,10 +243,13 @@ Readers that only understand Version 1 must ignore any data that extends beyond the calculated end of the version 1 data block. .PP -Writers should generate a version 3 file if +Other than version 1, writers should generate +the lowest version number needed by a file's data. +For example, a writer should generate a version 3 file +if the file does not contain a truncated leap second table +and so does not use version 4 features, but TZ string extensions are necessary to accurately -model transition times. -Otherwise, version 2 files should be generated. +model transition times so the file does need version 3 features. .PP The sequence of time changes defined by the version 1 header and data block should be a contiguous subsequence @@ -269,7 +272,7 @@ and This is for compatibility with POSIX requirements for time zone abbreviations. .PP -When reading a version 2 or 3 file, readers +When reading a version 2+ file, readers should ignore the version 1 header and data block except for the purpose of skipping over them. .PP @@ -328,6 +331,10 @@ for the next time zone east, e.g., .q "AST4" for permanent Atlantic Standard Time (\-04). .IP * +Some readers designed for earlier versions reject version 4 files, +because they require complete leap second tables that do not record +expiration dates. +.IP * Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. As a partial workaround, a writer can output more transitions -- 2.27.0

1 0

[PATCH 1/7] localtime.c is less finicky about leap seconds
by Paul Eggert March 17, 2021

March 17, 2021

* localtime.c (tzloadbody): Do not reject a TZif file merely because its leap second table contains adjacent entries with equal corrections, or contains a first entry with a correction value other than +1 or -1. * NEWS: Mention this. --- NEWS | 5 +++++ localtime.c | 13 ++++++++++--- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 0de05f3..d8676e6 100644 --- a/NEWS +++ b/NEWS @@ -39,6 +39,11 @@ Unreleased, experimental changes seconds error than with an hour error, so zic -L no longer truncates output in this way. + The TZif reader now allows the leap second table to begin with a + correction other than -1 or +1, and to contain adjacent + transitions with equal corrections. This supports possible + future extensions to the TZif format. + Fix bug that caused 'localtime' etc. to crash when TZ was set to a all-year DST string like "EST5EDT4,0/0,J365/25" that does not conform to POSIX but does conform to Internet RFC 8536. diff --git a/localtime.c b/localtime.c index 6627ff2..a086d4d 100644 --- a/localtime.c +++ b/localtime.c @@ -445,7 +445,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); int_fast64_t prevtr = 0; - int_fast32_t prevcorr = 0; + int_fast32_t prevcorr; int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); int_fast32_t typecnt = detzcode(up->tzhead.tzh_typecnt); @@ -542,9 +542,16 @@ tzloadbody(char const *name, struct state *sp, bool doextend, and UTC months are at least 28 days long (minus 1 second for a negative leap second). Each leap second's correction must differ from the previous one's by 1 - second. */ + second or less, except that the first correction can be + any value; these requirements are more generous than + RFC 8536, to allow future RFC extensions. */ if (tr - prevtr < 28 * SECSPERDAY - 1 - || (corr != prevcorr - 1 && corr != prevcorr + 1)) + || ((timecnt == 0 || sp->ats[0] < tr) + && ! (i == 0 + || (prevcorr < corr + ? corr == prevcorr + 1 + : (corr == prevcorr + || corr == prevcorr - 1))))) return EINVAL; sp->lsis[leapcnt].ls_trans = prevtr = tr; sp->lsis[leapcnt].ls_corr = prevcorr = corr; -- 2.27.0

2 7

changing "master" to "main" in tzdb development repository
by Paul Eggert March 17, 2021

March 17, 2021

Because the word "master" has negative connotations in English, I renamed the "master" branch to "main" in the tzdb development repository <https://github.com/eggert/tz>. This follows in the wake of GitHub's October change that makes the default branch "main" rather than "master", and GitHub's followup changes in January that made renaming relatively painless - for example, web requests for "master" are now redirected to "main" automatically <https://github.com/github/renaming/>. This renaming by GitHub is part of a broader change within the Git software ecosystem <https://sfconservancy.org/news/2020/jun/23/gitbranchname/>. This change affects neither past nor future releases of tzdb. It affects only the small number of direct accesses to the development repository for commits between releases. The idea is that on balance the small inconvenience for developers is outweighed by the advantage in reducing insensitivity overall. If you are a developer with a local clone of the tzdb repository, please adjust to this change by running the following shell commands: $ git branch -m master main $ git fetch origin $ git branch -u origin/main main I've done this for my own local clone of the repository. To document this change for tzdb newcomers, I installed the attached patch to the CONTRIBUTING file just before renaming the branch.

8 8

Troubles with zone Asia/Gaza after tzdata2020b release
by Evgheni Antropov March 15, 2021

March 15, 2021

Dear tzdata maintainers, I have found that after tzdata2020b release something has gone wrong with Asia/Gaza timezone, which is related to Palestine. For checking I used this information https://www.timeanddate.com/worldclock/palestine/gaza and for DST at 2019: https://www.timeanddate.com/time/change/palestine/gaza?year=2019 for DST at 2020: https://www.timeanddate.com/time/change/palestine/gaza?year=2020 for DST at 2021: https://www.timeanddate.com/time/change/palestine/gaza?year=2021 I compiled all last release of tzdata from 2019c to 2021a and was comparing them with Ubuntu packages for 2020b on groovy (20.10) and 2021a on bionic (18.04). If several changes in the date of DST for different years can be related with last applied laws of DST in Palestine (described here http://mm.icann.org/pipermail/tz/2020-October/029376.html) but broken timezone output in letters or numbers is speaking about any error in the this time zone code. Can you investigate this too ? On screenshot you can see all my investigation: [cid:image002.png@01D70EDB.BE0D5350] Also I share all commands and listing for your execution itself: [root@Router8:~]# ls -la /etc/localtime lrwxrwxrwx 1 root root 35 Mar 4 2021 /etc/localtime -> /usr/share/zoneinfo/posix/Asia/Gaza [root@Router8:~]# ls -la /usr/share/zoneinfo/posix/Asia/Gaza* lrwxrwxrwx 1 root root 41 Mar 27 01:00 /usr/share/zoneinfo/posix/Asia/Gaza -> /usr/share/zoneinfo/posix/Asia/Gaza.2019c -rw-r--r-- 1 root root 2316 Oct 22 09:34 /usr/share/zoneinfo/posix/Asia/Gaza.2019c -rw-r--r-- 1 root root 2316 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020a -rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020b -rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020c -rw-r--r-- 1 root root 1195 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020d -rw-r--r-- 1 root root 1213 Mar 1 2021 /usr/share/zoneinfo/posix/Asia/Gaza.2021a -rw-r--r-- 1 root root 2316 Oct 19 2020 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b -rw-r--r-- 1 root root 2459 Jan 27 2021 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a [root@Router8:~]# date +"%Y%m%d %T" -s "20190328 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20190328 23:59:55 Thu Mar 28 23:59:59 2019 +0200 EET Fri Mar 29 01:00:01 2019 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020a' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0200 EET Fri Mar 27 01:00:01 2020 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020b /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020b' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0000 Fri Mar 27 00:00:01 2020 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020c /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020c' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0000 Fri Mar 27 00:00:01 2020 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0200 EET Fri Mar 27 01:00:01 2020 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2021a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2021a' [root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20210326 23:59:55 Fri Mar 26 23:59:59 2021 +0000 Sat Mar 27 00:00:01 2021 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a' [root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20210326 23:59:55 Fri Mar 26 23:59:59 2021 +0200 EET Sat Mar 27 01:00:01 2021 +0300 EEST Best regards, [cid:image001.jpg@01D70EC7.959CF010] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/>

4 12

Re: [tz] [PROPOSED] Fix Sierra Leone typo for 1957
by REMI ACIEN March 11, 2021

March 11, 2021

For Sierra Leone : -0:53:00 - FMT 1913 Jun # Freetown Mean Time. Envoyé depuis mon appareil Galaxy

2 1

Re: [tz] Some time zone history (4) (P Chan)
by Yandex.ru March 9, 2021

March 9, 2021

On Wed, Mar 03, 2021 at 04:22:48PM +0000, P Chan via tz wrote: > Russia > … > The 1922 transition in Moscow seems to be wrong. The 1922 transition in Moscow is true, that confirmed by law: +1h on 15.02.1922 at 23:00 Msk https://www.lawmix.ru/zakonodatelstvo/2575961 -1h on 30.09.1922 at 24:00 Msk https://www.lawmix.ru/zakonodatelstvo/2575587

1 0

Some time zone history (4)
by P Chan March 8, 2021

March 8, 2021

Russia Before 14 February 1918, Julian calendar was used in Russia. Therefore for the 1917 transitions in tz, 1 July should be 14 July and 28 December should be 10 January 1918. Decrees for the 1917 forward transition: http://docs.historyrussia.org/ru/nodes/33879#mode/inspect/page/1/zoom/4 http://docs.historyrussia.org/ru/nodes/33986#mode/inspect/page/4/zoom/4 http://docs.historyrussia.org/ru/nodes/34925#mode/inspect/page/3/zoom/4 In 1920, there were four transitions, the dates were the same as 1921. http://docs.historyrussia.org/ru/nodes/16730#mode/inspect/page/1/zoom/4 http://docs.historyrussia.org/ru/nodes/16813#mode/inspect/page/1/zoom/4 http://docs.historyrussia.org/ru/nodes/21879#mode/inspect/page/1/zoom/4 The 1922 transition in Moscow seems to be wrong. Instead, there should be a transition in 1924. http://www.libussr.ru/doc_ussr/ussr_1984.htm You may also refer to a section on the Russian Wikipedia. https://ru.wikipedia.org/wiki/%D0%92%D1%80%D0%B5%D0%BC%D1%8F_%D0%B2_%D0%A0%… ----- Tanzania Standard time of GMT+2:30 was adopted on 1913-10-01, then GMT+3 at midnight of 1925-05-16, GMT+2:45 on 1937-01-01 and GMT+3 on 1942-08-01. Popular Astronomy: A Review of Astronomy and Allied Sciences, Volume 22, p 328 https://books.google.com/books?id=yVFGAQAAMAAJ&pg=PA328 General Notice No. 335 of 1925, 1905-05-13, Tanganyika Gazette, Vol. VI No.20, 1925-05-15, p 175 Interpretation (Standard Time) Order in Council, 1929 (Government Notice No. 11), 1929-01-21, Supplement to the Tanganyika Territory Gazette, Vol. X, No.5, 1929-01-25, p 9 Interpretation (Standard Time) Order, 1936 (Government Notice No. 159), 1936-10-13, Ibid., Vol. XVII, No. 56, 1936-11-06, p 270 Interpretation (Standard Time) Order, 1942 (Government Notice No. 259), 1942-07-15, Ibid., Vol. XXIII, No. 36, 1942-07-24,p 296 https://1drv.ms/u/s!AgX5Bc6Y-VsIi2-tBj4iXt90KNrV?e=8yoy29 ----- Uganda At some point after 1905-11-08, Uganda time was 30 minutes behind Mombasa Mean Time. At some point before 1908-04-25, GMT+2:30 was adopted as the standard time. In 1937 and 1942, new standard times in Uganda were adopted simultaneously in Kenya and Tanganyika. Notice. Uganda Official Time., 1905-11-08, The Official Gazette of the East Africa and Uganda Protectorates, 1905-12-01, p 392 https://books.google.com/books?id=FsRZ7PcucTEC&pg=RA1-PA392 "Local Time.", East African Standard, Mombasa Times and Uganda Argus, 1907-11-23, p 16 http://ddsnext.crl.edu/titles/31664#?c=0&m=260&s=0&cv=15&r=0&xywh=1130%2C24… "Standard Time.",Ibid., 1908-04-25, p 17 http://ddsnext.crl.edu/titles/31664#?c=0&m=282&s=0&cv=16&r=0&xywh=3187%2C18… General Notice No. 601 of 1936, 1936-11-03, Official Gazette of the Uganda Protectorate, Vol. XXIX, No.25, 1936-11-16, p 385 General Notice No. 213 of 1942, 1942-07-11, The Uganda Gazette, Vol. XXXV, No. 14, 1942-07-15, p 102 https://1drv.ms/u/s!AgX5Bc6Y-VsIi3O5OxfZRvN46GWA?e=EbwRAe ----- Zimbabwe Standard time of GMT+2 was adopted in 1899-08-01. Before that, GMT+2:30 was used in Salisbury. The Bulawayo Chronicle, 1899-07-08, p 5 Government Notice No. 160 of 1899, 1899-07-20, The British South Africa Company Government Gazette, 1899-07-21, p 199 https://1drv.ms/u/s!AgX5Bc6Y-VsIi3Ruk-lLkymGZBUN?e=bJnSaL ----- Israel For the fallback transition in 1980, it could be either at 24:00 or 24:00s. sources with 24:00s: Maariv⁩, 1980-09-09, p 1 https://www.nli.org.il/en/newspapers/mar/1980/09/09/01/article/7 Davar,⁩ 1980-09-10, p 2 and 10 https://www.nli.org.il/en/newspapers/dav/1980/09/10/01/article/14 https://www.nli.org.il/en/newspapers/dav/1980/09/10/01/article/114.2 The Jerusalem Post, 1980-09-10, p 18 https://search.proquest.com/docview/918197263 source with 24:00: Maariv, 1980-09-10, p 12 https://www.nli.org.il/en/newspapers/mar/1980/09/10/01/article/83 sources with "midnight": Al-Ittihad⁩, 1980-09-12, p 8 https://www.nli.org.il/en/newspapers/?a=d&d=alittihad19800912-01&dliv=userc… The Jerusalem Post, 1980-09-10, p 1 and 1980-09-14, p 1 https://search.proquest.com/docview/918209000 https://search.proquest.com/docview/918188423 For the fallback transition in 1984, it should be at 24:00. Maariv, 1984-08-24, p 1 https://www.nli.org.il/en/newspapers/mar/1984/08/24/01/article/6 Al-Ittihad⁩, 1984-08-26, p 2 https://www.nli.org.il/en/newspapers/?a=d&d=alittihad19840826-01&dliv=userc… The Jerusalem Post, 1984-08-21, p 4 and 1984-08-24, p 1 https://search.proquest.com/docview/924823083 https://search.proquest.com/docview/924051659 The Jerusalem Post images: https://1drv.ms/u/s!AgX5Bc6Y-VsIjBGvgWp_o9PZfHyu?e=VmSRwW ------ Cyprus Before independence, DST was observed in 1940-1945 and 1948 List of Summer Time Orders: http://www.cylaw.org/cgi-bin/sinocgi.pl?title=summer+time&searchoption=1&di… An article on the government website said that DST in Cyprus was first implemented in 1976. https://cyineu.pio.gov.cy/%CE%B5%CF%80%CE%B9%CE%BA%CE%B1%CE%B9%CF%81%CF%8C%… List of decrees for DST since 1976: http://www.cylaw.org/cgi-bin/sinocgi.pl?title=%C8%E5%F1%E9%ED%DE%F2+%BF%F1%… Apparently, no decree was issued for DST in 1975 and 1977-1979. http://www.cylaw.org/KDP/1975.html http://www.cylaw.org/KDP/1977.html http://www.cylaw.org/KDP/1978.html http://www.cylaw.org/KDP/1979.html For other years, the rules in tz mostly match with the degrees, except: 1. spring forward transitions in 1994-1997 were at 00:01 instead of 00:00. 2. fallback transitions in 1996 and 1997 were at 24:00 of the last Saturday of October (or 00:00 of the last Sunday of October) instead of September. 3. EU rules were first used for the spring forward transition in 1998 instead of September 1998. The Sovereign Base Areas of Akrotiri and Dhekelia has similar DST rules as Cyprus. List of Summer Time Orders of the Sovereign Base Areas: 1976: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1980: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1981: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1982: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1983: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1984: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1985: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1986: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1987: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1988: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1989: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1990: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1991: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1992: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1993: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1994: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1995: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1996: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1997: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1998: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… (EU rules have been adopted since 1998) These orders were not publicly listed, some were searchable by search engine, the others were found by brute-force. Apparently, no order was issued for DST before 1976 and 1977-1979. These orders mostly correspond to the decrees of Cyprus, except the transition times were in GMT, which was not stated in the decrees of Cyprus prior to 1998. Also, spring forward transition in 1994 was 00:00 (GMT) instead of 00:01. ------ Shanghai Standard time of GMT+8 was adopted by the French concession at noon on 1903-01-01, before that GMT+8:05:56.7 (Shanghai mean time) was used. "A New Time for the New Year", The North China Herald and Supreme Court & Counsular Gazette, 1902-12-31, p 1383 https://search.proquest.com/docview/1369511715/ The Straits Times, 1903-01-09, p 5 https://eresources.nlb.gov.sg/newspapers/Digitised/Article/straitstimes1903… Newspaper sources for DST observed in 1919 and 1940-1949: (These are taken from "全国报刊索引" https://www.cnbksy.com/ and "中國近代報刊" https://www.dhcdb.com.tw/SP/) https://1drv.ms/u/s!AgX5Bc6Y-VsIjBV8vf4qIDkPyE_7?e=LUQyIy The China Press 1919-04-13, p 26 1919-09-28, p 1 1940-05-31, p 1 1941-03-15, p 10 1941-11-02, p 2 1946-05-15, p 5 1946-10-01, p 2 1947-04-15, p 1 1947-09-21, p 5 1948-04-30, p 9 1948-09-30, p 1 1949-05-01, p 5 The North-China Daily News 1940-10-13, p 6 1949-06-01, p 1 The Shanghai Sunday Times 1942-02-01, p 4 The Shanghai Times 1942-10-23, p 5 Shun Pao (申報) 1945-08-28, p 2 The spring forward transitions in 1941 and 1942 should be at 24:00, the fallback transition in 1945 should be at 00:00. Actually these can also be deduced from Li Yu's article: footnote 29: 《沪市继续推行日光节约运动，自本月十五日午夜实行》，《申报》1941年3月12日，第7版。 footnote 34: 《日光节约时间昨夜开始》，《申报》1942年2月1日，第3版。 the sentence before footnote 37:"...宣布本年9月1日零时起结束'日光节约时间'" The communist city government ended DST at 00:00 on 1949-06-01. The rules for Shanghai and Taipei in 1946-1949 are the same. Maybe they can be merged. ------ Malaysia and Singapore Some of the sources mentioned in Aslaksen's webpage about Singapore time: Government Notification No. 1000, 1900-09-06, Straits Settlements Government Gazette, 1900-09-07, p 1933 https://eservice.nlb.gov.sg/data2/BookSG/publish/f/fe38abfe-bfbb-46f2-b977-… Government Notification No. 201, 1904-02-22, Ibid., 1904-02-26, p 300 https://eservice.nlb.gov.sg/data2/BookSG/publish/d/df4b34d6-7388-4c84-9b33-… Daylight Saving Ordinance, 1932 (No. 21 of 1932), Ibid., 1932-12-23, p 2623 https://eservice.nlb.gov.sg/data2/BookSG/publish/1/1d7e5694-43e5-46b2-b050-… Government Notification No. 2367, 1933-12-04, Ibid., 1933-12-15, p 2706 https://eservice.nlb.gov.sg/data2/BookSG/publish/9/91e94bfb-1e92-4451-badc-… Government Notification No. 2371, 1934-10-08, Ibid., 1934-10-19, p 2954 https://eservice.nlb.gov.sg/data2/BookSG/publish/d/d9d45030-bb72-4d5c-8a7e-… Daylight Saving (Amendment) Ordinance, 1935 (No. 5 of 1935), Ibid., 1935-03-08, p 488 https://eservice.nlb.gov.sg/data2/BookSG/publish/e/e16c3415-b038-48c8-90c2-… Daylight Saving Ordinance (Chapter 170), The laws of the Straits Settlements Edition of 1936, Vol VI, p 694 https://eservice.nlb.gov.sg/data2/BookSG/publish/b/b8f6f919-b64d-4ac5-ab10-… Daylight Saving (Amendment) Ordinance, 1941 (No. 33 of 1941), Supplement to the laws of the Straits Settlements, 1942, Vol I, p 223 https://eservice.nlb.gov.sg/data2/BookSG/publish/6/6f963fc2-9708-41c5-b7b2-… Daylight Saving Ordinance (Chapter 266), The laws of the Colony of Singapore Edition of 1955, Vol VII, p 319 https://eservice.nlb.gov.sg/data2/BookSG/publish/5/57ab953e-f062-40ea-aeda-… Interpretation and General Clauses Ordinance (Chapter 2), Ibid., Vol I, pp 17-38 https://eservice.nlb.gov.sg/data2/BookSG/publish/9/91034b99-bb5f-4ec6-b371-… Singapore Standard Time Notification (G.N. No. S 392/1981) https://sso.agc.gov.sg/SL/IA1965-N1/Historical/19920325?DocDate=20000831&Va… Malaysian Standard Time Act 1981 (Act 261) http://www.commonlii.org/my/legis/consol_act/msta1981223/ Other sources: "Malaya Finished With 'Tokyo Time'", The Straits Times, 1945-09-07, p 1 https://eresources.nlb.gov.sg/newspapers/Digitised/Article/straitstimes1945… Statute Law Revision Bill (Bill No. 36/1970) https://sso.agc.gov.sg/Bills-Supp/36-1970/Published/19700728?DocDate=197007… With regard to Aslaksen and tz, the 1935 Ordinance, which made the Daylight Saving Ordinance permanent, was commenced on 1935-03-08. During WWII, Kuala Lumpur was occupied by Japanese a month earlier than Singapore. Kuching was also occupied earlier in December 1941. Therefore it is unlikely that they switched to GMT+9 on the same day. The Daylight Saving Ordinance was repealed by the Statute Law Revision Act 1970 (No. 48 of 1970). The 1981/1982 transition took place at 16:00 GMT on 1981-12-31. (This was actually mentioned by Mok Ly Yng but the entry has remained uncorrected since 2003.) Some of the sources for Sarawak: Order No. VIII, 1926, 1926-02-11 The Sarawak Government Gazette, 1926-02-16, Vol.19 No.433, p 54 https://books.google.com.hk/books?id=VKbL-mOu1F8C&pg=PA54 Notification No. 429, 1930-06-30 Ibid., 1930-07-01, Vol.23 No. 552, p 248 https://books.google.com/books?id=B5saIO8yLL0C&pg=RA4-PA14 Notification No. 436, 1931-06-24 Ibid., 1931-07-01, Vol.24 No. 579 p.193 https://books.google.com/books?id=YqvrMnxJHAYC&pg=RA16-PP3 Notification No. 798, 1931-12-03 Ibid., 1932-01-02, Vol.24 No. 591, p 356 https://books.google.com/books?id=YqvrMnxJHAYC&pg=RA30-PA10 Notification No. 1274, 1940-09-06 Ibid., 1940-09-16, Vol.33 No.38, p 701 https://books.google.com/books?id=HDU3vTSR4UYC&pg=PA701 Defence (Standard Time (revocation)) Regulations, 1946 Ibid., Vol. 1 No.4, 1946-08-16, p 48 https://books.google.com/books?id=pWd9qBTe4gYC&pg=PA48 Standard Time Ordinance, 1946 (No. 2 of 1946) Ibid., Vol. 1 No.20, 1946-12-16, p 232 https://books.google.com/books?id=pWd9qBTe4gYC&pg=PA232 Standard Time Regulations, 1950 Colony of Sarawak Supplement to the Government Gazette, Sup. No. 6, 1950-04-17, p 50 https://books.google.com/books?id=GelAgpgyMpUC&pg=RA1-PA50 Standard Time (Amendment) Ordinance, 1950 (No. 2 of 1950) Ibid., Sup. No. 12, 1950-05-30, p 91 https://books.google.com/books?id=GelAgpgyMpUC&pg=RA1-PA91 "Sarawak Standard Time", The Sarawak Gazette, 1926-03-01, p 55 https://www.pustaka-sarawak.com/gazette/gazette_uploaded/1370908367.pdf#pag… "Mainly About Nothing", Ibid., 1929-12-02, p 213 https://www.pustaka-sarawak.com/gazette/gazette_uploaded/1399273124.pdf#pag… "Time in Sarawak", Ibid, 1932-10-01, p 168 https://www.pustaka-sarawak.com/gazette/gazette_uploaded/1399277620.pdf#pag… "Sarawak Chronology", Ibid, 1961-07-31, p 131 https://www.pustaka-sarawak.com/gazette/gazette_uploaded/1403144292.pdf#pag… "Summer Time in Sarawak" ,The Straits Times, 1932-09-29, p 19 https://eresources.nlb.gov.sg/newspapers/Digitised/Article/straitstimes1932… The Sarawak Government Gazette, 1929 https://books.google.com/books?id=wmtR6OfLitQC The Sarawak Government Gazette, 1941 https://books.google.com/books?id=sTOu9S62f9IC Standard time of GMT+7:30 was adopted in Sarawak on 1926-03-01. DST was officially observed in 1930-1939, GMT+7:50 was used from September to December. The 1933 transition in tz should be an error. According to some sources, DST was also observed in 1929, but the details are unclear. It was not mentioned in the Government Gazette issues published in 1929. According to the Defence (Standard Time (revocation)) Regulations, 1946, the Defence (Standard Time) Regulations, 1941 suspended the 1926 Order. But the text of the 1941 Regulations is unknown. The 1941 issues of Government Gazette on Google Books are only up to 1941-12-09. Therefore it is likely that those regulations were publish after that day. The 1946 Regulations reinstated the 1926 Order but did not affect the clock. The time zone being used during 1945-1946 is unclear. Standard time of GMT+8 has been adopted since 1950-05-01. "NBorneo" do not seem to be an appropriate name for the rules for Sarawak (Asia/Kuching). Since "North Borneo" usually refers to the territory which is now Sabah.

2 1

Temporal - ECMAScript built-in JS Library for dates/times/timezones/calendars in progress
by Jase Williams March 8, 2021

March 8, 2021

Hi I'm one of the TC39 (EcmaScript) delegates. As a heads up to anyone interested, we're creating a new built-in module in JavaScript (to hopefully replace Date()) called Temporal. This new, rich API includes: - First-class support for all time zones, including DST-safe arithmetic - Strongly-typed objects for dates, times, date/time values, year/month values, month/year values, "zoned" date/time values, and durations - Immutability for all Temporal objects - String serialization and interoperability via standardized formats - Compliance with industry standards like ISO 8601, RFC 3339, and RFC5545 (iCalendar) - Full support for non-Gregorian calendars Feel free to play around with it and offer feedback on the repo. The repository is here: https://github.com/tc39/proposal-temporal Documentation here: https://tc39.es/proposal-temporal/docs/index.html Polyfill here: https://github.com/tc39/proposal-temporal/tree/main/polyfill EcmaScript spec: https://tc39.es/proposal-temporal/ It's currently Stage 2 which means it's under review, but there's hope to see this implemented in Browsers/NodeJS soon. For consideration in tz-link.html. Feel free to adjust wording Project: https://github.com/tc39/proposal-temporal NPM: https://www.npmjs.com/package/proposal-temporal Thanks Jason Williams

6 5

[PROPOSED] Omit some no-longer-live packages
by Paul Eggert March 4, 2021

March 4, 2021

* tz-link.html: Remove pointers to some software packages that no longer seem live: ZoneInfo.Java, Time Zone Master, VelaTerra. --- tz-link.html | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/tz-link.html b/tz-link.html index af8885f..e7570a2 100644 --- a/tz-link.html +++ b/tz-link.html @@ -580,9 +580,6 @@ the Apache License.</li> library that translates between <abbr>UT</abbr> and civil time and can read <abbr>TZif</abbr> files. It is freely available under the Apache License.</li> -<li><a href="http://bmsi.com/java/#TZ">ZoneInfo.java</a> -is a <abbr>TZif</abbr> file reader written in Java. -It is freely available under the <abbr>LGPL</abbr>.</li> <li><a href="https://github.com/derickr/timelib">Timelib</a> is a C library that reads <abbr>TZif</abbr> files and converts timestamps from one time zone or format to another. @@ -667,15 +664,6 @@ href="https://www.oracle.com/java/index.html">Oracle Java</a> contains a copy of a subset of a recent <code><abbr>tz</abbr></code> database in a Java-specific format.</li> -<li><a href="https://relativedata.com/page/Time-Zone-Master">Time Zone -Master</a> is a Microsoft Windows clock program that can automatically -download, compile and use <code><abbr>tz</abbr></code> releases. -The Basic version is free.</li> -<li><a -href="http://veladg.com/velaterra.html">VelaTerra</a> is -a macOS program. Its developers -<a href="http://veladg.com/tzoffer.html">offer free -licenses</a> to <code><abbr>tz</abbr></code> contributors.</li> </ul> </section> -- 2.27.0

1 0

Eighth Continent Zealandia/Te Riu-a-Maui
by Brian Inglis March 3, 2021

March 3, 2021

Australians appear to agree that New Zealand is situated on its own (largely submerged) continental crust, along with nearby island groups, so we may have to consider a future split: https://www.bbc.com/future/article/20210205-the-last-secrets-of-the-worlds-… https://www.gns.cri.nz/static/unclos/images/unclosbook_print.pdf https://en.wikipedia.org/wiki/Zealandia#Political_divisions -- 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 binary units and prefixes, physical quantities in SI.]

3 2

Some time zone history (3)
by P Chan March 3, 2021

March 3, 2021

Correction: > British Guiana/Guyana adopted GMT-4 on 1911-08-01, GMT-3:75 on 1915-03-01, GMT-3 on 1975-08-01 and GMT-4 on 1992-03-29. GMT-3:75 should be GMT-3:45 --------- Most of the documents below were obtained from British Online Archives and LLMC Digital. ---------- Barbados https://1drv.ms/u/s!AgX5Bc6Y-VsIi3ioucfhJMcNlHr_?e=wjYyQa Definition of Time Act, 1911 (1911-7) [1911-08-28] Defence (Daylight Saving) Regulations, 1942, 1942-04-13 Defence (Daylight Saving) (Repeal) Regulations, 1942, 1942-08-22 Defence (Daylight Saving) Regulations, 1943, 1943-04-16 Defence (Daylight Saving) (Repeal) Regulations, 1943, 1943-09-01 Defence (Daylight Saving) Regulations, 1944, 1944-03-21 Defence (Daylight Saving) (Repeal) Regulations, 1944, 1944-04-30 Standard time of GMT-4 was adopted in 1911. DST was observed in 1942-44. The transitions were: 1942-04-19 05:00 GMT 1942-08-31 06:00 GMT 1943-05-02 05:00 GMT 1943-09-05 06:00 GMT 1944-04-09 05:00 GMT 1944-09-10 06:00 GMT --------- Gambia https://1drv.ms/f/s!AgX5Bc6Y-VsIi0MbGvyuIXGge6Iq Interpretation Ordinance, 1914 (No. 12 of 1914) [1914-09-29] Interpretation Ordinance, 1933 (No. 10 of 1933) [1933-03-31] Notice No. 5 of 1942, Colony of the Gambia Government Gazette, Vol. LIX, No.2, 1942-01-15, p 2 Interpretation (Amendment) Ordinance, 1946 (No. 3 of 1946) [1946-07-15] Standard time of GMT-1 was adopted on 1933-04-01. On 1942-02-01, GMT was adopted as a war time measure. This was made permanent in 1946. --------- Malawi https://1drv.ms/f/s!AgX5Bc6Y-VsIi0sbGvyuIXGge6Iq Interpretation and General Clauses Ordinance, 1911 (No. 12 of 1911) [1911-07-24] Notice No. 124 of 1914, 1914-06-30, The Nyasaland Government Gazette, Vol. XXI, No. 8, 1914-06-30, p 122 Interpretation and General Clauses (Amendment) Ordinance, 1925 (No. 3 of 1925) [1925-04-02] In 1911, Zomba mean time was adopted as the legal time of Nysaland. In 1914, Zomba mean time switched from GMT+2:21:10 to GMT+2:21. On 1925-07-01, GMT+2 was adopted. ---------- Nigeria https://1drv.ms/f/s!AgX5Bc6Y-VsIi0cbGvyuIXGge6Iq Government notices for the transition in 1905 and 1908. Government Notice No. 427 of 1905, 1905-06-17, Government Gazette. Colony of Lagos, No. 32, 1905, 1905-06-21, p 395 Government Notice No. 742 of 1908, 1908-06-24, Government Gazette. Colony of Southern Nigeria, No. 44, Vol. 3, 1905-06-24, p 869 ---------- Sierra Leone https://1drv.ms/f/s!AgX5Bc6Y-VsIi1EbGvyuIXGge6Iq Government Notice No. 121 of 1913 , 1913-06-06, Sierra Leone Royal Gazette, Vol. XLIV, No. 1384, 1913-06-14, p 347 Alteration of Time Ordinance, 1932 (No. 34 of 1932) [1932-12-01] Alteration of Time (Amendment) Ordinance, 1938 (No. 25 of 1938) [1938-11-24] Defence Regulations (No. 9), 1939 (Regulations No. 9 of 1939),1939-09-05 Defence Regulations (No. 11), 1939 (Regulations No. 11 of 1939), 1939-09-27 Defence (Amendment) (No.17) Regulations, 1941 (Public Notice No.157 of 1941), 1914-12-04 Alteration of Time (Amendment) Ordinance, 1946 (No. 2 of 1946) [1946-02-07] Standard time of GMT-1 was adopted on 1913-07-01. Twenty minutes of DST was introduce in 1932 and was suspended in 1939. In 1941, GMT was adopted by Defence Regulations. This was made permanent in 1946. For DST in 1957-62, I have looked through the gazettes from 1957 to 1961 but could not find any laws or notices related to DST. Also, the Local Time Ordinance (Cap 2, 1960 Revised Edition) <https://books.google.com/books?id=B-U-AQAAIAAJ&pg=PA18> does not contain any provisions related to DST. Proposed Rules: # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule SL 1932 only - Dec 1 0:00 0:20 -0040 Rule SL 1933 1938 - Mar 31 24:00 0 -01 Rule SL 1933 1939 - Aug 31 24:00 0:20 -0040 Rule SL 1939 only - May 31 24:00 0 -01 Rule SL 1939 only - Sep 5 0:00 0 -01 Zone Africa/Freetown -0:53:00 - LMT 1882 -0:53:00 - FMT 1913 Jul 1 # Freetown Mean Time -1:00 SL %s 1941 Dec 6 24:00 0:00 - GMT

2 5

Re: [tz] tz Digest, Vol 114, Issue 4
by Alan Lehotsky March 2, 2021

March 2, 2021

I can confirm that there can be funny behavior on 32 bit O/S if zic runs without -b fat Sent from my iPhone > On Mar 2, 2021, at 10:08, 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. Re: Troubles with zone Asia/Gaza after tzdata2020b release > (Evgheni Antropov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Mar 2021 08:49:33 +0000 > From: Evgheni Antropov <Evgheni.Antropov(a)addgrup.com> > To: Paul Eggert <eggert(a)cs.ucla.edu>, Tim Parenti > <tim(a)timtimeonline.com> > Cc: Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b > release > Message-ID: <5b8eea9809f34e658c6529708744c1ad(a)addgrup.com> > Content-Type: text/plain; charset="us-ascii" > > Dear Paul and Tim, > Thank you for attention to this issue. > > We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel > [root@Router8:~]# uname -a > Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux > > Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora > > Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install > #!/bin/sh > make clean > > #For compiling source extract tzdata and tzcode in one directory and run: > make TOPDIR=$(pwd)/binaries install > > with additional changes related with requests from our several customers, which are not effecting on the this file. > > In attachment you can see whole listing of compilation. > > Best regards, > > > Evgheni Antropov > Software R&D Engineer > +373 22 404 665 > www.addgrup.com<http://www.addgrup.com> > > > -----Original Message----- > From: Paul Eggert <eggert(a)cs.ucla.edu> > Sent: Tuesday, March 2, 2021 01:59 > To: Tim Parenti <tim(a)timtimeonline.com> > Cc: Evgheni Antropov <Evgheni.Antropov(a)addgrup.com>; Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b release > >> On 3/1/21 1:19 PM, Tim Parenti via tz wrote: >> Why is the system you're >> testing only looking at the (legacy) 32-bit data in the v1 data block, >> and not using the 64-bit data in the v2+ data block? Please let us >> know more about the system you're running > > Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. > Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem. > > Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza. > >> Please let us know more >> about the system you're running > > Yes, that'd be helpful. >

1 0

zdump man page misleading?
by Martin Burnicki Feb. 26, 2021

Feb. 26, 2021

Hi, the zdump.8.txt file generated from the current github code says: -c [loyear,]hiyear ... Cutoffs are at the start of each year, where the lower-bound timestamp is *exclusive* and the upper is *inclusive*; for example, -c 1970,2070 selects transitions after 1970-01-01 00:00:00 UTC and on or before 2070-01-01 00:00:00 UTC. The default cutoff is -500,2500. and $ ./zdump -V -c 2021,2022 Europe/Berlin Europe/Berlin Sun Mar 28 00:59:59 2021 UT = Sun Mar 28 01:59:59 .. Europe/Berlin Sun Mar 28 01:00:00 2021 UT = Sun Mar 28 03:00:00 .. Europe/Berlin Sun Oct 31 00:59:59 2021 UT = Sun Oct 31 02:59:59 .. Europe/Berlin Sun Oct 31 01:00:00 2021 UT = Sun Oct 31 02:00:00 .. (lines shorted to avoid line-wrapping) So the lower year is *inclusive* and the upper year is *exclusive*, and from my understanding these words should be swapped in the text of the man page. Or am I missing something? If I'm correct, should I provide a patch or pull request for the git repo? Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki(a)meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy

3 3

time zones only ?
by William Karlsson Feb. 25, 2021

Feb. 25, 2021

Is there a simple way to compile only the timezones ? i.e. US/Central etc... No cities ? -- // Karlsson

3 2

New IANA-timezone support date/time library
by Kerry Shetline Feb. 24, 2021

Feb. 24, 2021

I’ve just finished an extensive update of a JavaScript/TypeScript date/time library that I’d previously used only for my own astronomy website, skyviewcafe.com <http://skyviewcafe.com/>. I’ve done enough updates to this library now that it may be of interest to many other software developers, especially if they want to handle the odd edge cases that exist in timezone handling, like 47-hour days and missing days and the like. One unique features is that it's possible for users to get live updates of the tz database, which usually don’t become available to applications without, at the very least, restarting an application, if not rebooting one’s computer. Libraries in this category are hardly unique, but one of the most popular libraries, Moment.js, is being phased out, so this seemed to be to be a good time to introduce a new one. Among the (possible) unique features, you can do things like find the specific moments of DST transitions and other transitions, like UTC offset changes, and get descriptions of these changes, like this: new DateTime('2021-11-07', 'America/New_York').getDiscontinuityDuringDay() → { start: '02:00:00', end: '01:00:00', delta: -3600000 } // fall back! // As soon as it’s midnight on the 30th, it’s instantly midnight on the 31st, erasing 24 hours:<br> new DateTime('2011-12-30', 'Pacific/Apia').getDiscontinuityDuringDay()) → { start: '00:00:00', end: '24:00:00', delta: 86400000 } // As soon as it’s midnight on the 31th, turn back to 1AM on the 30th, adding 23 hours to the day:<br> new DateTime('1969-09-30', 'Pacific/Kwajalein').getDiscontinuityDuringDay() → { start: '24:00:00', end: '01:00:00', delta: -82800000 } My updated library can be found here: https://www.npmjs.com/package/@tubular/time <https://www.npmjs.com/package/@tubular/time> Besides the IANA timezone support, this library also features the ability to handle variable switch-over from the Julian to the Gregorian calendar, which can be of helpful to those handling historical dates.

8 9

Re: [tz] Gratuitous optimization
by Paul Eggert Feb. 23, 2021

Feb. 23, 2021

Thanks, I installed your performance fix via the attached proposed patch. The performance bug seems to have been introduced by my commit 30364485a6fdc0333f48905db387e07abb70bac1 (2013-09-08) "Improve the support for perpetual DST" which first appeared in tzdb 2013e.

1 0

Re: [tz] New IANA-timezone support date/time library
by Kerry Shetline Feb. 23, 2021

Feb. 23, 2021

On 2021-02-22, at 14:25, Paul Gilmartin <PaulGBoulder(a)AIM.com> wrote: > But the "Help" link (<https://skyviewcafe.com/help/>) fails with 404. The “Help” link is working now, so I’m not sure what the issue was at the time you clicked on it. > I don't know whether you've followed the "Kiev"/"Kyiv" debate on tz(a)iana.org. > But I was curious what skyviewcafe.com does about it. I read a little of that, but haven’t followed it. At least the pronunciation of Kyiv isn’t an issue! ;) My geographic data base finds the Ukrainian capital by either spelling, so that’s not a problem. I’m not sure if showing “Europe/Kyiv” in my interface would be confusing or not, since that’s not the existing IANA name for the associated timezone. Users are generally expected to click “Find”, and find cities by name, thus getting longitude, latitude, and timezone automatically without fussing with a manual selection, so the IANA names aren’t quite so important. I also intend to update my manual interface to make timezone selections by standard UTC offset, and then a list of zones in that offset, as the default way to make a manual timezone selection, with region/zone being a secondary option. > I tried to enter > "50°25'N 30°31'E". I learned: > o It's tedious to enter such coordinates digit-by-digit. > o I found no way to refresh the page with the coordinates entered. It’s definitely tedious compared to just looking up a city and getting lat/long automatically. But if one wants to enter info manually, I’m curious what you’d prefer as a means of input. The manual entry field also supports rolling digits up and down, which is a fun way to explore how the sky changes as you change latitude and longitude. > Tz, trying to pivot away from the debate, says that internal directory > and filenames should not be obvious to users. Thus, applications should > not show me "America", "Denver", or "Kiev”. I hadn’t really thought of those names like “America/New_York” as file names, but as names for timezones as abstract timezone entities. In fact, there is no “America/New_York” file in the tzdb. There’s a file named “northamerica”, and inside that file, a zone entry named "America/New_York”. Perhaps that’s still something a bit too rawly technical to be considered user-friendly, however. -Kerrt

3 2

[PATCH 1/5] Don't cite Howse where no longer used
by Paul Eggert Feb. 23, 2021

Feb. 23, 2021

--- africa | 3 --- asia | 3 --- 2 files changed, 6 deletions(-) diff --git a/africa b/africa index 28168cf..fca9af7 100644 --- a/africa +++ b/africa @@ -30,9 +30,6 @@ # Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94. # https://www.jstor.org/stable/1774359 # -# A reliable and entertaining source about time zones is -# Derek Howse, Greenwich time and longitude, Philip Wilson Publishers (1997). -# # European-style abbreviations are commonly used along the Mediterranean. # For sub-Saharan Africa abbreviations were less standardized. # Previous editions of this database used WAT, CAT, SAT, and EAT diff --git a/asia b/asia index ed94413..ac7def8 100644 --- a/asia +++ b/asia @@ -34,9 +34,6 @@ # Byalokoz EL. New Counting of Time in Russia since July 1, 1919. # (See the 'europe' file for a fuller citation.) # -# A reliable and entertaining source about time zones is -# Derek Howse, Greenwich time and longitude, Philip Wilson Publishers (1997). -# # The following alphabetic abbreviations appear in these tables # (corrections are welcome): # std dst -- 2.27.0

2 6

Some time zone history (2)
by P Chan Feb. 21, 2021

Feb. 21, 2021

Bahamas There were two periods of DST observed in 1941-1945: 1941-05-01 midnight to 1944-12-31 and 1945-02-01 to 1945-10-17 midnight. War Time Order 1942 [1942-05-01] and War Time (No. 2) Order 1942 [1942-09-29] Appendix to the Statutes of 7 George VI. and the Year 1942. p 34, 43 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA3-PA34 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA3-PA43 War Time Order 1943 [1943-03-31] and War Time Order 1944 [1943-12-29] Appendix to the Statutes of 8 George VI. and the Year 1943. p 9-10, 28-29 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA4-PA9 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA4-PA28 War Time Order 1945 [1945-01-31] and the Order which revoke War Time Order 1945 [1945-10-16] Appendix to the Statutes of 9 George VI. and the Year 1945. p 160, 247-248 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA6-PA160 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA6-PA247 ---------- Guyana British Guiana/Guyana adopted GMT-4 on 1911-08-01 , GMT-3:75 on 1915-03-01, GMT-3 on 1975-08-01 and GMT-4 on 1992-03-29. The Official Gazette of British Guiana. (New Series.) Vol. XL. July to December, 1915, p 1547 https://books.google.com/books?id=5-5CAQAAMAAJ&pg=SA1-PA547 Interpretation and general clauses (Amendment) Act 1975 (Act No. 27 of 1975) [1975-07-31] https://parliament.gov.gy/documents/acts/10923-act_no._27_of_1975_-_interpr… Interpretation and general clauses (Amendment) Act 1992 (Act No. 6 of 1992) [1992-04-18] https://parliament.gov.gy/documents/acts/5885-6_of_1992_interpretation_and_… Circular No. 10/1992 dated 1992-03-30 https://dps.gov.gy/wp-content/uploads/2018/12/1992-03-20-Circular-010.pdf ---------- Nigeria On 1914-01-01, standard time of GMT+0:30 was adopted for the unified Nigeria. Colonial Reports - Annual. No. 878. Nigeria. Report for 1914. (April 1916), p 27 https://libsysdigi.library.illinois.edu/ilharvest/Africana/Books2011-05/306… Interpretation Ordinance, 1914 (No. 4 of 1914) [1914-10-01] https://books.google.com.hk/books?id=mm5CAQAAMAAJ&pg=PA172 In 1919, standard time was changed to GMT+1. Interpretation Ordinance (Cap 2) The Laws of Nigeria, Containing the Ordinances of Nigeria, in Force on the 1st Day of January, 1923, Vol.I p 5-18 https://books.google.com.hk/books?id=BOMrAQAAMAAJ&pg=PA16 For the standard time used in Lagos before 1914, the Interpretation Ordinance of Southern Nigeria, 1908 revised edition defined “Time” to mean Greenwich time. That section was originated from Proclamation No. 11 of 1905 of the Protectorate of Southern Nigeria. But the Colony of Lagos was not merged into Southern Nigeria until May 1906. Moreover, the 1906 Report of Southern Nigeria says “all laws in force in any part of the territory prior to the commencement of the new system of government shall continue in force until further provision is made by the local legislature.” Lloyd's Register of Shipping (1915) says “Hitherto the time observed in Lagos was the local mean time. On 1st January, 1914, standard time for the whole of Nigeria was introduced … Lagos time has been advanced about 16 minutes accordingly.” Therefore it is possible that no standard time was adopted in Lagos until 1914. Interpretation Ordinance (Cap 2) Laws of the Colony of Southern Nigeria : being the schedule to the Statute laws revision ordinance, 1908, Vol.I, p 3-11 https://babel.hathitrust.org/cgi/pt?id=mdp.35112105426037&view=1up&seq=61 Colonial Reports - Annual. No. 554. Southern Nigeria. Report for 1906. (February 1908), p 43 https://libsysdigi.library.illinois.edu/ilharvest/Africana/Books2011-05/306… Lloyd's Register of Shipping. 1915-16. Vol. II.-Appendix. ,p 655 https://books.google.com/books?id=b_ROAQAAIAAJ&pg=PA655 ---------- Seychelles Standard Time was adopted on 1907-01-01. Standard Time Ordinance (Chapter 237) The Laws of Seychelles in Force on the 31st December, 1971, Vol. 6, p 571 https://books.google.com/books?id=efE-AQAAIAAJ&pg=PA571 ---------- Turks and Caicos Islands Standard Time Declaration Order 2015 (L.N. 15/2015) http://online.fliphtml5.com/fizd/czin/#p=2 Standard Time Declaration Order 2017 (L.N. 31/2017) http://online.fliphtml5.com/fizd/dmcu/#p=2 ---------- Vanuatu DST was observed in 1973/1974. The spring forward in 1984 should be on Sep 23. Joint Daylight Saving Regulation No 59 of 1973 New Hebrides Condominium Gazette No 336. December 1973 http://www.paclii.org/vu/other/VUNHGovGaz//1973/11.pdf#page=15 Joint Daylight Saving (Repeal) Regulation No 10 of 1974 New Hebrides Condominium Gazette No 336. March 1974 http://www.paclii.org/vu/other/VUNHGovGaz//1974/3.pdf#page=11 Summer Time Act No. 35 of 1982 [1983-09-01] http://www.paclii.org/vu/other/VUGovGaz/1982/32.pdf#page=48 Summer Time Act (Cap 157) Laws of the Republic of Vanuatu Revised Edition 1988 http://www.paclii.org/cgi-bin/sinodisp/vu/legis/consol_act1988/sta147/sta14… Summer Time (Amendment) Act No. 6 of 1991 [1991-11-11] http://www.paclii.org/vu/legis/num_act/sta1991227/ Summer Time (Repeal) Act No. 4 of 1993 [1993-05-03] http://www.paclii.org/vu/other/VUGovGaz/1993/15.pdf#page=59

4 11

[PATCH] Fixups for today’s patches
by Paul Eggert Feb. 18, 2021

Feb. 18, 2021

* NEWS: Mention the recent all-year DST change. * zic.c (stringzone): Fix sign bug. --- NEWS | 7 +++++++ zic.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index af5dd9f..f3c94ed 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,13 @@ Unreleased, experimental changes last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3. + zic now generates a POSIX-conforming TZ string for TZif files + where all-year DST is predicted for the indefinite future. + For example, for all-year Eastern Daylight Time, zic now generates + "XXX3EDT4,0/0,J365/23" where it previously generated + "EST5EDT,0/0,J365/25" or "". (Thanks to Michael Deckers for + noting the possibility of POSIX conformance.) + Release 2021a - 2021-01-24 10:54:57 -0800 diff --git a/zic.c b/zic.c index 4893a32..b91cb6c 100644 --- a/zic.c +++ b/zic.c @@ -2519,7 +2519,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) Fake a timezone with negative DST. */ stdzp = &zstr[0]; dstzp = &zstr[1]; - zstr[0].z_stdoff = zp->z_stdoff - 2 * save; + zstr[0].z_stdoff = zp->z_stdoff + 2 * save; zstr[0].z_format = "XXX"; /* Any 3 letters will do. */ zstr[0].z_format_specifier = 0; zstr[1].z_stdoff = zstr[0].z_stdoff; -- 2.27.0

1 0

[PATCH 1/4] Avoid use of local statics
by Paul Eggert Feb. 18, 2021

Feb. 18, 2021

* zic.c (inrule, inzsub, writezone): Avoid use of static when auto will do. This can help GCC catch uninitialized-variable errors. --- zic.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/zic.c b/zic.c index 51977b2..8653fb0 100644 --- a/zic.c +++ b/zic.c @@ -1341,7 +1341,7 @@ getsave(char *field, bool *isdst) static void inrule(char **fields, int nfields) { - static struct rule r; + struct rule r; if (nfields != RULE_FIELDS) { error(_("wrong number of fields on Rule line")); @@ -1418,7 +1418,7 @@ inzsub(char **fields, int nfields, bool iscont) { register char * cp; char * cp1; - static struct zone z; + struct zone z; register int i_stdoff, i_rule, i_format; register int i_untilyear, i_untilmonth; register int i_untilday, i_untiltime; @@ -1868,8 +1868,6 @@ writezone(const char *const name, const char *const string, char version, register FILE * fp; register ptrdiff_t i, j; register int pass; - static const struct tzhead tzh0; - static struct tzhead tzh; bool dir_checked = false; zic_t one = 1; zic_t y2038_boundary = one << 31; @@ -2000,6 +1998,7 @@ writezone(const char *const name, const char *const string, char version, for (pass = 1; pass <= 2; ++pass) { register ptrdiff_t thistimei, thistimecnt, thistimelim; register int thisleapi, thisleapcnt, thisleaplim; + struct tzhead tzh; int currenttype, thisdefaulttype; bool locut, hicut; zic_t lo; @@ -2168,7 +2167,7 @@ writezone(const char *const name, const char *const string, char version, thistimelim = thistimei; } #define DO(field) fwrite(tzh.field, sizeof tzh.field, 1, fp) - tzh = tzh0; + memset(&tzh, 0, sizeof tzh); memcpy(tzh.tzh_magic, TZ_MAGIC, sizeof tzh.tzh_magic); tzh.tzh_version[0] = version; convert(utcnt, tzh.tzh_ttisutcnt); -- 2.27.0

1 3

State of Palestine Time zone - need to update
by heba hamad Feb. 14, 2021

Feb. 14, 2021

Dear Sir/Madam, In reference to your recent response at 25 Oct,2020 regarding State of Palestine's request to correct the 'Time Zone Database', we would like to confirm that 'TZ' related to the State of Palestine is as follows: PS State of Palestine Asia/East Jerusalem UTC +2:00 Also, we would like to inform you that the State of Palestine comprises of the West Bank, including East Jerusalem and Gaza, all of which are integral parts of the State of Palestine, thus, as one territorial unit all areas belong to the same time zone. We would like to also emphasize that East Jerusalem is an integral part of the West Bank as stipulated under international law and by numerous international resolutions. Therefore, we urge you to adopt the official name and correct your data base. Best Regards, Heba Hamad 11 Feb,2021

22 35

[PATCH 1/2] Remove unused C macros
by Paul Eggert Feb. 13, 2021

Feb. 13, 2021

Also, pacify ‘gcc -Wunused-macros’, which was employed to find these unused macros. * localtime.c (NETBSD_INSPIRED_EXTERN): Define only if STD_INSPIRED is defined. * private.h (sys_time) [!TZ_TIME_T]: Inspect LOCALTIME_IMPLEMENTATION. * zdump.c (MAX_STRING_LENGTH): * zic.c (PRIdZIC): Remove these macros, which are no longer used. --- localtime.c | 16 ++++++++-------- private.h | 7 ++++--- zdump.c | 4 ---- zic.c | 1 - 4 files changed, 12 insertions(+), 16 deletions(-) diff --git a/localtime.c b/localtime.c index d3e406b..82a3b70 100644 --- a/localtime.c +++ b/localtime.c @@ -28,14 +28,6 @@ static int lock(void) { return 0; } static void unlock(void) { } #endif -/* NETBSD_INSPIRED_EXTERN functions are exported to callers if - NETBSD_INSPIRED is defined, and are private otherwise. */ -#if NETBSD_INSPIRED -# define NETBSD_INSPIRED_EXTERN -#else -# define NETBSD_INSPIRED_EXTERN static -#endif - #ifndef TZ_ABBR_MAX_LEN #define TZ_ABBR_MAX_LEN 16 #endif /* !defined TZ_ABBR_MAX_LEN */ @@ -2247,6 +2239,14 @@ leapcorr(struct state const *sp, time_t t) #ifdef STD_INSPIRED +/* NETBSD_INSPIRED_EXTERN functions are exported to callers if + NETBSD_INSPIRED is defined, and are private otherwise. */ +# if NETBSD_INSPIRED +# define NETBSD_INSPIRED_EXTERN +# else +# define NETBSD_INSPIRED_EXTERN static +# endif + /* ** IEEE Std 1003.1 (POSIX) says that 536457599 ** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which diff --git a/private.h b/private.h index 9efcd78..a919e4f 100644 --- a/private.h +++ b/private.h @@ -418,10 +418,11 @@ typedef unsigned long uintmax_t; # define TZ_TIME_T 0 #endif -#if TZ_TIME_T -# ifdef LOCALTIME_IMPLEMENTATION +#if defined LOCALTIME_IMPLEMENTATION && TZ_TIME_T static time_t sys_time(time_t *x) { return time(x); } -# endif +#endif + +#if TZ_TIME_T typedef time_tz tz_time_t; diff --git a/zdump.c b/zdump.c index b532fe3..57e363e 100644 --- a/zdump.c +++ b/zdump.c @@ -42,10 +42,6 @@ #define ZDUMP_HI_YEAR 2500 #endif /* !defined ZDUMP_HI_YEAR */ -#ifndef MAX_STRING_LENGTH -#define MAX_STRING_LENGTH 1024 -#endif /* !defined MAX_STRING_LENGTH */ - #define SECSPERNYEAR (SECSPERDAY * DAYSPERNYEAR) #define SECSPERLYEAR (SECSPERNYEAR + SECSPERDAY) #define SECSPER400YEARS (SECSPERNYEAR * (intmax_t) (300 + 3) \ diff --git a/zic.c b/zic.c index b37cdc9..51977b2 100644 --- a/zic.c +++ b/zic.c @@ -21,7 +21,6 @@ typedef int_fast64_t zic_t; #define ZIC_MIN INT_FAST64_MIN #define ZIC_MAX INT_FAST64_MAX -#define PRIdZIC PRIdFAST64 #define SCNdZIC SCNdFAST64 #ifndef ZIC_MAX_ABBR_LEN_WO_WARN -- 2.27.0

1 1

[PATCH] Clarify GCC pacification in previous fix
by Paul Eggert Feb. 13, 2021

Feb. 13, 2021

* zic.c (outzone): Make it clear that prevktime is initialized only to pacify GCC. --- zic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/zic.c b/zic.c index a864bc4..b37cdc9 100644 --- a/zic.c +++ b/zic.c @@ -2715,7 +2715,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) for (i = 0; i < zonecount; ++i) { struct rule *prevrp = NULL; - zic_t prevktime = min_time; + zic_t prevktime; + INITIALIZE(prevktime); /* ** A guess that may well be corrected later. */ -- 2.27.0

1 0

[PATCH] Fix bug in last time type of Asia/Gaza etc.
by Paul Eggert Feb. 13, 2021

Feb. 13, 2021

* zic.c (outzone): When avoiding bloat due to transitions deducible from the TZ string, don’t eliminate transitions that are before any lower-bound cutoff established by -r. All but the last of these transitions will be discarded later by limitrange, and the last transition is needed so that the dummy time type after the TZif file’s last transition agrees with the TZ string as required by Internet RFC 8536 section 3.3. This problem can be observed in tzdb 2021a if you run the command ‘zic -r@2145916800 asia’: the output file Asia/Gaza’s only time transition, which is at the specified time 2038-01-01 00:00:00 UTC, has an associated time type that specifies +03 with DST, rather than the correct +02 without DST. --- NEWS | 6 ++++++ zic.c | 4 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index b9d5777..a22e8ff 100644 --- a/NEWS +++ b/NEWS @@ -6,6 +6,12 @@ Unreleased, experimental changes Portugal observed DST in 1950. (Thanks to Alois Treindl.) + Changes to code + + Fix bug in zic -r; in some cases, the dummy time type after the + last time transition disagreed with the TZ string, contrary to + Internet RFC 8563 section 3.3. + Release 2021a - 2021-01-24 10:54:57 -0800 diff --git a/zic.c b/zic.c index a902b34..a864bc4 100644 --- a/zic.c +++ b/zic.c @@ -2715,6 +2715,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) for (i = 0; i < zonecount; ++i) { struct rule *prevrp = NULL; + zic_t prevktime = min_time; /* ** A guess that may well be corrected later. */ @@ -2851,7 +2852,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) rp->r_isdst, rp->r_save, false); offset = oadd(zp->z_stdoff, rp->r_save); if (!want_bloat() && !useuntil && !do_extend - && prevrp + && prevrp && lo_time <= prevktime && rp->r_hiyear == ZIC_MAX && prevrp->r_hiyear == ZIC_MAX) break; @@ -2865,6 +2866,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) lastatmax = timecnt; addtt(ktime, type); prevrp = rp; + prevktime = ktime; } } if (usestart) { -- 2.27.0

1 0

Replying to government officials
by John Hawkinson Feb. 12, 2021

Feb. 12, 2021

I wonder if we should have some kind of understanding of when it is appropriate for the general members of the list to respond to emails from government officials, versus deferring that task to the project coordinators. (I have thought this was a concern for some time, but multiple recent messages have amplified it in my mind.) -- jhawk(a)alum.mit.edu John Hawkinson

2 1

DST existed in Portugal 1950
by Alois Treindl Feb. 10, 2021

Feb. 10, 2021

TZ claims that in 1950 there was no DST in Portugal, zone Europe/Lisbon. While it was continuously applied between 1916 and 1965. The sources quoted in file europe are poor, it is only Whitman versus Shanks/Pottenger. I have research online law collection for Portugal at https://dre.pt/ and searched for 'hora de verão'. The results are sparse, but what I find on legal texts does not indicate any interruption of the 1916 law for the year 1950. This Wikipedia page shows a list https://pt.wikipedia.org/wiki/Lista_de_per%C3%ADodos_em_que_vigorou_o_hor%C… and mentions the Decreto-Lei nº 37048 for 1949-1965. That law says 'first Sunday in April to first Sunday in October. No exception for 1950. Here is a list from the Lisbon astronomical observatory, which says the same thing. http://oal.ul.pt/documentos/2018/01/hl1911a2018.pdf/ I suggest that the rules for Europe/Lisbon should be updated accordingly.

3 6

Request for change to the tz database
by Nadia Kobyliak Feb. 9, 2021

Feb. 9, 2021

Dear Arthur and Paul, I would like to draw your attention to one of the names of the UTC+2 time zone: Europe/Kiev . And suggest changing it to Europe/Kyiv. This name is derived from the name of Ukrainian capital “Київ”. Its official transliteration(1) is “Kyiv” and not “Kiev”. The transliteration “Kyiv” was approved by the Tenth United Nations Conference on Standardization of Geographical Names(2). This is a warranty of the campaign KyivNotKiev launched by Ministry of Foreign Affairs of Ukraine(3). This is a very important issue for Ukrainians in establishing our national identity in times of an armed conflict and hybrid war by propaganda and misinformation. “To appreciate the significance of the “Kyiv vs. Kiev” debate, one must first step back and view it in terms of the deep-rooted national identity crisis caused by centuries of Tsarist and Soviet russification.” (4) It would make a huge difference if you considered this suggestion! And please let me know, if there is something else I should do to substantiate this proposal. References: 1. According to the rules approved by Governmental decree from 27 January 2010 №55: https://www.kmu.gov.ua/npas/243262567 This particular example could be found there. 2. Resolution X/9. Romanization of Ukrainian geographical names could be found in the Report of the Conference: https://unstats.un.org/unsd/geoinfo/UNGEGN/docs/10th-uncsgn-docs/econf/E_CO… Document approved by the resolution: “Romanization System in Ukraine” https://unstats.un.org/unsd/geoinfo/UNGEGN/docs/10th-uncsgn-docs/econf/E_CO… 1. It may also be interesting for you to find out more about the movement on Wikipedia page: https://en.wikipedia.org/wiki/KyivNotKiev 2. An article on this matter in English could be found on Atlantic Council web-site: https://www.atlanticcouncil.org/blogs/ukrainealert/kyiv-not-kiev-why-spelli… Kind regards, Nadia Kobyliak [Изображение выглядит как знак Автоматически созданное описание] Nadia Kobyliak Senior project manager SOEs and Corporate Governance reform ________________________________ cell.: +38 097 642 35 29 12/2 Hrushevskoho str. me.gov.ua<http://www.me.gov.ua/> kobyliak.nadia(a)gmail.com<mailto:kobyliak.nadia@gmail.com> 01008 Kyiv Twitter<http://twitter.com/mineconomdev> NKobyliak(a)me.gov.ua<mailto:NKobyliak@me.gov.ua> Ukraine Facebook<http://facebook.com/mineconomdev>

17 33

Re: [tz] Request for change to the tz database
by Hal Murray Feb. 8, 2021

Feb. 8, 2021

tim(a)timtimeonline.com said: > Yes, and as the proposal moves forward, we could provide the IANA moderators > with updated boilerplate as necessary. I'd expect the boilerplate to be a pointer to a FAQ entry. I think a note on the page about the list would be helpful and friendly. https://mm.icann.org/mailman/listinfo/tz -- These are my opinions. I hate spam.

1 0

Re: [tz] South Sudan to change time zone?
by Paul Eggert Feb. 8, 2021

Feb. 8, 2021

On 2/7/21 10:16 AM, Hayo Schmidt wrote: > you created a new > edge case by defining 00:00 of a day and then shifting back the date by > one day (and 23 hours forward). This sort of edge case is not new to Africa/Juba. For example, it occurred on 2020-03-22 at 00:00 in America/Asuncion, and is scheduled to occur again on 2021-03-28 at 00:00 at the same location. > A datum could have been created when reaching the first time exactly > 00:00:00.000. This is modeled in tzdb by the clock ticking 23:59:59.999999999 (as many 9s as you like) followed by 23:00:00.000000000 (the same number of 0s). That is, all the timestamps from 23:00:00.000000000 through 23:59:59.999999999 occur twice, but 00:00:00.000000000 the next day occurs only once. In this sense, there's no difference between a transition at 24:00, and one at 02:00. You can seem more details by running the command "zdump -v Africa/Juba".

1 0

Fwd: Timezone issue
by Yaroslav Bilko Feb. 5, 2021

Feb. 5, 2021

Hi, hope you're doing great! I've noticed some libraries use quite an irrelevant name for the capital of Ukraine: "Timezone: Europe/Kiev". And it comes from TZDB. C'mon lads, everybody in the whole civilized world knows that Kiev is wrong but you use it for some reason (only bloody russians talk like this and without any permission from our country (ukrainians), they push that name just because they want conquer our country and erase ukrainnian culture and you help them to achieve this goal!), the only one official name of this city is Kyiv! Yes, many people say "Kiev" even in Ukraine, but their number is getting down very fast. People start to figure it out. And the most important thing - they use it in non-public conversations. In all public places all information must be written Ukrainian (sometimes dubbing with English and that's it). It is protected by the law ( https://zakon.rada.gov.ua/laws/show/2704-19#Text) All Latin transliteration of our cities written in this law: https://zakon.rada.gov.ua/laws/show/z0957-14#Text [image: image.png] No Kiev as you can see. Only Kyiv. Soviet name "Kiev" disappeared 30 years ago. There's no need to exhume this corpse from the grave. Ukraine started a official campaign ( https://mfa.gov.ua/news/67521-correctua-mzs-ukrajini-zvertajetysya-do-svitu… ) some time ago to show other countries and mass media that Kyiv is only one true name. Even Google accepted it and maps show the correct name. That hit me and my friends and colleagues right in a heart! We hope you find some time to fix this little typo, but this is little only for first look! Hope for your care.

4 5

Names of Areas
by Andrea Boyle Feb. 3, 2021

Feb. 3, 2021

Hello, I am writing to you to request a small but significant change to the area options that are currently listed in the database. Recently I used software that uses the database for the area and location information and I was initially very puzzled when trying to find Canada. America was there but no other country in the North or South American continents. After a little research I realized that the database has America represent both. The trouble I have is that America is also a well used name for the United States and represents the name of a country rather than the two continents. I will be honest that it definitely rubbed the wrong way to have to choose America to find a city in Canada and I would also bet that outside of the US it would not be intuitive to choose America when looking for other countries within North and South America. To that end, I think it would be a great improvement to update the area to "Americas" or "the Americas" so that it was much clearer that it represents more than just one country. Thank you -- Andrea Boyle

3 2

(Near) UNIX epoch in the wild
by Arthur David Olson Feb. 1, 2021

Feb. 1, 2021

Today at the Paul S. Sarbanes Silver Spring (Maryland) Transit Center. https://twitter.com/dashdashado/status/1356321947005628418 @dashdashado

2 1

Re: [tz] CCTF survey on Time and Frequency Metrology - Telecom
by Hal Murray Feb. 1, 2021

Feb. 1, 2021

Brian.Inglis(a)SystematicSw.ab.ca said: > My reply suggested they divorce the time scales to allow business systems to > use approximate POSIX like common law legal solar time as they ignore leap > seconds one way or another; allow scientific systems to use atomic time and > ignore legal solar time; and just ignore the ITU as broadcast radio time > signals (DCF/JJY/MSF/WWV/B/H) are unavailable most places, may need > equipment no longer commonly available, and too low accuracy for modern > needs; other commonly available sources are delayed to uselessness by > digital processing. Could you please say more about the "delayed to uselessness"? -- These are my opinions. I hate spam.

9 12

How can I add a new time zone: 'America/Joao Pessoa'?
by Fabrício Cabral Jan. 31, 2021

Jan. 31, 2021

Hi all! How can I add a new time zone? I'd like add 'America/Joao Pessoa'. Joao Pessoa[1] is the capital of Paraiba state, in Brazil. [1] https://en.wikipedia.org/wiki/Jo%C3%A3o_Pessoa,_Para%C3%ADba Best Regards, -- --fx

4 5

Re: [tz] South Sudan to change time zone?
by Chris Hill Jan. 30, 2021

Jan. 30, 2021

On Tue, 19 Jan 2021 at 19:04, Paul Eggert <eggert at cs.ucla.edu> wrote: > > This article says the change will take place at "midnight, February 1": > > > > http://southsudan24news.com/south-sudan-change-its-time-zone-in-february-1-… > > The version I now see says, "The change will occur at 00:00 (midnight) > on February 1, when clocks will be set back 1 hour to 23:00 (11:00 pm)." > This is a bit confusing, because if the change is indeed at 00:00 on > February 1, the quoted text should have ended in "23:00 (11:00 pm) the > previous day" to avoid confusion. > > Perhaps the official announcement (if one is made and someone can > .provide it) will be less confusing. The official announcement (accessible without a Facebook account at https://www.facebook.com/www.motps.goss.org/videos/3770463003014509/ concurs with this: 08:23 'So, from the 1st of February, we are going back to our actual Greenwich Mean Time. We are going back to our local zone, of 2 hours' difference between Greenwich Mean Time, which is the zero hour, and our local time which will be 2 hours, which will be Greenwich Mean Time plus 2 hours' 09:43 'On the 31st, and the morning starts, that morning will not start at 12, but when it is 12 midnight of the 31st of January, it will be 11 o'clock. And you continue like that... Our 12 midnight of the 31st January will repeat itself; it will be 11, and then you go again for 12 midnight. That is when it becomes according to our time now.' We're based in South Sudan so was keen to get this right. Hope it helps. Kind regards, -- Chris Hill IT Officer Mission Aviation Fellowship International T +44 (0)1233 895517 F +44 (0)1233 895570 Operations Centre, Henwood, Ashford, Kent TN24 8DH Mission Aviation Fellowship International. A company Limited by guarantee, registered in England & Wales Registered Charity Number: 1058226. Registered Company Number: 3144199. Registered Office: Operations Centre, Henwood, Ashford, Kent TN24 8DH https://www.mafint.org/ "NOTICE: Any opinions expressed in this message are those of the individual and not necessarily the company. This email (and any attachment) is confidential and may be legally privileged. If you are not the intended recipient, you must not use, disclose, forward, copy, print or retain this email. If you have received this email in error, please notify the sender before deleting it from your computer system. Email transmissions may not be completely secure, may be intercepted or corrupted and may arrive late or not at all. The sender accepts no liability for viruses and we recommend that you scan all emails for viruses before opening them. For more information please contact dataprotection(a)mafint.org<mailto:dataprotection@mafint.org>. To view our Privacy Notice click Here<https://www.mafint.org/privacy-notice.html>. To view our Terms and Conditions click Here<https://www.mafint.org/terms-and-conditions.html>."

6 8

Old London Meridian
by Tim Jacobs Jan. 29, 2021

Jan. 29, 2021

Lines 106 to 125 of tz/europe mention the old meridian before Greenwich. The estimated position is 51° 28' 30" N, 0° 18' 45" W, which would put it north of the river in the grounds of Syon House. The meridian markers are in fact all south of the river, and can be seen by walking the Thames Path on the south bank. The meridian passes through the King's Observatory, with obelisks to the north and south. The map on the information boards shows a total of four obelisks marking the meridian. The website for the King's Observatory quotes the following: "This task was later transferred to Greenwich Observatory but not before three obelisks had been erected in the Old Deer Park in June 1778 to assist in the exact alignment of instruments in the Observatory. The northern one and the western one of the southern pair are on the true north-south meridian line passing through the west room of the Observatory which housed a tracking telescope. The southern obelisk is due south from the east room that at the time housed its great mural quadrant." The position of the King's Observatory is given on Wikipedia as 51°28′08″N 0°18′53″W, which would give STDOFF = -0:01:15.53 I don't suppose anyone is particularly concerned about this, but I thought I would point it out.

1 0

Re: [tz] CCTF survey on Time and Frequency Metrology - Telecom
by Gertsvolf, Marina Jan. 25, 2021

Jan. 25, 2021

Dear Colleague, The last time the definition of the SI second was changed was in 1967 when Caesium atom hyperfine frequency transition was chosen as the reference value. Since then first the primary thermal beam caesium clocks and then caesium fountains have been providing the SI second realization values to steer the International Atomic Timescale. The current fountain uncertainties are at the low 1E-16 level. The frequency metrology research in recent years has surpassed the microwave clocks, and optical frequency standards based on trapped ions and atoms now provide frequency measurements with evaluated uncertainties at the level 1E-18. The frequency comparisons have also been advancing both through improved techniques in Global Navigation Satellite Systems signal analysis and the Two Way satellite Time and Frequency transfer as well as with fibre based frequency links and portable optical clocks. Frequency combs used to compare frequencies between clock lasers of different optical clocks and also between optical frequencies and microwave 133Cs frequency of 9.192631770 GHz are now routine laboratory equipment and are commercially readily available. These factors now provide a solid foundation to prepare for the redefinition of SI second based on the optical frequency standard. The exact approach is currently under discussion and it may be selecting one atomic candidate or building an ensemble. The specific requirements and the conditions for the redefinition to take place are also being finalized. The Consultative Committee for Time and Frequency (CCTF) has started preliminary work on this subject, to investigate possible scenarios and their possible impact. It is within this framework that we contact you an expert in the field of Telecommunications, in order to make sure that the needs and wishes of your community are integrated into the general debate that will take place and may, eventually, lead to the redefinition of the second. With the new definition, the frequency measurement accuracy will surpass that of Caesium-based timescale by at least one order of magnitude and will provide an adequate tool for current and future research into fundamental physics as well as technology exploitation. The redefinition is not expected to affect any of the existing commercial frequency standard uncertainties such as those of caesium beam clocks or hydrogen masers, because their uncertainties are generally orders of magnitude higher than the expected accuracy of the new definition. Same is true for caesium fountains. The computation and dissemination of UTC will also not change, but UTC will become more stable and accurate based on the improved optical realizations of the SI second. We would like to ask your expert opinion on whether the redefinition may have any impact be it negative or positive on your field of study and operation. The issues we would like you to consider are not just scientific and technological, but also regulatory and legislative. Your answers will be carefully examined and taken into account by CCTF in their analysis of Time and Frequency metrology current and future needs and SI second and UTC evolution. You can find the survey at https://www.surveymonkey.com/r/CCTF_Survey_2020 and in the attached letter from CCTF president Noël Dimarcq you will find additional information on other activities at CCTF for your reference. Best regards, The CCTF Task Force on the redefinition of the second, subgroup A Co-chairs: Marina Gertsvolf (marina.gertsvolf(a)nrc-cnrc.gc.ca<mailto:marina.gertsvolf@nrc-cnrc.gc.ca>) Gaetano Mileti (gaetano.mileti(a)unine.ch<mailto:gaetano.mileti@unine.ch>) Secretary: Frederic Meynadier(frederic.meynadier(a)bipm.org<mailto:frederic.meynadier@bipm.org>)

5 4

[CCTF_survey on Time and Frequency metrology]
by Patrizia TAVELLA Jan. 25, 2021

Jan. 25, 2021

Dear Colleague, in December you should have received the announcement of a CCTF survey (see below) aiming to understand the needs and the opinions of the time and frequency community. Please remind that the deadline for the survey is January 31, 2021. This is an important possibility to contribute to the future way forward on some hot topics. Thanks to those who have already answered. Your contribution is really appreciated. Best wishes for the new year Dear Colleague, the Consultative Committee for Time and Frequency (CCTF) is currently working on very important topics concerning the field of Time & Frequency Metrology and its applications. They are: 1. Updating the Roadmap for the redefinition of the second 2. Leap seconds in UTC - building a consensus for a continuous timescale 3. Promoting the mutual benefit of UTC and GNSS 4. Sharing resources to improve international timekeeping To make sure that the needs and wishes of concerned institutional bodies and stakeholder communities are integrated into the general debate, we have prepared specific questionnaires, that we kindly ask you to answer. Your answers, opinions, and ideas will be carefully examined and taken into account by the CCTF in order to provide future guidelines and recommendations. Please find attached a letter explaining the process. Thanks for the contribution you can give to this survey. Please feel free to forward this email to other colleagues in your field that may give useful feedback, and please apologize for multiples emails you may receive on this topic. with sincere appreciation, on behalf of the CCTF, Noel Dimarcq CCTF President Dr Patrizia Tavella Director of Time Department Bureau International des Poids et Mesures Pavillon de Breteuil 12 bis grande rue 92312 Sèvres Cedex Tel : +33 (1) 45 07 7076 Email patrizia.tavella(a)bipm.org<mailto:patrizia.tavella@bipm.org>

1 0

[tz-announce] 2021a release of tz code and data available
by Paul Eggert Jan. 24, 2021

Jan. 24, 2021

The 2021a 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: Changes to future timestamps South Sudan changes from +03 to +02 on 2021-02-01 at 00:00. (Thanks to Steffen Thorsen.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2021a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2021a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2021a.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 336c8f8262e31116878b079abba80b1626baaa8f dated 2021-01-24 10:54:57 -0800 and tagged '2021a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: bf1d53bcbfecd3b09d57a9e6d3cb49b5dc5f8e1b6674b67e7f974e1a268c2aaf13ca89a7ef12f49d0665aff782bd72685e00c22a41ca88a028da0429f972fd45 tzcode2021a.tar.gz 7cdd762ec90ce12a30fa36b1d66d1ea82d9fa21e514e2b9c7fcbe2541514ee0fadf30843ff352c65512fb270857b51d1517b45e1232b89c6f954ba9ff1833bb3 tzdata2021a.tar.gz 1878ec039db73d3255d808e2b28a5acf2b384d4c5d178aaa2048b5b73cd6b34d03c2ab7282ed615d286b695fa46c628d7e4b6fb6f84bf1905ac8dfbb740769c1 tzdb-2021a.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmANxdIACgkQ7ZfpDmKq fjRy5g//Y/CPFNFyrlCJSvZT8pP5f+qGfntGfUGEXBJRdFNmGW8KU/wRLHrK+mEP 8VQgPKZqYaKQwJvVTrDycs96Ntm62sKbzb/tSr04JvxYYcJa4ecvMISI8ePI/M9m sKNoKLDuok/Dnl9yntvDWFjLkw43TBMqZRj+oXxMz9Ui8Cap4iZFZfw+tgedwjUk 8mkd45xLQJ5D9k9K6bXvgy0KIFvhN7+Td16do94QHx86gaiSwgzey81rqetzHisb fj329dq2xMa+5bKxS8QDfbL05HOrxQBKmgJQNl2E7MvonBbXAjrd56FQJjGkaViM cTwhQecrElm9bPIzNduV2zy6CyE+5ZlQcYrUJ73g4pH1kZ7H4S5UdIL0O8sdcDOW Gjj0xUMGdwUpI0k2VkKvMjKQ1LzT/vKZy0S4n2LlHTOtIifUA5SigQ1tPmQuWwW+ XfbDb2reeq1mUzphHvwsakKOSPRfwVeszfN4lgOmh3hOpPvEEkzEhQYVOKYwBvEr sK+zl0a+c3ePOMioC9uUF56B38bRgVcTojA/suaoMJEH8IE8wLBT4dSEjofA0wya kKVpvHZiwTj5mM7bMVgq+gtvaQprI52k/X6HWcBD4CcL0dOMQswmz8Sv2LGd7IFK oFm30G2vBVIzprcKdeezYU83EAeUnASbDt5kPm5PCnzELmgRu4E= =pUNC -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmANxdIACgkQ7ZfpDmKq fjTnYRAAnozc58/XHxdZ92os3TIzGZHDt4jWZt7zeSlzag7C9r0pvq2u0K0AZVPG yGMUpNlFm2fcbks65En8+wRVZ/5AJeEkUA4V2DDMlf5yDtiXZyt42YTu0UL/saZ3 wHEZIPySeZWKdUILp9BTD9ZDmY2VbIceL1PGMfs00Ti98UgmsNG8yJPMD2E86T3H dcsx7kTYFou9KYuvm3GDlxrQO7X/sTVVEnWJF7Z8rLQz4wjPnYn6Lspoav+N0HNR ycRXSADS3c2kjlaeRjjYVKaekJ3oIXvWgfXcYb1CcB59bACDi4HOMvd8kMU/PV5R p7lkZpSvSNNy/5j5MJDV79YVBwas5++yjv8bQZPkDnS/1YvW9I8ca4YYeTGEA1/G 89sysUlUEYzuojs+oApgqFFAwl+Eo0y5MLyOuRxcXgWw6+eTW6oHHaUXLDFq9jwR d0biMlHIFZNyKHZ72dUbSLo8FalHspHdRYBCppwU8cCprJlPc43zuljru86jRYuW jr228IpKq75ngtXbOHexVrnJejCp/NuV3rcfP3FjC2C3HC2Ao95FO9xT0ZlcTpXq +wu2wZ8csf1RO/hzyOHtcpuFZBRL5a4ZQNvqydFgMgfx2oZcSIAz3GmA8qt5BjHQ C+JwBd00A4JvOigUMvprSSvu3OEOv2kCLgAQSJPOSGWbkrr0s08= =5dc0 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmANxdQACgkQ7ZfpDmKq fjQKOg//RWKxqgAHjfiurbEV8E4KJfA1FCN9lnj8Yd0y5r7QXmABKpJvTa//oqy1 s6OvcAlw9KtBx69F5AR8O3/cJSK8ITKTApoYBDoOhPxBQBYkWAg5tM5Eajv0nOlm HlsnKi0jR/vTyDEhBl4XX/dqzcQF0qb0dmdd+Bm5aB3VjeYC5RlebizT5BHEjTtB 2kw/fkoWYt9r9x+drLwTTDeKB2P7PGZiiOsru5sReWJd5liH/htgC9oC8j4vmbKC BnAFAoRtOYiazAJmyc/da4PJXHEBPnsL9iBxGLR265kkn6rg1v+SJhsBQm5Xj3Ci zwDsX4+93Uk2ezU/Eyk+zvIhKIWWWjcSdWa4zVjLROBvX9jQ1xBSFcTN1mBXccEg pbu9U29qISOY11RqtenC++1KXdNFlLdWiNvuLNNYmSRPOVSyfz+h57wkXqj3zlSS MAH6xGdIGH043pofOgmrVkgyywJ8C195ajmgjQoG5CxCf/o1YgBgoJyd07xPZlEv D94ZShvuXMDHtQ7eJOoFcVTOcIRj5WvEmxxup4eEDmFULOQ2RrVphYTkpVApp5ks kQVPxDkANq7cNwBDokuzV9cDX+ScnSEMs7k79TMB1S2szuM/W8g2ZTN2wwQoZq4T 8QMKHQPMTU72IesC38+bn7V2dHxR14jT+tpjVZc3FsguILd7Ev0= =o/OB -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. 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

[PATCH] Update web links
by Paul Eggert Jan. 24, 2021

Jan. 24, 2021

* tz-link.html: Remove broken links and links to expired drafts. C++20 is now official. Replace CIA time zone map link to a more-general link, as the old link’s replacement has a long cookie-like component and is possibly unstable. --- tz-link.html | 45 ++++++++++++++++----------------------------- 1 file changed, 16 insertions(+), 29 deletions(-) diff --git a/tz-link.html b/tz-link.html index 56ef9e4..abe38d8 100644 --- a/tz-link.html +++ b/tz-link.html @@ -352,12 +352,7 @@ transferring time zone data by reference. <a href="https://devguide.calconnect.org/Time-Zones/TZDS/">TZDIST implementations</a> are available. The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis -mailing list</a> discussed the Internet draft <a -id="TZDIST-Geolocate" -href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate">TZDIST -Geolocate Extension</a> (now expired), which let a client determine its timezone -from its geographic location using a <a -href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>.</li> +mailing list</a> discusses possible extensions.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> Internet Calendaring and Scheduling Core Object Specification (iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) @@ -410,11 +405,11 @@ transition in the <code><abbr>tz</abbr></code> database.</li> <li>The <a href="https://howardhinnant.github.io/date/tz.html">Time Zone Database Parser</a> is a <a href="https://en.wikipedia.org/wiki/C%2B%2B">C++</a> parser and -runtime library with API <a -href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html">adopted -into the draft standard</a> for +runtime library with <a +href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html">API</a> +adopted by <a href="https://en.wikipedia.org/wiki/C++20">C++20</a>, -the next iteration of the C++ standard. +the current iteration of the C++ standard. It is freely available under the <abbr title="Massachusetts Institute of Technology">MIT</abbr> license.</li> <li><a id="ICU" href="http://site.icu-project.org">International Components for @@ -627,11 +622,6 @@ It is freely available under the <abbr>GPL</abbr>.</li> implementations contain a copy of a 32-bit subset of a recent <code><abbr>tz</abbr></code> database in a Go-specific format.</li> -<li><a -href="http://users.skynet.be/Peter.Verthez/projects/intclock/">International -clock (intclock)</a> is a clock that displays multiple time zones on -<abbr>GNU</abbr>/Linux and similar systems. It is freely available -under the <abbr>GPL</abbr>.</li> <li>Microsoft Windows 8.1 and later has <code><abbr>tz</abbr></code> data and <abbr>CLDR</abbr> data (mentioned <a href="#CLDR">below</a>) used by the @@ -677,10 +667,7 @@ licenses</a> to <code><abbr>tz</abbr></code> contributors.</li> is Astrodienst's Web version of Shanks and Pottenger's out-of-print time zone history atlases <a href="https://www.worldcat.org/oclc/468828649">for the US</a> and -<a href="https://www.worldcat.org/oclc/76950459">for the world</a>, -now published in <a -href="https://astrocom.com/astrology-products/software/acs-atlas-software">software</a> -form by <a href="https://astrocom.com">ACS-Starcrafts</a>. +<a href="https://www.worldcat.org/oclc/76950459">for the world</a>. Although these extensive atlases <a href="https://astrologynewsservice.com/opinion/how-astrologers-contributed-to-the…">were sources for much of the older <code><abbr>tz</abbr></code> data</a>, @@ -704,11 +691,13 @@ gives current time zone rules for airports served by commercial aviation.</li> <section> <h2 id="maps">Maps</h2> <ul> -<li>The <a href="https://www.cia.gov/index.html">United States Central -Intelligence Agency (<abbr -title="Central Intelligence Agency">CIA</abbr>)</a> publishes a <a -href="https://www.cia.gov/library/publications/the-world-factbook/graphics/ref_ma…">time -zone map</a>; the +<li>The <a +href="https://www.cia.gov/the-world-factbook/maps/world-regional/">World +and Regional Maps section</a> of <em>The World Factbook</em>, published by the +<a href="https://www.cia.gov">US Central Intelligence +Agency (<abbr +title="Central Intelligence Agency">CIA</abbr>)</a>, contains a time +zone map; the <a href="https://legacy.lib.utexas.edu/maps/world.html">Perry–Castañeda Library Map Collection</a> @@ -734,7 +723,9 @@ where the two differ greatly. It's a bit out of date, unfortunately.</li> <section> <h2 id="boundaries">Time zone boundaries</h2> <p>Geographical boundaries between timezones are available -from several <a href="https://en.wikipedia.org/wiki/Geolocation">geolocation</a> +from several <a +href="https://en.wikipedia.org/wiki/Internet_geolocation">Internet +geolocation</a> services and other sources.</p> <ul> <li><a href="https://github.com/evansiroky/timezone-boundary-builder">Timezone @@ -883,10 +874,6 @@ of Legal Time in Germany</a>.</dd> <dd>The Interior Ministry periodically issues <a href="ftp://ftp.cs.huji.ac.il/pub/tz/announcements" hreflang="he">announcements (in Hebrew)</a>.</dd> -<dt>Italy</dt> -<dd>The National Institute of Metrological Research publishes a -<a href="http://oldsite.inrim.it/res/tf/ora_legale_i.shtml" hreflang="it">table -of civil time (in Italian)</a>.</dd> <dt>Malaysia</dt> <dd>See Singapore <a href="#Singapore">below</a>.</dd> <dt>Mexico</dt> -- 2.27.0

1 0