- tz - lists.iana.org

[PROPOSED 1/7] Port better to C23 bool
by Paul Eggert Oct. 20, 2022

Oct. 20, 2022

* private.h (HAVE_STDBOOL_H): Remove. (true, false, bool): Simply rely on __STDC_VERSION__. There’s no longer need to treat pre-C99 compilers with <stdbool.h> specially, as they can be treated as if they lack <stdbool.h>. --- Makefile | 1 - NEWS | 3 +++ private.h | 10 +++------- 3 files changed, 6 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 156840e..afe7af7 100644 --- a/Makefile +++ b/Makefile @@ -223,7 +223,6 @@ LDLIBS= # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX # -DHAVE_SNPRINTF=0 if your system lacks the snprintf function -# -DHAVE_STDBOOL_H if you have a non-C99 compiler with <stdbool.h> # -DHAVE_STDINT_H if you have a non-C99 compiler with <stdint.h> # -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l # -DHAVE_STRDUP=0 if your system lacks the strdup function diff --git a/NEWS b/NEWS index 164ab95..16f454c 100644 --- a/NEWS +++ b/NEWS @@ -37,6 +37,9 @@ Unreleased, experimental changes number 2438 comes from the 32-bit limit in the year 2038, plus the 400-year Gregorian cycle. (Problem reported by Bradley White.) + Take advantage of the following C23 features if available: + bool/true/false keywords. + Release 2022e - 2022-10-11 11:13:02 -0700 diff --git a/private.h b/private.h index 9c31ec5..058d3c0 100644 --- a/private.h +++ b/private.h @@ -74,10 +74,6 @@ # define HAVE_POSIX_DECLS 1 #endif -#ifndef HAVE_STDBOOL_H -# define HAVE_STDBOOL_H (199901 <= __STDC_VERSION__) -#endif - #ifndef HAVE_STRDUP # define HAVE_STRDUP 1 #endif @@ -623,12 +619,12 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; ** Finally, some convenience items. */ -#if HAVE_STDBOOL_H -# include <stdbool.h> -#else +#if __STDC_VERSION__ < 199901 # define true 1 # define false 0 # define bool int +#elif __STDC_VERSION__ < 202311 +# include <stdbool.h> #endif #define TYPE_BIT(type) (sizeof(type) * CHAR_BIT) -- 2.37.3

1 6

[PATCH 0/5] Simplifying Link line maintenance
by Paul Eggert Oct. 17, 2022

Oct. 17, 2022

Although TZDB currently puts most Link lines in the ‘backward’ file, some Link lines reside in the continental files ‘africa’, ‘antarctica’, etc., with little rhyme or reason as to which lines are in ‘backward’ and which line are in a continental file. This is confusing and makes maintenance a bit more difficult. This proposed series of patches aims to regularize this by putting the Link lines into ‘backward’, except that to work around a TZUpdater bug the GMT Link line is in ‘backward’ only when using vanguard form. As part of these patches, the Link lines in ‘backward’ are organized into sections that better explain the reason for each Link line. Also, comments are added to document shortcut Link lines, that is, Link lines reworded to reference the target rather than the source of another Link line. Furthermore, the Makefile is augmented to check Link lines more carefully. The overall effect of this patch is to shrink TZDB’s source code and make maintenance simpler and more robust, without affecting data except for users who are purposely bleeding-edge by omitting all backward-compatibility links. Because these patches are nontrivial I have not installed them in the development repository, and there is no rush. Comments welcome as usual. Paul Eggert (5): Move a few links to ‘backward’ Move most remaining links to ‘backward’ Reorder 'backward’ Improve checking for shortcut links Coalesce some commentary Makefile | 6 +- NEWS | 17 +++ africa | 213 ++++++++++-------------------------- antarctica | 2 +- asia | 69 ++++-------- australasia | 46 +++----- backward | 288 +++++++++++++++++++++++++++++++++++++++---------- checklinks.awk | 17 +++ etcetera | 17 ++- europe | 202 ++++++++++++---------------------- northamerica | 86 ++++----------- southamerica | 15 --- theory.html | 1 + zdump.c | 4 +- ziguard.awk | 14 +++ 15 files changed, 472 insertions(+), 525 deletions(-) -- 2.37.3

2 8

Re: [tz] Northern Ontario (Canada)
by dpatte Oct. 17, 2022

Oct. 17, 2022

Individual reserves usually have their own names such as the one near Fort Frances, "Nigigoonsiminikaaning" (Little Otters Playing). If the whole treaty area followed a rule than I agree that the treaty name would be a good solution. ----- Original Message ----- From: Brian Inglis via tz [mailto:tz@iana.org] To: <tz(a)iana.org> Sent: Sat, 15 Oct 2022 17:35:27 -0600 Subject: Re: [tz] Northern Ontario (Canada) Hi folks, Given that ids are named for the largest municipality observing given rules, and those named municipalities are not documented as nor likely to have diverged from provincial rules, then applying those ids to rural areas, especially reserves, would be erroneous. In the case of Canadian rural reserves, large areas are normally covered by the federal treaties under which those settlements were negotiated, and if reserves in those treaty areas could be documented to have ignored DST, then perhaps better ids would be e.g. Treaty3 for the ON Lake of the Woods Area, and Treaty60 for the ON Nipigon Lake area, given that other applicable labels are likely to be either confusing, excessively long, or require uncommon fonts to render? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry On 2022-10-15 17:02, Chris Walton via tz wrote: > Paul, > The changes look correct except that you linked *America/Rainy_River* to > *America/Toronto* instead of *America/Winnipeg*. > Rainy River is west of 90°W and needs to remain on Central Time. > > David, > I don't deny that there may have been some small reserves that did not observe > daylight saving. > They could still be added to the database if somebody wants to do the research > and provide appropriate names. > However, it would be wrong to use the names of existing towns and cities to > represent small reserves that exist outside of those towns and cities. > > -chris > > On Sat, 15 Oct 2022 at 17:11, dpatte <dpatte(a)relativedata.com > <mailto:dpatte@relativedata.com>> wrote: > > My concern about these changes is that I seem to remember that some first > nations in those areas did not use daylight-savings time on their reserves, > and that they were real but very small 'zones', not the large zones they > ended up being assumed to be. > > Unfortunately I have no documentation either way on this. > > > *----- Original Message -----* > *From:* Paul Eggert via tz [mailto:tz@iana.org] <mailto:tz@iana.org> > *To:* "Chris Walton" <crj.walton(a)gmail.com <mailto:crj.walton@gmail.com>> > *Cc:* tz(a)iana.org <mailto:tz@iana.org> > *Sent:* Sat, 15 Oct 2022 12:53:28 -0700 > *Subject:* Re: [tz] Northern Ontario (Canada) > > Thank you for doing that investigative work. Proposed patch attached and > installed into the tzdb development repository on GitHub. > > This patch follows your suggestions, except that it moves Nipigon's and > Rainy River's dubious data to 'backzone' instead of removing them > entirely, as I worry that some users will want the appearance of > completeness no matter how illusory.

2 1

Re: [tz] Northern Ontario (Canada)
by dpatte Oct. 16, 2022

Oct. 16, 2022

My concern about these changes is that I seem to remember that some first nations in those areas did not use daylight-savings time on their reserves, and that they were real but very small 'zones', not the large zones they ended up being assumed to be. Unfortunately I have no documentation either way on this. ----- Original Message ----- From: Paul Eggert via tz [mailto:tz@iana.org] To: "Chris Walton" <crj.walton(a)gmail.com> Cc: tz(a)iana.org Sent: Sat, 15 Oct 2022 12:53:28 -0700 Subject: Re: [tz] Northern Ontario (Canada) Thank you for doing that investigative work. Proposed patch attached and installed into the tzdb development repository on GitHub. This patch follows your suggestions, except that it moves Nipigon's and Rainy River's dubious data to 'backzone' instead of removing them entirely, as I worry that some users will want the appearance of completeness no matter how illusory.

4 3

Northern Ontario (Canada)
by Chris Walton Oct. 15, 2022

Oct. 15, 2022

On January 1, 1970, the twin cities of Fort William and Port Arthur were merged to form the City of Thunder Bay. The TZ database currently shows that Thunder Bay has observed daylight saving every year from 1970 onwards with the exception of 1973. Back in July I raised some doubts on this mailing list about the 1973 data. I now have more proof that it is wrong. Somebody from the Thunder Bay Public Library was kind enough to send me two newspaper scans from 1973. Both scans are from the Chronicle Journal which has been a local Thunder Bay newspaper since 1972. *Chronicle Journal - Saturday April 28, 1973 - page 1* This page contains a slightly corny but very relevant notice titled "*Clocks Move Ahead Sunday*''. It reads: > Advancing an hour glass one hour for daylight saving time appears to pose > a problem for Pat Plachta. She knows DST begins at 2 a.m. Sunday and she'll > have one less hour to sleep in the morning but she'll make it up in the > Fall. Above the article is a picture of a woman holding an hourglass. Being that this is a Thunder Bay newspaper, the implication is that Thunder Bay did observe daylight saving in 1973. For completeness, I will also mention that the same newspaper page also contains a generic Canadian Press article titled "*Canadians Will Lose Hour Sleep*". The article briefly documents daylight saving practices across the country with no mention of any specific towns or cities. It starts out with: > OTTAWA (CP) — 12:01 a.m. becomes 1:01 a.m. in Canada Sunday. ... Clearly that first line is not entirely correct because most (but not all) of Canada was doing the switch at 2:00a.m. instead of 12:01a.m. I am not quoting the entire article here because it is not specific to Thunder Bay and there is nothing in it that we do not already know. *Chronicle Journal - Saturday October 27, 1973 - page 1* This page contains a notice titled "*Extra Sleep*". It reads: > Tonight city residents can look forward to gaining an extra hour of rest, > as Thunder Bay goes from Daylight Saving Time to Eastern Standard Time. So > don't forget to set your clocks back an hour tonight at 12:01 a.m. I will assume that 12:01 is an error; since most cities and towns in Ontario switched at 2:00a.m. Regardless, the notice provides additional proof that Thunder Bay did observe daylight saving in 1973. The TZ database entry for *America/Thunder_Bay* should be updated to include the observance of daylight saving in 1973. This change will make *America/Thunder_Bay* identical to *America/Toronto* from October 26, 1969 until present. Ultimately, *America/Thunder_Bay *could be replaced with a link. It could also be maintained in the backzone file using pre-1970 history from either Port Arthur or Fort William. Both Port Arthur and Fort William started their first experiments with daylight saving on May 2, 1908 which is not currently reflected in the *America/Thunder_Bay* data. Unfortunately I do not have a complete history for Port Arthur or Fort William however there are a couple of sources to start with: https://www.thunderbay.ca/en/inc/blog.aspx (scroll to the bottom) http://www.bayviewmagazine.com/article/2022/03/great-springing-forward-deba… Also, I would also like to see *America/Nipigon *and* America/Rainy_River* converted into link entries because I have zero faith in the current Shanks based data. America/Nipigon --> America/Toronto America/Rainy_River --> America/Winnipeg I am not convinced it is worth saving the data for either of these two questionable zones inside the backzone file. As I pointed out in July, the TZ database shows that Nipigon started daylight saving in 1974, but newspaper evidence shows it was already using daylight saving at least as far back as 1972. https://news.ourontario.ca/npl/122271/page/2 And FYI: The *America/Nipigon* and *America/Rainy_River* boundaries were removed from OpenStreetMap back in August. The *America/Toronto* boundary was restored to include most of Ontario east of 90°W. I was happy to see it done. -chris

2 1

time keeps on slipping into the future
by Bradley White Oct. 15, 2022

Oct. 15, 2022

tzfile.5 says: > After the second header and data comes a newline-enclosed, > POSIX-TZ-environment-variable-style string for use in handling > instants after the last transition time stored in the file I had imagined that the reference implementation would apply the future rule for all of the future, but I currently observe that UTC-offset changes get stuck after a while for many (but not all) zones. For example, for *"Australia/Sydney"*, whose POSIX TZ string is *"AEST-10AEDT,M10.1.0,M4.1.0/3"*, tz_localtime_rz() produces the following civil times at the given instants: 14745254399 = 2437-04-05T02:59:59+1100 14745254400 = 2437-04-05T02:00:00+1000 14760979199 = 2437-10-04T01:59:59+1000 14760979200 = 2437-10-04T03:00:00+1100 That looks good ... daylight time from the first Sunday in Oct through the first Sunday in Apr, shifting at 03:00. But once we hit 2438, the UTC offset is stuck at +1100. For example, in July we would expect to see standard time, but instead get: 14784296400 = 2438-07-01T00:00:00+1100 And it never seems to recover after that. I'm pretty sure this used to work.

2 8

Jordan DST - News
by Issam AlZawairi Oct. 11, 2022

Oct. 11, 2022

Hello, The Council of Ministers in Jordan decided Wednesday 5th October 2022, that daylight saving time (DST) will be throughout the year. Here's a link from an official news website https://en.royanews.tv/news/37769/2022-10-05 Thanks for creating a new TZ DB version. P Please consider the environment before printing this email Issam Al-Zuwairi DevOps Manager - Technology and Digital Innovation Zain Jordan [cid:image001.png@01D8D8B7.02E841A0] M: 00962797612342 T: 00962797900900 ext: 5809 E: <mailto:%7bemail%7d> issam.alzawairi(a)jo.zain.com<mailto:issam.alzawairi@jo.zain.com> www.jo.zain.com<http://www.jo.zain.com/> [cid:image002.jpg@01D8D8B7.02E841A0]

3 4

[tz-announce] 2022e release of tz code and data
by Paul Eggert via tz-announce Oct. 11, 2022

Oct. 11, 2022

The 2022e release of the tz code and data is available. This release reflects the following changes: Briefly: Jordan and Syria switch from +02/+03 with DST to year-round +03. Changes to future timestamps Jordan and Syria are abandoning the DST regime and are changing to permanent +03, so they will not fall back from +03 to +02 on 2022-10-28. (Thanks to Steffen Thorsen and Issam Al-Zuwairi.) Changes to past timestamps On 1922-01-01 Tijuana adopted standard time at 00:00, not 01:00. Changes to past time zone abbreviations and DST flags The temporary advancement of clocks in central Mexico in summer 1931 is now treated as daylight saving time, instead of as two changes to standard time. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022e.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 c4eb3fcf2fc736b7924176cf9c3f9c305c398b8b dated 2022-10-11 11:13:02 -0700 and tagged '2022e' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 7b3771bfa024d0bf445256f4d837a046eaba910ca3f2a5b4fcaf72ddd5fe34a9318a68f94ee09c0de120f3bdea41e9a16b0e82763896df8a6254ced0b454c060 tzcode2022e.tar.gz 3b63ba2662930ee13dec79290f57545d71d21d4ddb76f94498a7096edaee0b3150e501c221c4d596df6af7c1d770c211f88feb5add13c5e3bed979218b4544da tzdata2022e.tar.gz 6b316ac2d9dfe615685164accd126ee29c363fafe0d3483ac155644c5693693758e7315aa9f55c0a3e3c027d38f1125462d84a13fd424458b86f6be33f153cc7 tzdb-2022e.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNFtBIACgkQ7ZfpDmKq fjR5uxAAncvLsl0jRRUoY/5t92LNweU9UG3qTV6k3Y8GMlY6vOl3LFPM/Be9RKzr oJ6z3JNjOHTeE69Y8xWDqzcxyKiFIyJV3l9p0Pc6JiBWWmI/MOarja3PjGsw8v0C jv4pV+Qm5zObEvtIBboOsK5WE26/5zzP0mlW+zseAu9Qj2Ed9MuAB4xw7SDHlzWN k49SwPeeIrnW6z4iIx55KHZv2bn7XSytw1X5ZsVEizEzO+uNJh0/P0VfS9FCWdyY tOop5WYBzFfPfqHP4Daq1UbZF79lJS0W+7d7VFjgWq4dLI1C9B0H1LAO3TDPIHj+ lbq4RyGEuevl1pFXLQcum34tzlPfv5vrJF6elHWAzxZESRQwuUQ4ZEl3dkdU6P2l h/V9haUG8NHzFHsa+gVABqJ+HbNYeh6U8ve313PB/7kYtCG3ECQuKMouVQkTdNTE yh96FvKQcfqLGEdbLl9F4FyMAD2LVCQZsJeflBYQjXoMJWI/UDW5EJewxosx6ltG OizhQFY7VYnTSdv5PLevfaT0b+qQ5VJ7kNGdyRo+jjtReN8jt/Nr/ZOu7kgx2e2V fDtGfOdEe/3Hc2ZkxhdAP4q/mw17feiEC+ngbHhmtdvGO+Zm02lOwcfVb3vURTHf Pgb74iYpEioxMSlmeNjeHXeo2zPOsAfZDKv1jTuExEkrEZRKAZQ= =Bfnc -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNFtBMACgkQ7ZfpDmKq fjRUzxAAvpQHbranZRCN7Kf5XHR+0oQEio4zDl0ETg/dXmndWUN360JwHIcmzGQR H6XHIPihZX/iBq9R+1gzYDijRagWGJ4YgUnp9qJ9GnM2Xj7+DNkTBjuy+p5fMXU2 /tofAxlaJx4Mb1C7BDLuRc4jtU+36VxCvycwOyEYocngOapOGr/7xooTgYsT6BdR UcxdM6E+M/9PR8Mocz7PrVGyA3QanUp/tLtw6Q7s43Ch9E4W7TTX1T9tVF2b/9Ka 5PmamLEUVBpo0Ia4ofydr0W41sU4A0WRfVu9VjwikNbSJ7Vkw7hEWcgR6aH+GfCN 2ZfGq7JMPhJh3oWuNOTYx6h2ySS3EgRXo3x+4ktm2UIdublCnjzaXl45Hokuqu2F 9RzNeSDc5S1obh72SeALH3FymeeI/dUk3nNqZbM1UvxrJtICn6xcbGA5g78ItExb BOK19dLzkAo8dduBrBRFo7gZ1wB5hudJn5xeY4jsh1Q6lcnYKdWk6k7DcnirNuJG NkbvSlXq+83zxT6DpZXlCpN8qRV6crFcGSq1UUbpX2bRmkqdvmuAOwfdEjqLoH54 fMHPMBSszzaJdMyGmFM7VaJYWmH/I5mUZHQmT+XagL7ZDjGgwMNsoeCGKPBa7vLx lQZU9rwMgqWBm+LimwaZRJrXAoNgk1O+xeYvjNg4cUmiJOgy2wI= =XYNS -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNFtBQACgkQ7ZfpDmKq fjSNbQ/9FMWPzYHrbPVJH6IZjnfbz0Zc1XeZTDZLvK6BEARPy2fs7/8hWlvuSpz3 nPSIyK3gZyEyd88xSgkzpvf6AvbYRz/KN+6ntOTq1tYoxIcRcqEG8MFqDQ0ZhQuK EqzqGFZHwZbCR4iiZXxiCC7SqX7kRs/rGdXjCZPas/lUn1wkAKoG9oF0JlNCZn8e TdipevHL0AkuG2/mRHTV3r2NAQcs9MTOd0UJyA2gRBDL/BU02jhmaqm13kjsdAEl 5/K8c/o1jGpiuq5nm0fMMMtvnemdu6vWsY8rfbTl9UUKu421Ky6CZ1qVjG0jsGf9 12W5poAbnNQwqxuCCu66QIbwl6CKS3qveSaEvfKMg1OKF1Zc8B3bxVG/oXgAWNo2 jDl/RaTrUVDQC2fxIJjJTHJjwZRAeBH+J8iy3gnuZqeZUvXZLibiIeVCVUfTa5Mf 2ZwxuNcIjY05Ox4ldlAgSmy4ozzRRl8J7X5YoNKR+/H1Nc+t6pzJELCkA+cqXO6c dyBUk7imH08zy+J3EpujEJhFG1s3dunKr0TA494wT8xlXgZm0PNIjz3P4pgsWbUc IWeVvlGhlOOMaIug2JroYGM3yFiyDdcXo3olelZFqAukakQxTb8XFiJGuFtq+USg Hxn09bCLS2BCf8ut3T1TO8g8CF/rAFIASVPvpAZK4fCHOIq+Kq8= =Ttyr -----END PGP SIGNATURE-----

1 0

Re: [tz] What's your idea of a perfect date?
by dpatte Oct. 11, 2022

Oct. 11, 2022

In Canada, the official method for today is 11/10/2022, except if you are a programmer, or from Quebec, where 2022-10-11 (ISO style) is more common. But I sometimes get cheques (checks) from the USA which for today would be 10/11/2022. So here at least, we see cheques with all 3 formats. Most Canadians no longer use cheques - now I see why. US chains (Walmart) often print their receipts in the US format, but Canadian businesses generally use Canadian or ISO format. Its a huge headache if you have a small business and count your pennies on your receipts at tax time - especially if your corp year end is not Dec 31st. 'Was this receipt for last tax year or this tax year'. I personally convinced Ottawa International Airport to convert their displays to ISO format. Their original display software was setup with the USA format. ----- Original Message ----- From: Fred Gleason via tz [mailto:tz@iana.org] To: "Tz Database IANA" <tz(a)iana.org> Sent: Tue, 11 Oct 2022 11:59:10 -0400 Subject: Re: [tz] What's your idea of a perfect date? On Oct 11, 2022, at 11:40, Brooks Harris via tz <tz(a)iana.org> wrote: I once had a check from a UK client (wait, I guess it must have been a cheque?) with a date like "19-7-2015". My American bank would not accept it because the date made no sense to them. It took phone calls and a visit to the bank to sort it out. :-) Even weirder (from a strictly parochial American POV) is a convention I’ve seen in German documents from the the early/mid-twentieth century (and perhaps today?), where the year would be expressed in Roman numerals. Thus: s/19-7-1932/19-7-XXXII/. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | The nice thing about standards is that there are so many of them | | to choose from. | | | | -- Andrew S. Tanenbaum | |---------------------------------------------------------------------|

2 1

What's your idea of a perfect date?
by Brooks Harris Oct. 11, 2022

Oct. 11, 2022

5 7