[tz] time keeps on slipping into the future

[Bradley White]

On Thu, Oct 13, 2022 at 6:32 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 10/13/22 14:58, Bradley White via tz wrote:
> > For example, for *"Australia/Sydney"*, whose POSIX TZ string is
> > *"AEST-10AEDT,M10.1.0,M4.1.0/3"*, tz_localtime_rz() produces the
> following
> > civil times at the given instants:
> >
> >    14745254399 = 2437-04-05T02:59:59+1100
> >    14745254400 = 2437-04-05T02:00:00+1000
> >    14760979199 = 2437-10-04T01:59:59+1000
> >    14760979200 = 2437-10-04T03:00:00+1100
> >
> > That looks good ... daylight time from the first Sunday in Oct through
> the
> > first Sunday in Apr, shifting at 03:00.  But once we hit 2438, the UTC
> > offset is stuck at +1100.  For example, in July we would expect to see
> > standard time, but instead get:
> >
> >    14784296400 = 2438-07-01T00:00:00+1100
> >
> > And it never seems to recover after that.
>
> Thanks for reporting the issue. I'm not seeing that problem when I build
> on Fedora 36 x86-64, using this command:
>
>    make TOPDIR=/tmp/tz CFLAGS='$(GCC_DEBUG_FLAGS)' -j5 install
>

Try that with ZFLAGS='-b fat' and observe the difference.

$ make TOPDIR=/tmp/tz CFLAGS='$(GCC_DEBUG_FLAGS)' ZFLAGS='-b fat' -j5
install
    :
$ /tmp/tz/usr/bin/zdump -i -c 2437,2440
/tmp/tz/usr/share/zoneinfo/Australia/Sydney

TZ="/tmp/tz/usr/share/zoneinfo/Australia/Sydney"
-       -       +11     AEDT    1
2437-04-05      02      +10     AEST
2437-10-04      03      +11     AEDT    1


> in that when I run this command:
>
>    ./zdump -i -c 2437,2440 Australia/Sydney
>
> the output is:
>
>    TZ="Australia/Sydney"
>    -    -       +11     AEDT    1
>    2437-04-05   02      +10     AEST
>    2437-10-04   03      +11     AEDT    1
>    2438-04-04   02      +10     AEST
>    2438-10-03   03      +11     AEDT    1
>    2439-04-03   02      +10     AEST
>    2439-10-02   03      +11     AEDT    1
>
> which looks OK. I get the same results if I set
> CFLAGS='$(GCC_DEBUG_FLAGS) -m32 -D_TIME_BITS=64' instead.
>
> To help debug this, it'd be nice to know the platform and a recipe for
> reproducing the problem. The existence of tz_localtime_tz indicates that
> you're using non-default CFLAGS of some sort, and this may be at issue
> here.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20221013/abd53d6b/attachment.html>