Wrong zdump output in timezone-2021e
Hi everyone! I have encountered a strange behaviour in zdump in the latest version of timezone (timezone-2021e). Previous output of version timezone-2021a: # zdump Europe/Copenhagen -v -c 2022,2023 | grep isdst Europe/Copenhagen Sun Mar 27 00:59:59 2022 UT = Sun Mar 27 01:59:59 2022 CET isdst=0 gmtoff=3600 Europe/Copenhagen Sun Mar 27 01:00:00 2022 UT = Sun Mar 27 03:00:00 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 00:59:59 2022 UT = Sun Oct 30 02:59:59 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 01:00:00 2022 UT = Sun Oct 30 02:00:00 2022 CET isdst=0 gmtoff=3600 Current output with timezone-2021e: # zdump Europe/Copenhagen -v -c 2022,2023 | grep isdst Europe/Copenhagen -67768040609743820 = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=3020 Europe/Copenhagen -67768040609740801 = Thu Jan 1 00:50:19 -2147481748 LMT isdst=0 gmtoff=3020 Europe/Copenhagen Thu Jan 1 00:00:00 -2147481748 UT = Thu Jan 1 00:50:20 -2147481748 LMT isdst=0 gmtoff=3020 Europe/Copenhagen Sun Mar 27 00:59:59 2022 UT = Sun Mar 27 01:59:59 2022 CET isdst=0 gmtoff=3600 Europe/Copenhagen Sun Mar 27 01:00:00 2022 UT = Sun Mar 27 03:00:00 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 00:59:59 2022 UT = Sun Oct 30 02:59:59 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 01:00:00 2022 UT = Sun Oct 30 02:00:00 2022 CET isdst=0 gmtoff=3600 Europe/Copenhagen Wed Dec 31 22:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 CET isdst=0 gmtoff=3600 I consider this a bug due to the strange values printed by zdump. I have tested zdump in different distributions and they are all affected. Can you please confirm? -- Best Regards, Danilo Spinella
On 1/25/22 02:57, Danilo Spinella via tz wrote:
I consider this a bug due to the strange values printed by zdump.
Although the values look strange, they're valid boundary cases for ordinary zdump with 64-bit time_t. The difference in zdump output format was noted in the NEWS file entry for 2021b, which says "zdump -v now outputs more-useful boundary cases." So, for example, where 2021a "zdump -v Europe/Copenhagen" did not output the transition in the year 2147485547 when localtime stops working, 2021b-through-2021e zdump outputs that transition. To omit these extreme transitions you can use "zdump -V" instead of "zdump -v". There's also "zdump -i", which I use. Now that you mention it, though, the 2021b-through-2021e zdump -v format is too cryptic for these these far-past or far-future transitions. I'm attaching the attached proposed patch that will cause "zdump -v Europe/Copenhagen" to output the following five lines for the last two transitions and the maximum time_t: Europe/Copenhagen Wed Dec 31 22:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 CET isdst=0 gmtoff=3600 Europe/Copenhagen Wed Dec 31 23:00:00 2147485547 UT = 67768036191673200 (localtime failed) Europe/Copenhagen Wed Dec 31 23:59:59 2147485547 UT = 67768036191676799 (localtime failed) Europe/Copenhagen 67768036191676800 (gmtime failed) = 67768036191676800 (localtime failed) Europe/Copenhagen 9223372036854775807 (gmtime failed) = 9223372036854775807 (localtime failed) Compare to the 2021b-through-2021e output, which is harder to understand: Europe/Copenhagen Wed Dec 31 22:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 CET isdst=0 gmtoff=3600 Europe/Copenhagen Wed Dec 31 23:00:00 2147485547 UT = NULL Europe/Copenhagen Wed Dec 31 23:59:59 2147485547 UT = NULL Europe/Copenhagen 67768036191676800 = NULL Europe/Copenhagen 9223372036854775807 = NULL
participants (2)
-
Danilo Spinella -
Paul Eggert