- tz - lists.iana.org

Grouped country lists are confusing
by Stephen Colebourne Oct. 31, 2022

Oct. 31, 2022

Recent changes merged the comments acting as country headers. Thus, a typical merged header is now: # Denmark # Germany # Norway # Sweden It is very confusing to suggest that all four countries are evenly represented here, as the commentary is typically all about the primary country (Germany in this case). The alphabetical list is decidedly unhelpful too, as nothing indicates which country the Zone's city relates to. Can I propose these comments be altered to something like: # Germany # also applicable since 1970 to Denmark # also applicable since 1970 to Norway # also applicable since 1970 to Sweden thanks Stephen

4 6

[tz-announce] 2022f release of tz code and data available
by Paul Eggert via tz-announce Oct. 30, 2022

Oct. 30, 2022

The 2022f release of the tz code and data is available. This release contains the following changes. The most urgent one is the change for Chihuahua, Mexico which affects timestamps starting Sunday. Briefly: Mexico will no longer observe DST except near the US border. Chihuahua moves to year-round -06 on 2022-10-30. Fiji no longer observes DST. Move links to 'backward'. In vanguard form, GMT is now a Zone and Etc/GMT a link. zic now supports links to links, and vanguard form uses this. Simplify four Ontario zones. Fix a Y2438 bug when reading TZif data. Enable 64-bit time_t on 32-bit glibc platforms. Omit large-file support when no longer needed. In C code, use some C23 features if available. Remove no-longer-needed workaround for Qt bug 53071. Changes to future timestamps Mexico will no longer observe DST after 2022, except for areas near the US border that continue to observe US DST rules. On 2022-10-30 at 02:00 the Mexican state of Chihuahua moves from -07 (-06 with DST) to year-round -06, thus not changing its clocks that day. The new law states that Chihuahua near the US border no longer observes US DST. (Thanks to gera for the heads-up about Chihuahua.) Fiji will not observe DST in 2022/3. (Thanks to Shalvin Narayan.) For now, assume DST is suspended indefinitely. Changes to data Move links to 'backward' to ease and simplify link maintenance. This affects generated data only if you use 'make BACKWARD='. GMT is now a Zone and Etc/GMT a link instead of vice versa, as GMT is needed for leap second support whereas Etc/GMT is not. However, this change exposes a bug in TZUpdater 2.3.2 so it is present only in vanguard form for now. Vanguard form now uses links to links, as zic now supports this. Changes to past timestamps Simplify four Ontario zones, as most of the post-1970 differences seem to have been imaginary. (Problem reported by Chris Walton.) Move America/Nipigon, America/Rainy_River, and America/Thunder_Bay to 'backzone'; backward-compatibility links still work, albeit with some different timestamps before November 2005. Changes to code zic now supports links to links regardless of input line order. For example, if Australia/Sydney is a Zone, the lines Link Australia/Canberra Australia/ACT Link Australia/Sydney Australia/Canberra now work correctly, even though the shell commands ln Australia/Canberra Australia/ACT ln Australia/Sydney Australia/Canberra would fail because the first command attempts to use a link Australia/Canberra that does not exist until after the second command is executed. Previously, zic had unspecified behavior if a Link line's target was another link, and zic often misbehaved if a Link line's target was a later Link line. Fix line number in zic's diagnostic for a link to a link. Fix a bug that caused localtime to mishandle timestamps starting in the year 2438 when reading data generated by 'zic -b fat' when distant-future DST transitions occur at times given in standard time or in UT, not the usual case of local time. This occurs when the corresponding .zi Rule lines specify DST transitions with TO columns of 'max' and AT columns that end in 's' or 'u'. The number 2438 comes from the 32-bit limit in the year 2038, plus the 400-year Gregorian cycle. (Problem reported by Bradley White.) On glibc 2.34 and later, which optionally supports 64-bit time_t on platforms like x86 where time_t was traditionally 32 bits, default time_t to 64 instead of 32 bits. This lets functions like localtime support timestamps after the year 2038, and fixes year-2038 problems in zic when accessing files dated after 2038. To continue to limit time_t to 32 bits on these platforms, use "make CFLAGS='-D_TIME_BITS=32'". In C code, do not enable large-file support on platforms like AIX and macOS that no longer need it now that tzcode does not use off_t or related functions like 'stat'. Large-file support is still enabled by default on GNU/Linux, as it is needed for 64-bit time_t support. In C code, prefer C23 keywords to pre-C23 macros for alignof, bool, false, and true. Also, use the following C23 features if available: __has_include, unreachable. zic no longer works around Qt bug 53071, as the relevant Qt releases have been out of support since 2019. This change affects only fat TZif files, as thin files never had the workaround. zdump no longer modifies the environ vector when compiled on platforms lacking tm_zone or when compiled with -DUSE_LTZ=0. This avoid undefined behavior on POSIX platforms. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022f.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 d3dc2a9d65ce433555c994ce2cf84901b87d9357 dated 2022-10-28 18:04:57 -0700 and tagged '2022f' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 3e2ef91b972f1872e3e8da9eae9d1c4638bfdb32600f164484edd7147be45a116db80443cd5ae61b5c34f8b841e4362f4beefd957633f6cc9b7def543ed6752b tzcode2022f.tar.gz 72d05d05be999075cdf57b896c0f4238b1b862d4d0ed92cc611736592a4ada14d47bd7f0fc8be39e7938a7f5940a903c8af41e87859482bcfab787d889d429f6 tzdata2022f.tar.gz 1dd9f8fc3e9fa113a72010b9bceb04c7540b1175801fbd15b591a6bca9400503c6683a4c89f83e08d77f5b78624a005113a8fc428c552a2a4a2b8d26de110141 tzdb-2022f.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNcfQQACgkQ7ZfpDmKq fjS19A//fGB4YH/GygGQkql4tlshrg7ykQIQCc3qDgBrj09JVeUfM/tAN5unx+lU jBK/V5BK4K9bkrNCmxmhEdoCfdyKqusPLJSrI+ZwqqPXzNOt46dkzUxbRNYH2pvy SZklxSpgJPa4h83I8C3afGOVJn6DYpnv8SKOV6jdOOk8C6aXMaDA6t16BxN1i1Ja UKN9EQtC7xjtvtq7LtLcwo9GMy4pWoyb+CbDayG2wBq4ym3VFLxRbKupVFIDa0I7 +1pzM3Ldg2dwDKvLH8GRzirsisXbfESNVI3v1DmGnm0xDrK5pOT3iPe95OyqvMvL NdjQCpbYpoaUuo8nCf5clU4nzGEDb1sEkI6Mb8tGl2ZgG5gdC5a4P2i20vNmyIt/ uSquD7xmcBZ0CggijpFx0ndZ+0y7XSJNf7mCPaxc7vHCj5jAgQv8HLE6UXChCLeq OazZOW7xEYTDyWQ9xt2HIY1RMVBeaEE5n9V3xyfBQpb/jYeIFm83nEP5X+KjlG0Z 0YGYrVieiwS1lzNTh+LXcXusMwe6B6wYt1G4pVUgasoFADUemfd9y0yzvpdkz6/2 +WvIAF4KbGwdVHteKFR+wq9UyaSFhTUL1f9f+DsYnSbApO4F7KFzDZ3tA9IVLxfy WuOZkqjAtldzkQhoTiygF2cyGwgzWeT1WwNF6oowYYvisDf1o2E= =JtyS -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNcfQUACgkQ7ZfpDmKq fjRcIBAAhzux6C0XSQtma/RyLPGu18XmXNrFOATZ+pGxZVYEMQCbIwzS5K9yN1eD NqmcyRwI+57Kn4WHIaPcAXepcWq20yv9W30CNAZLmI6bgDlY2x2Hy+N+/TZfGWbQ FKa0gDKh/KMV5efOsgRQDm4RnM81yoJT7CV6abnaAnvUGtOzBlnsnCD5CbEUPA2s RsM/DnHISjofgfRuEyJk1oce/lji4VOaKnoR1u5omUHhOsowAZZs9AVS3dJcYdSc 58QPrwFoZjDtW5SpXV8lufgJBFEaWpDBzgvqwKyZz4SuRmezZLWedhu06iCLNedB ORkL9N5UJj2IXUD46uJGSaFgRyqtAElEzqWjgPsa2HjrTFoDlUfu2+I7HTzE+9ZN JldGwJz3P0ZGYUXldiCsV0dIgVsukcXE+8y2t3XSreTrgY+BQkipCaFz/y9vgMN+ ueudjvcTyTx9K6SCWeZ9UHLGhIPMsTgifmrTi/4Z2O8HHPROtYAF1aAMqKO0qMZ+ YEJnwsyHWDxty+3eB6NXRuvZjAIK3nTf1KUOy5zh4h0oG1/NG19eCNtzLLC3Zpt8 KLXrDPqWU2KRs3ts6l1kYTgiebb0w5iUBksMgTxwcslqYFHQfX++lov0PZOv1Mtl D46ODcN9NAHxsu+MmX9PtAotMVCyyJhhv6sFHnbqzEiA+faHVXw= =E16s -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNcfQYACgkQ7ZfpDmKq fjT9mA/8CUb7Mz5G+ih1x9HkhqMFE4W8m9C0yQfDL4s3c50HcLIUfjyue0UUejW5 t6Ahs+nkFWXd9l2d0Twp/tRuSMJSuiNkcxcL12zAFD2PmP1gjmvObup56jNlOSut RzuCjhDCcNablZUCFnPJ7RtZ3CDfB4wQlp86QsELFhRyhOEIpp+dtPbJ6rRQctMt 8E3Bdk5CvmMrtosTWMRJRDP6e3ox1Dx1idUSFwTedHaxwpFw7edVyuS6rV5i7i3G hX+9osS1fxV7uLJ7dEd78Hlg55ygn2l5iaxyl7bEWnBpRjGjeuYzir34Y7ddWoKh 2feE4z1aG8zIzXJMCnojqiyFO4Thsm1naWKwBLzIx0L3y09NOtRAL/9HYbO4f0Zi /owClbYLQSjzqaVLxFfSscFt9iIwonmQsynG3/aJuNAHQVEXhAWg5dlaEqG0pCLo mKsvg8aeu5sC68bokEZbsGzcPnmQYFTnhU9ZXYvEIrCbBUuszv7FdlSsB6Jwwhqn dadNZF5mToxUSp6YfmwTY/STvf6WJOxMuU2bxF4Bi79xptY8mO2tEre/wamwId95 Vk0aNyFD8z9PJu8Sfk5cPijJXLcGI6MEXoZlJ9Ou9l/Ybio9Ns4YH7tjHf8O10Uu 9QM3XMKKyAG2G49mYbU1lJDmcM1VGtGmS/CibmL/d1eZdNFTBqw= =Eezp -----END PGP SIGNATURE-----

5 6

checklinks.awk validation too strict
by Stephen Colebourne Oct. 30, 2022

Oct. 30, 2022

Hi, The latest version of checklinks.awk includes the following check: if (backcheck && FILENAME != backcheck && $3 != "GMT") { printf "%s: Link should be in '%s'\n", $3, backcheck status = 1 } The effect of the check is to insist that all Links are in the backward file. I understand this makes sense for TZDB's default dataset, as it now contains no Links in the main set of data files. In my opinion however it is perfectly valid to have a Link in the main set of files. This has been long-standing practice for TZDB. We know that some downstream consumers edit the source files before compiling them, so it seems highly likely that someone will still be wanting to have a Link in one of the main files. (And no, I don't think a command line option to turn it off is the right solution. If the check needs retaining there should be a "strict" mode only used by the default TZDB dataset) In summary, I think that this check should be removed since it is complaining about perfectly valid input files. thanks Stephen

2 1

Country heading for Morocco missing
by Stephen Colebourne Oct. 30, 2022

Oct. 30, 2022

I've noticed that the comment that acts as a heading for Morocco in the `africa` file is now missing. It is around line 591. I believe it was erroneously deleted. thanks Stephen

2 1

2022f and zonetab entries for Mexico
by Chris Walton Oct. 30, 2022

Oct. 30, 2022

According to 2022f, *America/Chihuahua* and *America/Ojinaga* switched from Mountain Time to Central Time. The descriptions in zone.tab and zone1970.tab still show "Mountain Time". -chris

3 5

[PROPOSED] Don’t assume nonempty argv
by Paul Eggert Oct. 29, 2022

Oct. 29, 2022

Don’t dump core if argv[0] is NULL, which is allowed on GNU/Linux if the invoker is sufficiently perverse. * zdump.c (progname): Now char const *, so that it can be given the address of a string constant. (tzalloc): Use optarg, not progname, since progname’s type is no longer correct. * zdump.c, zic.c (main): Initialize progname to non-null. --- zdump.c | 6 +++--- zic.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zdump.c b/zdump.c index 512ba8cc..f0461ade 100644 --- a/zdump.c +++ b/zdump.c @@ -84,7 +84,7 @@ static time_t const absolute_max_time = ? (((time_t) 1 << atime_shift) - 1 + ((time_t) 1 << atime_shift)) : -1); static int longest; -static char * progname; +static char const *progname; static bool warned; static bool errout; @@ -234,7 +234,7 @@ tzalloc(char const *val) exit(EXIT_FAILURE); } tzset(); - return &progname; /* Any valid non-null char ** will do. */ + return &optarg; /* Any valid non-null char ** will do. */ # else enum { TZeqlen = 3 }; static char const TZeq[TZeqlen] = "TZ="; @@ -463,7 +463,7 @@ main(int argc, char *argv[]) # endif /* defined TEXTDOMAINDIR */ textdomain(TZ_DOMAIN); #endif /* HAVE_GETTEXT */ - progname = argv[0]; + progname = argv[0] ? argv[0] : "zdump"; for (i = 1; i < argc; ++i) if (strcmp(argv[i], "--version") == 0) { printf("zdump %s%s\n", PKGVERSION, TZVERSION); diff --git a/zic.c b/zic.c index 501718f4..f3b32ecc 100644 --- a/zic.c +++ b/zic.c @@ -943,7 +943,7 @@ main(int argc, char **argv) textdomain(TZ_DOMAIN); #endif /* HAVE_GETTEXT */ main_argv = argv; - progname = argv[0]; + progname = argv[0] ? argv[0] : "zic"; if (TYPE_BIT(zic_t) < 64) { fprintf(stderr, "%s: %s\n", progname, _("wild compilation-time specification of zic_t")); -- 2.37.2

4 5

[PROPOSED] Most of Mexico will no longer observe DST
by Paul Eggert Oct. 29, 2022

Oct. 29, 2022

Also, Chihuahua moves to year-round -06. * NEWS: Mention this. * northamerica (Mexico): No DST after 2022. (America/Ojinaga, America/Chihuahua): Switch from -07 to -06 on 2022-10-30 02:00. --- NEWS | 9 +++++++++ northamerica | 20 ++++++++++++++++---- 2 files changed, 25 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index 331c1d2..5689811 100644 --- a/NEWS +++ b/NEWS @@ -3,6 +3,8 @@ News for the tz database Unreleased, experimental changes Briefly: + Mexico will no longer observe DST except near the US border. + Chihuahua moves to year-round -06 on 2022-10-30. Fiji no longer observes DST. Move links to 'backward'. In vanguard form, GMT is now a Zone and Etc/GMT a link. @@ -16,6 +18,13 @@ Unreleased, experimental changes Changes to future timestamps. + Mexico will no longer observe DST after 2022, except for areas + near the US border that continue to observe US DST rules. + On 2022-10-30 at 02:00 the Mexican state of Chihuahua moves + from -07 (-06 with DST) to year-round -06, thus not changing + its clocks that day. The new law states that Chihuahua + near the US border no longer observes US DST. + Fiji will not observe DST in 2022/3. (Thanks to Shalvin Narayan.) For now, assume DST is suspended indefinitely. diff --git a/northamerica b/northamerica index 1f16a1c..df19543 100644 --- a/northamerica +++ b/northamerica @@ -2553,6 +2553,12 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # 5- The islands, reefs and keys shall take their timezone from the # longitude they are located at. +# From Paul Eggert (2022-10-28): +# The new Mexican law was published today: +# https://www.dof.gob.mx/nota_detalle.php?codigo=5670045&fecha=28/10/2022 +# This abolishes DST except where US DST rules are observed, +# and in addition changes all of Chihuahua to -06 with no DST. + # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mexico 1931 only - May 1 23:00 1:00 D Rule Mexico 1931 only - Oct 1 0:00 0 S @@ -2568,8 +2574,8 @@ Rule Mexico 1996 2000 - Apr Sun>=1 2:00 1:00 D Rule Mexico 1996 2000 - Oct lastSun 2:00 0 S Rule Mexico 2001 only - May Sun>=1 2:00 1:00 D Rule Mexico 2001 only - Sep lastSun 2:00 0 S -Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D -Rule Mexico 2002 max - Oct lastSun 2:00 0 S +Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D +Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S # Zone NAME STDOFF RULES FORMAT [UNTIL] # Quintana Roo; represented by Cancún Zone America/Cancun -5:47:04 - LMT 1922 Jan 1 6:00u @@ -2622,7 +2628,8 @@ Zone America/Ojinaga -6:57:40 - LMT 1922 Jan 1 7:00u -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 -7:00 Mexico M%sT 2010 - -7:00 US M%sT + -7:00 US M%sT 2022 Oct 30 2:00 + -6:00 - CST # Chihuahua (away from US border) Zone America/Chihuahua -7:04:20 - LMT 1922 Jan 1 7:00u -7:00 - MST 1927 Jun 10 23:00 @@ -2631,7 +2638,8 @@ Zone America/Chihuahua -7:04:20 - LMT 1922 Jan 1 7:00u -6:00 - CST 1996 -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 - -7:00 Mexico M%sT + -7:00 Mexico M%sT 2022 Oct 30 2:00 + -6:00 - CST # Sonora Zone America/Hermosillo -7:23:52 - LMT 1922 Jan 1 7:00u -7:00 - MST 1927 Jun 10 23:00 @@ -2729,6 +2737,10 @@ Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 7:00u # http://dof.gob.mx/nota_detalle.php?codigo=5127480&fecha=06/01/2010 # It has been moved to the 'backward' file. # +# From Paul Eggert (2022-10-28): +# Today's new law states that the entire state of Baja California +# follows US DST rules, which agrees with simplifications noted above. +# # # Revillagigedo Is # no information -- 2.37.3

1 0

Daylight Savings Time in Fiji Islands
by Shalvin Narayan Oct. 28, 2022

Oct. 28, 2022

Hi Contributors, Please note that there will not be any daylight savings time change in Fiji for 2022-2023. As per current tzdata, the time is scheduled to be changed on 13 November and moved back on 15 January. However, as per the government announcement, it will not be the case and they have canceled the DST change. You can find the announcement on: https://www.facebook.com/FijianGovernment/posts/pfbid0mmWVTYmTibn66ybpFda75… Requesting if the updated tzdata package can be provided so the patch can be implemented in the system and reflected in global time and data systems. zdump -v Pacific/Fiji | grep 2022 zdump: warning: zone "Pacific/Fiji" abbreviation "+12" lacks alphabetic at start Pacific/Fiji Sat Jan 15 13:59:59 2022 UTC = Sun Jan 16 02:59:59 2022 +13 isdst=1 gmtoff=46800 Pacific/Fiji Sat Jan 15 14:00:00 2022 UTC = Sun Jan 16 02:00:00 2022 +12 isdst=0 gmtoff=43200 Pacific/Fiji Sat Nov 12 13:59:59 2022 UTC = Sun Nov 13 01:59:59 2022 +12 isdst=0 gmtoff=43200 Pacific/Fiji Sat Nov 12 14:00:00 2022 UTC = Sun Nov 13 03:00:00 2022 +13 isdst=1 gmtoff=46800 zdump -v Pacific/Fiji | grep 2023 zdump: warning: zone "Pacific/Fiji" abbreviation "+12" lacks alphabetic at start Pacific/Fiji Sat Jan 14 13:59:59 2023 UTC = Sun Jan 15 02:59:59 2023 +13 isdst=1 gmtoff=46800 Pacific/Fiji Sat Jan 14 14:00:00 2023 UTC = Sun Jan 15 02:00:00 2023 +12 isdst=0 gmtoff=43200 Pacific/Fiji Sat Nov 11 13:59:59 2023 UTC = Sun Nov 12 01:59:59 2023 +12 isdst=0 gmtoff=43200 Pacific/Fiji Sat Nov 11 14:00:00 2023 UTC = Sun Nov 12 03:00:00 2023 +13 isdst=1 gmtoff=46800 timedatectl status Local time: Wed 2022-10-26 16:19:46 +12 Universal time: Wed 2022-10-26 04:19:46 UTC RTC time: Wed 2022-10-26 04:19:47 Time zone: Pacific/Fiji (+12, +1200) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: no Last DST change: DST ended at Sun 2022-01-16 02:59:59 +13 Sun 2022-01-16 02:00:00 +12 Next DST change: DST begins (the clock jumps one hour forward) at Sun 2022-11-13 01:59:59 +12 Sun 2022-11-13 03:00:00 +13 Thanks Shalvin Narayan Head of ICT Telecom Fiji Limited [cidimage002.png(a)01D70F67.132FB220] P: (679) 321 0247 M: (679) 991 3793 This email (including any attachments) is confidential and intended solely for the use of the recipient it is addressed to. It may also be subject to legal or other professional privileges. Information contained in this email should not be copied or forwarded without the consent of the sender. If you have received this transmission in error, please notify the sender immediately and destroy and/or delete all hard and soft data relating to this transmission. Confidentiality or privilege is not waived or lost because this email has been sent to you by mistake. Telecom Fiji Limited has active anti-virus measures on its email systems but does not accept any liability in connection with any computer virus, data corruption, delay, interruption, unauthorized access, or unauthorized amendment. Any views expressed in this email are those of the individual sender, except where expressly stated to be a representation by Telecom Fiji Limited

3 3

Wrong day light savings (DST) in Syria
by MAHMAOD RADWAN Oct. 28, 2022

Oct. 28, 2022

Dear iana organization Right now in Syria government made a decision to cancel day light saving (DST) in Syria but for some reason smartphones (android and ios) devices reserve a change to it clock so the clock in the all smartphones are now late for an hour so I hope to fix this mistake and reasove the issue Note i live right now in Syria and my clock is late for an hour

4 4

[PROPOSED 1/7] Avoid undefined behavior if no Link lines
by Paul Eggert Oct. 28, 2022

Oct. 28, 2022

* zic.c (make_links): Don't call qsort(NULL, 0, ...) as this has undefined behavior in C. This fixes a bug introduced five days ago. --- zic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/zic.c b/zic.c index 78afa67..a699285 100644 --- a/zic.c +++ b/zic.c @@ -683,7 +683,8 @@ static void make_links(void) { ptrdiff_t i, j, nalinks; - qsort(links, nlinks, sizeof *links, qsort_linkcmp); + if (nlinks) + qsort(links, nlinks, sizeof *links, qsort_linkcmp); /* Ignore each link superseded by a later link with the same name. */ j = 0; -- 2.37.3

9 33

[PROPOSED] Fix recently-introduced zic infloop
by Paul Eggert Oct. 28, 2022

Oct. 28, 2022

* zic.c (make_links): Diagnose link cycles instead of looping. --- zic.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/zic.c b/zic.c index 4222869..501718f 100644 --- a/zic.c +++ b/zic.c @@ -688,7 +688,7 @@ bsearch_linkcmp(void const *key, void const *b) static void make_links(void) { - ptrdiff_t i, j, nalinks; + ptrdiff_t i, j, nalinks, pass_size; if (1 < nlinks) qsort(links, nlinks, sizeof *links, qsort_linkcmp); @@ -700,7 +700,7 @@ make_links(void) i++; links[j++] = links[i]; } - nlinks = j; + nlinks = pass_size = j; /* Walk through the link array making links. However, if a link's target has not been made yet, append a copy to the @@ -739,8 +739,22 @@ make_links(void) eat(links[i].l_filenum, links[i].l_linenum); /* If this pass examined all its links, start the next pass. */ - if (i == j) + if (i == j) { + if (nalinks - i == pass_size) { + error(_("\"Link %s %s\" is part of a link cycle"), + links[i].l_target, links[i].l_linkname); + break; + } j = nalinks; + pass_size = nalinks - i; + } + + /* Diagnose self links, which the cycle detection algorithm would not + otherwise catch. */ + if (strcmp(links[i].l_target, links[i].l_linkname) == 0) { + error(_("link %s targets itself"), links[i].l_target); + continue; + } /* Make this link unless its target has not been made yet. */ l = bsearch(links[i].l_target, &links[i + 1], j - (i + 1), -- 2.37.3

1 0

[PROPOSED 1/2] Don’t include <sys/type.h>
by Paul Eggert Oct. 27, 2022

Oct. 27, 2022

* private.h: Do not include <sys/types.h> for time_t. Including sys/types.h was added on 1989-04-10 to support pre-C89 platforms, but this is no longer needed now that we assume C89. --- private.h | 1 - 1 file changed, 1 deletion(-) diff --git a/private.h b/private.h index ffb9d48..baacdfb 100644 --- a/private.h +++ b/private.h @@ -179,7 +179,6 @@ #undef tzfree #include <stddef.h> -#include <sys/types.h> /* for time_t */ #include <string.h> #include <limits.h> /* for CHAR_BIT et al. */ #include <stdlib.h> -- 2.37.3

1 1

[PROPOSED] Fix zdump undefined behavior if !USE_LTZ
by Paul Eggert Oct. 27, 2022

Oct. 27, 2022

When compiled with -DUSE_LTZ=0, zdump modified pointers in the environ vector, which POSIX says results in undefined behavior. Fix this by using setenv if available, otherwise by arranging for the modifications to occur to the vector before it's assigned or re-assigned to ‘environ’. * Makefile, NEWS: Mention this. * private.h (HAVE_SETENV): Default to 1. * zdump.c (tzalloc): If HAVE_SETENV, just use setenv; it’s simpler. Otherwise, avoid modifying environ, environ[0], environ[0][0], etc. while environ is in use by getenv etc. Do this by keeping two independent environ vectors; the original one and fakeenv. If !HAVE_SETENV, return the initial environ array. (tzalloc, tzfree): Give the getenv family a chance of getting the correct answer, by calling tzset after each time the environment is modified. (tzfree): Restore the initial environ array. --- Makefile | 1 + NEWS | 4 ++++ private.h | 4 ++++ zdump.c | 57 ++++++++++++++++++++++++++++++++++++++----------------- 4 files changed, 49 insertions(+), 17 deletions(-) diff --git a/Makefile b/Makefile index d3cfbd0..34cec49 100644 --- a/Makefile +++ b/Makefile @@ -223,6 +223,7 @@ LDLIBS= # -DHAVE_MALLOC_ERRNO=0 if malloc etc. do not set errno on failure. # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX +# -DHAVE_SETENV=0 if your system lacks the setenv function # -DHAVE_SNPRINTF=0 if your system lacks the snprintf function # -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 diff --git a/NEWS b/NEWS index a918aed..546fe11 100644 --- a/NEWS +++ b/NEWS @@ -73,6 +73,10 @@ Unreleased, experimental changes releases have been out of support since 2019. This change affects only fat TZif files, as thin files never had the workaround. + zdump no longer modifies the environ vector when compiled on + platforms lacking tm_zone or when compiled with -DUSE_LTZ=0. + This avoid undefined behavior on POSIX platforms. + Release 2022e - 2022-10-11 11:13:02 -0700 diff --git a/private.h b/private.h index 2c7535d..ffb9d48 100644 --- a/private.h +++ b/private.h @@ -87,6 +87,10 @@ # define HAVE_POSIX_DECLS 1 #endif +#ifndef HAVE_SETENV +# define HAVE_SETENV 1 +#endif + #ifndef HAVE_STRDUP # define HAVE_STRDUP 1 #endif diff --git a/zdump.c b/zdump.c index 168f72a..ffb321a 100644 --- a/zdump.c +++ b/zdump.c @@ -228,33 +228,56 @@ mktime_z(timezone_t tz, struct tm *tmp) static timezone_t tzalloc(char const *val) { +# if HAVE_SETENV + if (setenv("TZ", val, 1) != 0) { + perror("setenv"); + exit(EXIT_FAILURE); + } + tzset(); + return NULL; +# else + enum { TZeqlen = 3 }; + static char const TZeq[TZeqlen] = "TZ="; static char **fakeenv; - char **env = fakeenv; - char *env0; - if (! env) { - char **e = environ; - int to; + static size_t fakeenv0size; + void *freeable = NULL; + char **env = fakeenv, **initial_environ; + size_t valsize = strlen(val) + 1; + if (fakeenv0size < valsize) { + char **e = environ, **to; + ptrdiff_t initial_nenvptrs; /* Counting the trailing NULL pointer. */ while (*e++) continue; - env = xmalloc(sumsize(sizeof *environ, - (e - environ) * sizeof *environ)); - to = 1; - for (e = environ; (env[to] = *e); e++) - to += strncmp(*e, "TZ=", 3) != 0; + initial_nenvptrs = e - environ; + fakeenv0size = sumsize(valsize, valsize); + fakeenv0size = max(fakeenv0size, 64); + freeable = env; + fakeenv = env = + xmalloc(sumsize(sumsize(sizeof *environ, + initial_nenvptrs * sizeof *environ), + sumsize(TZeqlen, fakeenv0size))); + to = env + 1; + for (e = environ; (*to = *e); e++) + to += strncmp(*e, TZeq, TZeqlen) != 0; + env[0] = memcpy(to + 1, TZeq, TZeqlen); } - env0 = xmalloc(sumsize(sizeof "TZ=", strlen(val))); - env[0] = strcat(strcpy(env0, "TZ="), val); - environ = fakeenv = env; + memcpy(env[0] + TZeqlen, val, valsize); + initial_environ = environ; + environ = env; tzset(); - return env; + free(freeable); + return initial_environ; +# endif } static void -tzfree(timezone_t env) +tzfree(timezone_t initial_environ) { - environ = env + 1; - free(env[0]); +# if !HAVE_SETENV + environ = initial_environ; + tzset(); +# endif } #endif /* ! USE_LOCALTIME_RZ */ -- 2.37.3

1 0

[PROPOSED 1/2] Default time_t to 64 bits on glibc 2.34+ 32-bit
by Paul Eggert Oct. 26, 2022

Oct. 26, 2022

* NEWS: Mention this. * private.h (_TIME_BITS): Default to 64. --- NEWS | 8 ++++++++ private.h | 12 ++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index bddbd3da..a918aed2 100644 --- a/NEWS +++ b/NEWS @@ -57,6 +57,14 @@ 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.) + On glibc 2.34 and later, which optionally supports 64-bit time_t + on platforms like x86 where time_t was traditionally 32 bits, + default time_t to 64 instead of 32 bits. This lets functions like + localtime support timestamps after the year 2038, and fixes + year-2038 problems in zic when accessing files dated after 2038. + To continue to limit time_t to 32 bits on these platforms, use + "make CFLAGS='-D_TIME_BITS=32'". + In C code, prefer C23 keywords to pre-C23 macros for alignof, bool, false, and true. Also, use the following C23 features if available: __has_include, unreachable. diff --git a/private.h b/private.h index c185d5f3..2c7535d8 100644 --- a/private.h +++ b/private.h @@ -127,8 +127,9 @@ /* Enable strtoimax on pre-C99 Solaris 11. */ #define __EXTENSIONS__ 1 -/* To avoid having 'stat' fail unnecessarily with errno == EOVERFLOW, - enable large files on GNUish systems ... */ +/* Although tzcode does not call 'stat'-like functions directly, stdio + functions may call them. To avoid having them fail unnecessarily + with errno == EOVERFLOW, enable large files on GNUish systems ... */ #ifndef _FILE_OFFSET_BITS # define _FILE_OFFSET_BITS 64 #endif @@ -137,6 +138,13 @@ /* ... and enable large inode numbers on Mac OS X 10.5 and later. */ #define _DARWIN_USE_64_BIT_INODE 1 +/* On GNUish systems where time_t might be 32 or 64 bits, use 64. + This supports a wider time range, and avoids having 'stat'-like + functions fail unnecessarily with errno == EOVERFLOW. */ +#ifndef _TIME_BITS +# define _TIME_BITS 64 +#endif + /* ** Nested includes */ -- 2.37.2

1 1

Re: [tz] tz Digest, Vol 133, Issue 32
by richa＠msn.com Oct. 24, 2022

Oct. 24, 2022

Once again, "All problems in computer science can be solved by another level of indirection." ________________________________ From: tz <tz-bounces(a)iana.org> on behalf of tz-request(a)iana.org <tz-request(a)iana.org> Sent: Monday, October 24, 2022 7:00 AM To: tz(a)iana.org <tz(a)iana.org> Subject: tz Digest, Vol 133, Issue 32 Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.… 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..."

1 0

[PROPOSED 1/2] zic now supports links to links
by Paul Eggert Oct. 24, 2022

Oct. 24, 2022

* NEWS, backward, zic.8: Mention this. * zic.c (make_links): New function, which supports links to later links. In this function, improve quality of warnings about links to links. (main): Use it. --- NEWS | 14 ++++++++ backward | 6 ++-- zic.8 | 29 ++++++++++++++--- zic.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++-------- 4 files changed, 126 insertions(+), 20 deletions(-) diff --git a/NEWS b/NEWS index 64a2d0c..f400d71 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,7 @@ Unreleased, experimental changes Briefly: Move links to 'backward'. In vanguard form, GMT is now a Zone and Etc/GMT a link. + zic now supports links to links. Simplify four Ontario zones into one. Fix a Y2438 bug when reading TZif data. @@ -28,6 +29,19 @@ Unreleased, experimental changes Changes to code + zic now supports links to links regardless of input line order. + For example, if Australia/Sydney is a Zone, the lines + Link Australia/Canberra Australia/ACT + Link Australia/Sydney Australia/Canberra + now work correctly, even though the shell commands + ln Australia/Canberra Australia/ACT + ln Australia/Sydney Australia/Canberra + would fail because the first command attempts to use a link + Australia/Canberra that does not exist until after the second + command is executed. Previously, zic had unspecified behavior if + a Link line's target was another link, and zic often misbehaved if + a Link line's target was a later Link line. + Fix line number in zic's diagnostic for a link to a link. Fix a bug that caused localtime to mishandle timestamps starting diff --git a/backward b/backward index 101cbc0..4c1c5d5 100644 --- a/backward +++ b/backward @@ -17,9 +17,9 @@ # backward compatibility link. Each section is sorted by link name. # A "#= TARGET1" comment labels each link inserted only because some -# .zi parsers mishandle links to links. The comment says what the -# target would be if these parsers were fixed so that data could -# contain links to links. For example, the line +# .zi parsers (including tzcode through 2022e) mishandle links to links. +# The comment says what the target would be if these parsers were fixed +# so that data could contain links to links. For example, the line # "Link Australia/Sydney Australia/ACT #= Australia/Canberra" would be # "Link Australia/Canberra Australia/ACT" were it not that data lines # refrain from linking to links like Australia/Canberra, which means diff --git a/zic.8 b/zic.8 index e46d0ab..f79148f 100644 --- a/zic.8 +++ b/zic.8 @@ -190,7 +190,10 @@ the named file rather than in the standard location. Be more verbose, and complain about the following situations: .RS .PP -The input specifies a link to a link. +The input specifies a link to a link, +something not supported by some older parsers, including +.B zic +itself through release 2022e. .PP A year that appears in a data file is outside the range of representable years. @@ -691,19 +694,37 @@ The .B TARGET field should appear as the .B NAME -field in some zone line. +field in some zone line or as the +.B LINK-NAME +field in some link line. The .B LINK-NAME field is used as an alternative name for that zone; it has the same syntax as a zone line's .B NAME field. +Links can chain together, although the behavior is unspecified if a +chain of one or more links does not terminate in a Zone name. +A link line can appear before the line that defines the link target. +For example: +.sp +.ne 3 +.nf +.in +2m +.ta \w'Zone\0\0'u +\w'Greenwich\0\0'u +Link Greenwich G_M_T +Link Etc/GMT Greenwich +Zone Etc/GMT\0\00\0\0\*-\0\0GMT +.sp +.in +.fi +The two links are chained together, and G_M_T, Greenwich, and Etc/GMT +all name the same zone. .PP Except for continuation lines, lines may appear in any order in the input. However, the behavior is unspecified if multiple zone or link lines -define the same name, or if the source of one link line is the target -of another. +define the same name. .PP The file that describes leap seconds can have leap lines and an expiration line. diff --git a/zic.c b/zic.c index 82e1a4d..78afa67 100644 --- a/zic.c +++ b/zic.c @@ -678,6 +678,89 @@ bsearch_linkcmp(void const *key, void const *b) return strcmp(key, m->l_linkname); } +/* Make the links specified by the Link lines. */ +static void +make_links(void) +{ + ptrdiff_t i, j, nalinks; + qsort(links, nlinks, sizeof *links, qsort_linkcmp); + + /* Ignore each link superseded by a later link with the same name. */ + j = 0; + for (i = 0; i < nlinks; i++) { + while (i + 1 < nlinks + && strcmp(links[i].l_linkname, links[i + 1].l_linkname) == 0) + i++; + links[j++] = links[i]; + } + nlinks = j; + + /* Walk through the link array making links. However, + if a link's target has not been made yet, append a copy to the + end of the array. The end of the array will gradually fill + up with a small sorted subsequence of not-yet-made links. + nalinks counts all the links in the array, including copies. + When we reach the copied subsequence, it may still contain + a link to a not-yet-made link, so the process repeats. + At any given point in time, the link array consists of the + following subregions, where 0 <= i <= j <= nalinks and + 0 <= nlinks <= nalinks: + + 0 .. (i - 1): + links that either have been made, or have been copied to a + later point point in the array (this later point can be in + any of the three subregions) + i .. (j - 1): + not-yet-made links for this pass + j .. (nalinks - 1): + not-yet-made links that this pass has skipped because + they were links to not-yet-made links + + The first subregion might not be sorted if nlinks < i; + the other two subregions are sorted. This algorithm does + not alter entries 0 .. (nlinks - 1), which remain sorted. + + If there are L links, this algorithm is O(C*L*log(L)) where + C is the length of the longest link chain. Usually C is + short (e.g., 3) though its worst-case value is L. */ + + j = nalinks = nlinks; + + for (i = 0; i < nalinks; i++) { + struct link *l; + + eat(links[i].l_filenum, links[i].l_linenum); + + /* If this pass examined all its links, start the next pass. */ + if (i == j) + j = nalinks; + + /* Make this link unless its target has not been made yet. */ + l = bsearch(links[i].l_target, &links[i + 1], j - (i + 1), + sizeof *links, bsearch_linkcmp); + if (!l) + l = bsearch(links[i].l_target, &links[j], nalinks - j, + sizeof *links, bsearch_linkcmp); + if (!l) + dolink(links[i].l_target, links[i].l_linkname, false); + else { + /* The link target has not been made yet; copy the link to the end. */ + links = growalloc (links, sizeof *links, nalinks, &nlinks_alloc); + links[nalinks++] = links[i]; + } + + if (noise && i < nlinks) { + if (l) + warning(_("link %s targeting link %s mishandled by pre-2023 zic"), + links[i].l_linkname, links[i].l_target); + else if (bsearch(links[i].l_target, links, nlinks, sizeof *links, + bsearch_linkcmp)) + warning(_("link %s targeting link %s"), + links[i].l_linkname, links[i].l_target); + } + } +} + /* Simple signal handling: just set a flag that is checked periodically outside critical sections. To set up the handler, prefer sigaction if available to close a signal race. */ @@ -992,19 +1075,7 @@ _("%s: invalid time range: %s\n"), continue; outzone(&zones[i], j - i); } - /* - ** Make links. - */ - if (noise) - qsort(links, nlinks, sizeof *links, qsort_linkcmp); - for (i = 0; i < nlinks; ++i) { - eat(links[i].l_filenum, links[i].l_linenum); - dolink(links[i].l_target, links[i].l_linkname, false); - if (noise - && bsearch(links[i].l_target, links, nlinks, sizeof *links, - bsearch_linkcmp)) - warning(_("link to link")); - } + make_links(); if (lcltime != NULL) { eat(COMMAND_LINE_FILENUM, 1); dolink(lcltime, tzdefault, true); -- 2.37.3

1 1

Pacific islands as identifiers
by Paul-Cathy Unger Oct. 22, 2022

Oct. 22, 2022

Hi, I was recently setting the time zone on my computer to my current location -- Honiara, Solomon Islands. In my operating system's drop-down list of "Cities" (I use a Linux distro based on Ubuntu), I could not find Honiara. I finally ended up clicking on the map approximately where I thought it would be. To my surprise, where I clicked had the label "Guadalcanal". I wasn't expecting that, and certainly wasn't looking for Guadalcanal in the list -- Honiara would have made a lot more sense to me (e.g., https://www.timeanddate.com/time/zone/solomon-islands) I'm wondering what the rationale is for using island / province names for some Pacific nations and city names for others (e.g., Apia, Samoa; Port Moresby, PNG)? And I wonder if knowing that there are historic animosities in a country between people from one island and another would be enough to consider changing an apparent favouring of one island over another? For a brief and somewhat current analysis, see https://www.csis.org/analysis/deep-roots-solomon-islands-ongoing-political-…. I offer this for your kind consideration, Paul Unger

2 1

[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