Bugzilla – Bug 1180797
timezone bug after 2021-06-28
Last modified: 2021-03-16 20:26:07 UTC
https://github.com/hroptatyr/dateutils/issues/121 Steps To Reproduce: zypper in dateutils libfaketime faketime 2021-06-29 dzone --prev UTC never <- 2021-06-28T00:00:27+00:00 UTC Somehow, this works fine on Debian. Maybe because their tzdata package has different binaries (only /usr/sbin/tzconfig) and this seems to be related to zic and leap seconds.
Debian has older version of dateutils than openSUSE: https://packages.debian.org/sid/dateutils Or maybe it could be related to the end-of-the-world January 19, 2038 The problematic commit looks mostly harmless, the most suspicious part is on leapseconds.awk (we were already facing some issues where timezone comments were falsely interpreted). But I can't find the result on my computer :( . Anyway, thanks for the report, looks interesting.
I had tested on Debian stable https://packages.debian.org/buster/dateutils is at 0.4.3
I built dateutils-0.4.3 from git on Leap 15.2 and could reproduce the bug
Thanks, I will try to experiment with it a bit.
(In reply to Markéta Machová from comment #4) > Thanks, I will try to experiment with it a bit. I am trying to create a minimal patch which fixes the issue, starting with the revert you suggested: https://build.opensuse.org/package/show/home:mcalabkova:branches:Base:System/timezone This one still fixes it, next week I will try to get rid of (or add, if you prefer) at least one of the new functions (and I hope I will find the problem part soon).
I reduced the patch to two lines: --- 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; } } Now, how to fix it without doing any real (user-facing) changes... do you have any idea?
I guess, we should involve upstream. https://www.iana.org/time-zones lists a ML for Submissions/Discussions Though, it could be that dateutils is doing something unexpected or wrong.
Looking deeper, the mentioned time comes from: timezone-2020f/leapseconds:#expires 1624838400 (2021-06-28 00:00:00 UTC) I once had a bug where there was exactly this problem, but I can't find it right now... The timezone takes the expiration data from ftp://ftp.nist.gov/pub/time/leap-seconds.list. (Now they have obsolete data upstream, the newest file expires in December 2021. But it probably does not matter now.) Yes, we could ask upstream :) but it still puzzles me why Debian does not encounter this issue.
https://github.com/eggert/tz/commit/500141665b78279e47f614dc1acfd77b845a4578 diff --git a/leap-seconds.list b/leap-seconds.list index e897a867..3198d651 100644 --- a/leap-seconds.list +++ b/leap-seconds.list @@ -204,10 +204,10 @@ # current -- the update time stamp, the data and the name of the file # will not change. # -# Updated through IERS Bulletin C60 -# File expires on: 28 June 2021 +# Updated through IERS Bulletin C61 +# File expires on: 28 December 2021 # -#@ 3833827200 +#@ 3849638400 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 @@ -252,4 +252,4 @@ # the hash line is also ignored in the # computation. # -#h 064356a8 39268b92 76e4d5ef 3e22fae1 0cca529c +#h 2ab8253d d4380d28 75f01343 381504f8 8f8a4bfc
thanks, but it does not resolve our problem, just move it a bit into the future :)
This was fixed by https://github.com/hroptatyr/dateutils/commit/2fd968266b666f98209aaa07ca86c6439c383aef, which is already in Factory.