On Thu, Oct 13, 2022 at 6:32 PM Paul Eggert <eggert@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.