[tz] [tz-announce] 2022f release of tz code and data available

Sun Oct 30 08:11:38 UTC 2022

It worked flawlessly, where applied.

Unfortunately, most of the systems (even those who provide automatic 
time on Telcos) went indeed back in time.

I expect havoc.

On 10/28/22 19:55, Paul Eggert via tz-announce via tz wrote:
> 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-----