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