[tz] [tz-announce] 2022f release of tz code and data available
gera
tz at gera.me
Sun Oct 30 08:21:33 UTC 2022
Even Google isn't aware of this:
https://www.google.com.mx/search?q=time+in+chihuahua
I know, this has nothing to do with tzdata, but it's still a disgrace.
On 10/30/22 02:14, gera via tz wrote:
> It worked flawlessly, where applied.
>
> Unfortunately, most of the systems (even those who provide automatic
> time on Telcos) went indeed back in time, and now most of the cell
> phones are one hour behind. Even Alexa is now.
>
> 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-----
More information about the tz
mailing list