dzone.009.clit test fails after 2021-06-28

[bmwiedemann]

While working on reproducible builds for openSUSE, I found that our dateutil 0.4.7 package tests fail soon:

FAIL: dzone.009.clit

$ dzone --prev UTC
--- "expected output  7c513e5a" 2036-02-07 16:46:30.463883626 +0000
+++ "actual output  7c513e5a"   2036-02-07 16:46:30.463883626 +0000
@@ -1 +1 @@
-never <- never UTC
+never <- 2021-06-28T00:00:27+00:00     UTC
$? 1

Why would it think that a DST change happened in the UTC zone? I tried dzone --next UTC and it said never

Interestingly, it was still passing in 2020-04-24 with the same 0.4.7 Bisected a bit and it seems, timezone-2019c was still good but timezone-2020a already makes it fail.

[bmwiedemann]

Debugged further and found that tests work again after reverting this timezone change https://github.com/eggert/tz/commit/fb434180b191ae0e8d3d17fd7442939d2b563443

Add support for Expires lines to zic zic now supports expiration dates for leap second lists.

To reproduce:

faketime 2021-06-29 dzone --prev UTC

[MeggyCal]

The problem part is:

--- timezone-2020f.orig/zic.c
+++ timezone-2020f/zic.c
@@ -3038,8 +3038,6 @@ adjleap(void)
            error(_("last Leap time does not precede Expires time"));
            exit(EXIT_FAILURE);
          }
-         if (leapexpires <= hi_time)
-           hi_time = leapexpires - 1;
        }
 }

probably along with the not ignoring of #expires 1624838400 (2021-06-28 00:00:00 UTC) line in leapseconds. The date comes from leap-seconds.list, which always contained its expiration date.

Is it possible to fix on your side, please? Or should I contact tz upstream?

[hroptatyr]

Hi Bernhard, hi MeggyCal, I'm trying to reproduce this somehow using Ubuntu's tzdata 2020f, or eggert/tz's git repo, well, to no avail.

$ ll /usr/share/zoneinfo/right/Etc/UTC
2021-01-18T13:33:07 -rw-r--r-- 1 freundt users 658 2021-01-08T16:19:33 /usr/share/zoneinfo/right/Etc/UTC
$ sha1sum /usr/share/zoneinfo/right/Etc/UTC
40af28cda3670008fbb91602b2f23982a46ad9d0  /usr/share/zoneinfo/right/Etc/UTC

same as ever, and obviously no error. Can you point me to something I can download and unpack, an rpm or something maybe?

[bmwiedemann]

I see it with http://download.opensuse.org/distribution/leap/15.2/repo/oss/x86_64/timezone-2020a-lp152.2.1.x86_64.rpm but maybe there are other contributing factors.

On the openSUSE side we track this in http://bugzilla.opensuse.org/show_bug.cgi?id=1180797

For some reason, it does not fail on Debian with the same versions.

[hroptatyr]

I see. SuSE generates zones with bloat=slim (-b slim as argument to zic). I think I have to redo the tz parser, I'm currently expecting -b fat files.

[MeggyCal]

-b slim is not the problem, the behaviour is reproducible also with -b fat (for example with this package: https://build.opensuse.org/package/binaries/openSUSE:Factory/timezone/standard). Leap 15.2 should have the "fat" timezone version already, please update.

[hroptatyr]

Using timezone-2020f-1.1.x86_64.rpm instead of the system one, the checks pass completely. And yes, they are in fat format.

[bmwiedemann]

Using timezone-2020f-1.1.x86_64.rpm instead of the system one, the checks pass completely. And yes, they are in fat format.

I can reproduce it with Factory's timezone-2020f-1.1 Did you really run checks under faketime 2021-06-29 ?

[hroptatyr]

No, that's right. I can reproduce it now (with 2020f-1.1), too, using faketime. I mean, earlier, with -b slim zones, I was able to reproduce it even without faketime.

[bmwiedemann]

I tested that 2fd968266b666f98209aaa07ca86c6439c383aef fixed this.

[MeggyCal]

Perfect! Thanks a lot to all.