[tz] time keeps on slipping into the future

[Paul Eggert]

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

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.