Re: [tz] iana build failures on Windows
On 4/19/21 7:09 AM, Manuela Friedrich wrote:
I had to include signal.h in zic.c to prevent the following error:
zic.c(610): error C2061: syntax error: identifier 'got_signal'
This is a portability bug recently introduced to zic.c. I installed the first attached patch to fix it.
The I needed to resolved error
zic.obj : error LNK2019: unresolved external symbol tz_time referenced in function random_dirent
This appears to be another recent portability bug. It's related to a portability problem you reported on MS-Windows in response to which in 2018d I committed a patch that introduced RESERVE_STD_EXT_IDS: https://github.com/eggert/tz/commit/24b45243c5210b4196987fdd06e6c288c358a268 When I recently added the randomish filename code to the development version, I neglected to deal with RESERVE_STD_EXT_IDS. The second attached patch should fix this issue. Please give the two patches a try, as I don't use MS-Windows and can't easily test these patches on that platform.
a test run of zdump -v produced way more output than in the last release, the Linux output seems to have become longer too, but maybe this is still under development.
That change is intentional, and was caused by this: https://github.com/eggert/tz/commit/ac07b446a3afaa4cb1ae11a91785a201c91f6351 along with some neighboring commits. Thanks for reporting the problems, and I hope the current development version of tzdb addresses the issues you mentioned.
Hello Paul, your patches compiled fine on Windows. I still would like to double check about the zdump -v output for Africa Abidjan. I am getting 1946 lines of output. Is that in the range you get on Linux? Thanks! Regards Manuela Friedrich From: Paul Eggert <eggert@cs.ucla.edu> Sent: Dienstag, 20. April 2021 08:15 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows On 4/19/21 7:09 AM, Manuela Friedrich wrote:
I had to include signal.h in zic.c to prevent the following error:
zic.c(610): error C2061: syntax error: identifier 'got_signal'
This is a portability bug recently introduced to zic.c. I installed the first attached patch to fix it.
The I needed to resolved error
zic.obj : error LNK2019: unresolved external symbol tz_time referenced in function random_dirent
This appears to be another recent portability bug. It's related to a portability problem you reported on MS-Windows in response to which in 2018d I committed a patch that introduced RESERVE_STD_EXT_IDS: https://github.com/eggert/tz/commit/24b45243c5210b4196987fdd06e6c288c358a268<https://github.com/eggert/tz/commit/24b45243c5210b4196987fdd06e6c288c358a268> When I recently added the randomish filename code to the development version, I neglected to deal with RESERVE_STD_EXT_IDS. The second attached patch should fix this issue. Please give the two patches a try, as I don't use MS-Windows and can't easily test these patches on that platform.
a test run of zdump -v produced way more output than in the last release, the Linux output seems to have become longer too, but maybe this is still under development.
That change is intentional, and was caused by this: https://github.com/eggert/tz/commit/ac07b446a3afaa4cb1ae11a91785a201c91f6351<https://github.com/eggert/tz/commit/ac07b446a3afaa4cb1ae11a91785a201c91f6351> along with some neighboring commits. Thanks for reporting the problems, and I hope the current development version of tzdb addresses the issues you mentioned.
On 4/20/21 4:57 AM, Manuela Friedrich wrote:
I still would like to double check about the zdump -v output for Africa Abidjan. I am getting 1946 lines of output. Is that in the range you get on Linux?
No, all I get is the following.
Africa/Abidjan -9223372036854775808 = NULL Africa/Abidjan -67768040609740801 = NULL Africa/Abidjan Thu Jan 1 00:00:00 -2147481748 UT = NULL Africa/Abidjan Thu Jan 1 00:16:07 -2147481748 UT = NULL Africa/Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:07 1912 UT = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:08 1912 UT = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 Africa/Abidjan Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 GMT isdst=0 gmtoff=0 Africa/Abidjan 67768036191676800 = NULL Africa/Abidjan 9223372036854775807 = NULL
So it appears that there is still some problem on MS-Windows that we haven't gotten to the bottom of. Looking at the output you sent me in earlier email (quoted below), it appears that there a problem starting at Sun Dec 31 23:59:59 1911 UT. Starting then, on your MS-Windows port for some reason zdump thinks there is a transition every second.
d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan -9223372036854775808 = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan -67768040609740801 = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:00:00 -2147481748 UT = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:07 -2147481748 UT = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Sun Dec 31 23:59:59 1911 UT = Sun Dec 31 23:43:51 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:00 1912 UT = Sun Dec 31 23:43:52 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:00 1912 UT = Sun Dec 31 23:43:52 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:01 1912 UT = Sun Dec 31 23:43:53 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:01 1912 UT = Sun Dec 31 23:43:53 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:02 1912 UT = Sun Dec 31 23:43:54 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:02 1912 UT = Sun Dec 31 23:43:54 1911 LMT isdst=0 gmtoff=-968 ...
My suspicion is that the following line in zdump.c (line 702) is the culprit somehow: && delta(&tm, &lotm) == t - lot That is, I suspect that delta(&tm, &lotm) is not equal to t - lot, even though it should be in the "transitions" that zdump is reporting incorrectly. Here, tm is the result of calling localtime on t and lotm is the result of calling localtime on lot, and in this incorrect "transitions" t = lot + 1. Perhaps you can investigate my guess with a debugger, or by inserting debugging printfs to see why zdump is going awry.
Hello Paul, I've added the tracing, please see: diff --git a/zdump.c b/zdump.c index 16e73ae..f33a925 100644 --- a/zdump.c +++ b/zdump.c @@ -696,6 +696,7 @@ hunt(timezone_t tz, char *name, time_t lot, struct tm *lotmp, time_t hit, if (t == lot) break; tm_ok = my_localtime_rz(tz, &t, &tm) != NULL; + printf("TRACING: only_ok = %d | delta(&tm,&lotm) = %d | t - lot = %d \n", only_ok, delta(&tm, &lotm), t - lot); if (lotm_ok == tm_ok && (only_ok || (lotm_ok && tm.tm_isdst == lotm.tm_isdst skipped the only_ok = 1 output TRACING: only_ok = 0 | delta(&tm,&lotm) = 22568 | t - lot = 21600 TRACING: only_ok = 0 | delta(&tm,&lotm) = 11768 | t - lot = 10800 TRACING: only_ok = 0 | delta(&tm,&lotm) = 6368 | t - lot = 5400 TRACING: only_ok = 0 | delta(&tm,&lotm) = 3668 | t - lot = 2700 TRACING: only_ok = 0 | delta(&tm,&lotm) = 2318 | t - lot = 1350 TRACING: only_ok = 0 | delta(&tm,&lotm) = 675 | t - lot = 675 TRACING: only_ok = 0 | delta(&tm,&lotm) = 337 | t - lot = 337 TRACING: only_ok = 0 | delta(&tm,&lotm) = 168 | t - lot = 168 TRACING: only_ok = 0 | delta(&tm,&lotm) = 84 | t - lot = 84 TRACING: only_ok = 0 | delta(&tm,&lotm) = 42 | t - lot = 42 TRACING: only_ok = 0 | delta(&tm,&lotm) = 21 | t - lot = 21 TRACING: only_ok = 0 | delta(&tm,&lotm) = 10 | t - lot = 10 TRACING: only_ok = 0 | delta(&tm,&lotm) = 5 | t - lot = 5 TRACING: only_ok = 0 | delta(&tm,&lotm) = 2 | t - lot = 2 TRACING: only_ok = 0 | delta(&tm,&lotm) = 1 | t - lot = 1 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Sun Dec 31 23:59:59 1911 UT = Sun Dec 31 23:43:51 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:00 1912 UT = Sun Dec 31 23:43:52 1911 LMT isdst=0 gmtoff=-968 TRACING: only_ok = 0 | delta(&tm,&lotm) = 22568 | t - lot = 21600 TRACING: only_ok = 0 | delta(&tm,&lotm) = 11768 | t - lot = 10800 TRACING: only_ok = 0 | delta(&tm,&lotm) = 6368 | t - lot = 5400 TRACING: only_ok = 0 | delta(&tm,&lotm) = 3668 | t - lot = 2700 TRACING: only_ok = 0 | delta(&tm,&lotm) = 2318 | t - lot = 1350 TRACING: only_ok = 0 | delta(&tm,&lotm) = 675 | t - lot = 675 TRACING: only_ok = 0 | delta(&tm,&lotm) = 337 | t - lot = 337 TRACING: only_ok = 0 | delta(&tm,&lotm) = 168 | t - lot = 168 TRACING: only_ok = 0 | delta(&tm,&lotm) = 84 | t - lot = 84 TRACING: only_ok = 0 | delta(&tm,&lotm) = 42 | t - lot = 42 TRACING: only_ok = 0 | delta(&tm,&lotm) = 21 | t - lot = 21 TRACING: only_ok = 0 | delta(&tm,&lotm) = 10 | t - lot = 10 TRACING: only_ok = 0 | delta(&tm,&lotm) = 5 | t - lot = 5 TRACING: only_ok = 0 | delta(&tm,&lotm) = 2 | t - lot = 2 TRACING: only_ok = 0 | delta(&tm,&lotm) = 1 | t - lot = 1 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:00 1912 UT = Sun Dec 31 23:43:52 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:01 1912 UT = Sun Dec 31 23:43:53 1911 LMT isdst=0 gmtoff=-968 .... Regards Manuela Friedrich -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Mittwoch, 21. April 2021 20:34 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows On 4/20/21 4:57 AM, Manuela Friedrich wrote:
I still would like to double check about the zdump -v output for Africa Abidjan. I am getting 1946 lines of output. Is that in the range you get on Linux?
No, all I get is the following.
Africa/Abidjan -9223372036854775808 = NULL Africa/Abidjan -67768040609740801 = NULL Africa/Abidjan Thu Jan 1 00:00:00 -2147481748 UT = NULL Africa/Abidjan Thu Jan 1 00:16:07 -2147481748 UT = NULL Africa/Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:07 1912 UT = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:08 1912 UT = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 Africa/Abidjan Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 GMT isdst=0 gmtoff=0 Africa/Abidjan 67768036191676800 = NULL Africa/Abidjan 9223372036854775807 = NULL
So it appears that there is still some problem on MS-Windows that we haven't gotten to the bottom of. Looking at the output you sent me in earlier email (quoted below), it appears that there a problem starting at Sun Dec 31 23:59:59 1911 UT. Starting then, on your MS-Windows port for some reason zdump thinks there is a transition every second.
d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan -9223372036854775808 = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan -67768040609740801 = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:00:00 -2147481748 UT = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:07 -2147481748 UT = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Sun Dec 31 23:59:59 1911 UT = Sun Dec 31 23:43:51 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:00 1912 UT = Sun Dec 31 23:43:52 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:00 1912 UT = Sun Dec 31 23:43:52 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:01 1912 UT = Sun Dec 31 23:43:53 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:01 1912 UT = Sun Dec 31 23:43:53 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:02 1912 UT = Sun Dec 31 23:43:54 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:00:02 1912 UT = Sun Dec 31 23:43:54 1911 LMT isdst=0 gmtoff=-968 ...
My suspicion is that the following line in zdump.c (line 702) is the culprit somehow: && delta(&tm, &lotm) == t - lot That is, I suspect that delta(&tm, &lotm) is not equal to t - lot, even though it should be in the "transitions" that zdump is reporting incorrectly. Here, tm is the result of calling localtime on t and lotm is the result of calling localtime on lot, and in this incorrect "transitions" t = lot + 1. Perhaps you can investigate my guess with a debugger, or by inserting debugging printfs to see why zdump is going awry.
On 4/22/21 4:44 AM, Manuela Friedrich wrote:
+ printf("TRACING: only_ok = %d | delta(&tm,&lotm) = %d | t - lot = %d \n", only_ok, delta(&tm, &lotm), t - lot);
It'd be helpful to print the contents of t, lot, tm's components, and lotm's components too. Also, delta returns intmax_t (so use %jd to print it) and t - lot is of type time_t (so use the appropriate modifier for time_t too). The output you've sent so far indicates that the binary search isn't working right, and is constantly returning the smallest possible value even when that isn't the right value. So the extra debugging output should help us track that down.
On 4/22/21 1:30 PM, Paul Eggert wrote:
It'd be helpful to print the contents of t, lot, tm's components, and lotm's components too.
More specifically, what happens if you apply the attached patch to zdump.c, and then run the command 'zdump -v Africa/Abidjan'? I get the attached output but evidently you'll get something different.
Hello Paul, please find the tracing output attached. I have only kept the first 136 lines believing it provides enough information. Regards Manu -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Freitag, 23. April 2021 03:07 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows On 4/22/21 1:30 PM, Paul Eggert wrote:
It'd be helpful to print the contents of t, lot, tm's components, and lotm's components too.
More specifically, what happens if you apply the attached patch to zdump.c, and then run the command 'zdump -v Africa/Abidjan'? I get the attached output but evidently you'll get something different.
On Apr 22, 2021, at 11:22 PM, Manuela Friedrich via tz <tz@iana.org> wrote:
please find the tracing output attached. I have only kept the first 136 lines believing it provides enough information.
...
d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan -9223372036854775808 = NULL
Is zdump linked with the rest of the tz code, or is it only linked with the Visual Studio C library? If it's only linked with the Visual Studio C library, so that the localtime() that zdump calls is the Visual Studio C library's localtime(), rather than the tz code's localtime(), then it Will Not Work for any time before January 1, 1970, 00:00:00 UTC - localtime() in the Visual Studio C library returns NULL for all such date/time values: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localtime-l...
I believe the line you are quoting is expected because the same happens in Paul's Linux output: Africa/Abidjan -9223372036854775808 = NULL We are linking the other objects into zdump.exe, see nmake output: /out:zdump.exe zdump.obj getopt.obj localtime.obj asctime.obj strftime.obj It is probably this line from tools.ini: TZDOBJSW= zdump$(O) getopt$(O) localtime$(O) asctime$(O) strftime$(O) See the ful tools.ini file: [NMAKE] !IF [ if not "%PLATFORM%" == "x64" exit /b 1 ] == 0 CFLAGSW = /Zi -DHAVE_SYS_WAIT_H=0 -DHAVE_UNISTD_H=0 -DHAVE_INTTYPES_H=0 -DHAVE_POSIX_DECLS=0 -DHAVE_LINK=0 -DHAVE_SYMLINK=0 -DHAVE_DECL_ASCTIME_R=0 -Dssize_t=__int64 -DHAVE_STRTOLL=0 -DRESERVE_STD_EXT_IDS -DSUPPRESS_TZDIR -DHAVE_TZNAME=1 -DZIC_BLOAT_DEFAULT="""fat""" !ELSE CFLAGSW = /Zi -DHAVE_SYS_WAIT_H=0 -DHAVE_UNISTD_H=0 -DHAVE_INTTYPES_H=0 -DHAVE_POSIX_DECLS=0 -DHAVE_LINK=0 -DHAVE_SYMLINK=0 -DHAVE_DECL_ASCTIME_R=0 -Dssize_t=int -DHAVE_STRTOLL=0 -DRESERVE_STD_EXT_IDS -DSUPPRESS_TZDIR -DHAVE_TZNAME=1 -DZIC_BLOAT_DEFAULT="""fat""" !ENDIF LINKW = cl $(LDFLAGS) CCW = cl /c LDLIBSW = X = .exe O = .obj PACKAGE= tzcode BUGEMAIL= tz@iana.org TZCOBJSW= zic$(O) getopt$(O) TZDOBJSW= zdump$(O) getopt$(O) localtime$(O) asctime$(O) strftime$(O) root: zic$(X) zdump$(X) version: !IF [git describe > nul 2>&1] == 0 if not exist version for /f "delims=-" %%a in ('git describe') do echo %%a > version !ELSE if not exist version echo $(VERSION) > version !ENDIF version.h: echo static char const PKGVERSION[]="($(PACKAGE)) "; >version.h for /F %%H in ('type version') do echo static char const TZVERSION[]="%%H"; >> version.h echo static char const REPORT_BUGS_TO[]="$(BUGEMAIL)"; >>version.h zic$(X): $(TZCOBJSW) $(LINKW) $(CFLAGSW) $(TZCOBJSW) /link /out:$@ zdump$(X): $(TZDOBJSW) $(LINKW) $(CFLAGSW) $(TZDOBJSW) /link /out:$@ clean_misc: del *$(O) *.out version.h clean: clean_misc del zdump$(X) zic$(X) asctime$(O): private.h tzfile.h date$(O): private.h difftime$(O): private.h localtime$(O): private.h tzfile.h strftime$(O): private.h tzfile.h zdump$(O): version.h zic$(O): private.h tzfile.h version.h getopt$(O): .c.obj: $(CCW) $*.c $(CFLAGSW) .PHONY: root Regards Manu -----Original Message----- From: Guy Harris <gharris@sonic.net> Sent: Freitag, 23. April 2021 09:38 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Paul Eggert <eggert@cs.ucla.edu>; Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: [tz] iana build failures on Windows On Apr 22, 2021, at 11:22 PM, Manuela Friedrich via tz <tz@iana.org> wrote:
please find the tracing output attached. I have only kept the first 136 lines believing it provides enough information.
...
d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan -9223372036854775808 = NULL
Is zdump linked with the rest of the tz code, or is it only linked with the Visual Studio C library? If it's only linked with the Visual Studio C library, so that the localtime() that zdump calls is the Visual Studio C library's localtime(), rather than the tz code's localtime(), then it Will Not Work for any time before January 1, 1970, 00:00:00 UTC - localtime() in the Visual Studio C library returns NULL for all such date/time values: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localtime-l...
On 2021-04-23 01:37, Guy Harris via tz wrote:
On Apr 22, 2021, at 11:22 PM, Manuela Friedrich via tz wrote:
please find the tracing output attached. I have only kept the first 136 lines believing it provides enough information.
d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan -9223372036854775808 = NULL
Is zdump linked with the rest of the tz code, or is it only linked with the Visual Studio C library?
If it's only linked with the Visual Studio C library, so that the localtime() that zdump calls is the Visual Studio C library's localtime(), rather than the tz code's localtime(), then it Will Not Work for any time before January 1, 1970, 00:00:00 UTC - localtime() in the Visual Studio C library returns NULL for all such date/time values:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localtime-l... As long as you are using 64 bit time functions, with limits from
1970-01-01 00:00:00+0000 @0 ... 3000-12-31 23:59:59+0000 @32535215999 you can work around that, using a 400 year offset to get the time within the supported range: $ date -ud '1970-01-01 00:00:00+0000 + 400 years' +@%s @12622780800 GNU date and related functions should be good between the range (and some months and days): $ date -ud '1970-01-01 00:00:00+0000 - 2147483718 years' +%c%z\ @%s -2147481748 Jan 01 Mon 00:00:00+0000 @-67768040609740800 # - 2^31+70 yr $ date -ud '1970-01-01 00:00:00+0000 + 2147481677 years' +%c%z\ @%s 2147483647 Jan 01 Tue 00:00:00+0000 @67767976201996800 # + 2^31-1971 yr -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
On 4/22/21 11:22 PM, Manuela Friedrich wrote:
please find the tracing output attached.
Thanks. Here's the first line that differs between your output (-) and mine (+): -TRACING: lotm_ok=1 tm_ok=1 only_ok=0 lot=-1830384001 t=-1830383664 tm={1911-364T23:49:28 dst=0} lotm={1911-364T23:43:51 dst=0} delta=337 t-lot=337 +TRACING: lotm_ok=1 tm_ok=1 only_ok=0 lot=-1830383326 t=-1830382989 tm={1912-000T00:16:51 dst=0} lotm={1911-364T23:55:06 dst=0} delta=1305 t-lot=337 This difference suggests that for TZ=Africa/Abidjan and the timestamp -1830383495, tzdb's localtime behaves differently on your platform than on mine, although the two platforms agree on -1830384001 and on -1830382989 (the point of disagreement is halfway between the two points of agreement). localtime should convert this timestamp to 1911-12-31 23:52:17 -00:16:08 LMT (with no DST), but evidently it converts to something else on your platform. I see three things that could have gone wrong. First, while looking into this I noticed that relevant parts of zic.c and localtime.c rely on implementation-defined behavior when shifting or converting negative integers. Although I doubt that's your problem please try the latest GitHub tzdb development version, which has these fixes I installed today: https://mm.icann.org/pipermail/tz/2021-April/030025.html https://mm.icann.org/pipermail/tz/2021-April/030024.html Second, the TZif file for Africa/Abidjan could be incorrect on your platform, which would mean a portability bug in zic.c. I'm attaching my Abidjan file (it's binary data) along with Abidjan-od-t-x1.txt, the output of the shell command 'od -t x1 Africa/Abidjan' (it's a textual representation of that data). Please compare this to your Abidjan file, making sure that it's the actual Abidjan file you're using (you perhaps have multiple near-copies of that file on your system by now...). Third, there could be a problem in tzdb's localtime code. To test this, please apply the attached patch zdump-2.diff to otherwise-unmodified source code and then run 'zdump Africa/Abidjan' (without the '-v'). The output I get is also attached as zdump-2.txt; what output do you get?
Hello Paul, I rebuilt the latest git code but the zdump -v output is the same. I created Abidjan-od-t-x1-win.txt and it is indeed different from your version. Note it is the same as for the released 2021a version though. Also the 2021a zdump -v worked fine on the 2021a Abidjan file. Your zdump-2.diff produced the same result for me, see zdump-2-win.txt. Regards Manuela Friedrich -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Samstag, 24. April 2021 08:09 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows On 4/22/21 11:22 PM, Manuela Friedrich wrote:
please find the tracing output attached.
Thanks. Here's the first line that differs between your output (-) and mine (+): -TRACING: lotm_ok=1 tm_ok=1 only_ok=0 lot=-1830384001 t=-1830383664 tm={1911-364T23:49:28 dst=0} lotm={1911-364T23:43:51 dst=0} delta=337 t-lot=337 +TRACING: lotm_ok=1 tm_ok=1 only_ok=0 lot=-1830383326 t=-1830382989 tm={1912-000T00:16:51 dst=0} lotm={1911-364T23:55:06 dst=0} delta=1305 t-lot=337 This difference suggests that for TZ=Africa/Abidjan and the timestamp -1830383495, tzdb's localtime behaves differently on your platform than on mine, although the two platforms agree on -1830384001 and on -1830382989 (the point of disagreement is halfway between the two points of agreement). localtime should convert this timestamp to 1911-12-31 23:52:17 -00:16:08 LMT (with no DST), but evidently it converts to something else on your platform. I see three things that could have gone wrong. First, while looking into this I noticed that relevant parts of zic.c and localtime.c rely on implementation-defined behavior when shifting or converting negative integers. Although I doubt that's your problem please try the latest GitHub tzdb development version, which has these fixes I installed today: https://mm.icann.org/pipermail/tz/2021-April/030025.html https://mm.icann.org/pipermail/tz/2021-April/030024.html Second, the TZif file for Africa/Abidjan could be incorrect on your platform, which would mean a portability bug in zic.c. I'm attaching my Abidjan file (it's binary data) along with Abidjan-od-t-x1.txt, the output of the shell command 'od -t x1 Africa/Abidjan' (it's a textual representation of that data). Please compare this to your Abidjan file, making sure that it's the actual Abidjan file you're using (you perhaps have multiple near-copies of that file on your system by now...). Third, there could be a problem in tzdb's localtime code. To test this, please apply the attached patch zdump-2.diff to otherwise-unmodified source code and then run 'zdump Africa/Abidjan' (without the '-v'). The output I get is also attached as zdump-2.txt; what output do you get?
Hi all, sorry for jumping in, but could the problem depend on the build environment you are using? E.g. mingw vs. Visual Studio on Windows? Martin Am 27.04.21 um 13:02 schrieb Manuela Friedrich via tz:
Hello Paul,
I rebuilt the latest git code but the zdump -v output is the same.
I created Abidjan-od-t-x1-win.txt and it is indeed different from your version. Note it is the same as for the released 2021a version though. Also the 2021a zdump -v worked fine on the 2021a Abidjan file.
Your zdump-2.diff produced the same result for me, see zdump-2-win.txt.
Regards Manuela Friedrich
-----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Samstag, 24. April 2021 08:09 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows
On 4/22/21 11:22 PM, Manuela Friedrich wrote:
please find the tracing output attached.
Thanks. Here's the first line that differs between your output (-) and mine (+):
-TRACING: lotm_ok=1 tm_ok=1 only_ok=0 lot=-1830384001 t=-1830383664 tm={1911-364T23:49:28 dst=0} lotm={1911-364T23:43:51 dst=0} delta=337 t-lot=337 +TRACING: lotm_ok=1 tm_ok=1 only_ok=0 lot=-1830383326 t=-1830382989 tm={1912-000T00:16:51 dst=0} lotm={1911-364T23:55:06 dst=0} delta=1305 t-lot=337
This difference suggests that for TZ=Africa/Abidjan and the timestamp -1830383495, tzdb's localtime behaves differently on your platform than on mine, although the two platforms agree on -1830384001 and on -1830382989 (the point of disagreement is halfway between the two points of agreement). localtime should convert this timestamp to 1911-12-31 23:52:17 -00:16:08 LMT (with no DST), but evidently it converts to something else on your platform.
I see three things that could have gone wrong. First, while looking into this I noticed that relevant parts of zic.c and localtime.c rely on implementation-defined behavior when shifting or converting negative integers. Although I doubt that's your problem please try the latest GitHub tzdb development version, which has these fixes I installed today:
https://mm.icann.org/pipermail/tz/2021-April/030025.html https://mm.icann.org/pipermail/tz/2021-April/030024.html
Second, the TZif file for Africa/Abidjan could be incorrect on your platform, which would mean a portability bug in zic.c. I'm attaching my Abidjan file (it's binary data) along with Abidjan-od-t-x1.txt, the output of the shell command 'od -t x1 Africa/Abidjan' (it's a textual representation of that data). Please compare this to your Abidjan file, making sure that it's the actual Abidjan file you're using (you perhaps have multiple near-copies of that file on your system by now...).
Third, there could be a problem in tzdb's localtime code. To test this, please apply the attached patch zdump-2.diff to otherwise-unmodified source code and then run 'zdump Africa/Abidjan' (without the '-v'). The output I get is also attached as zdump-2.txt; what output do you get?
-- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
we are using Visual Studio 2017, which worked fine in the past -----Original Message----- From: Martin Burnicki <martin.burnicki@meinberg.de> Sent: Dienstag, 27. April 2021 15:14 To: Manuela Friedrich <Manuela.Friedrich@actian.com>; Paul Eggert <eggert@cs.ucla.edu> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: [tz] iana build failures on Windows Hi all, sorry for jumping in, but could the problem depend on the build environment you are using? E.g. mingw vs. Visual Studio on Windows? Martin Am 27.04.21 um 13:02 schrieb Manuela Friedrich via tz:
Hello Paul,
I rebuilt the latest git code but the zdump -v output is the same.
I created Abidjan-od-t-x1-win.txt and it is indeed different from your version. Note it is the same as for the released 2021a version though. Also the 2021a zdump -v worked fine on the 2021a Abidjan file.
Your zdump-2.diff produced the same result for me, see zdump-2-win.txt.
Regards Manuela Friedrich
-----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Samstag, 24. April 2021 08:09 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows
On 4/22/21 11:22 PM, Manuela Friedrich wrote:
please find the tracing output attached.
Thanks. Here's the first line that differs between your output (-) and mine (+):
-TRACING: lotm_ok=1 tm_ok=1 only_ok=0 lot=-1830384001 t=-1830383664 tm={1911-364T23:49:28 dst=0} lotm={1911-364T23:43:51 dst=0} delta=337 t-lot=337 +TRACING: lotm_ok=1 tm_ok=1 only_ok=0 lot=-1830383326 t=-1830382989 tm={1912-000T00:16:51 dst=0} lotm={1911-364T23:55:06 dst=0} delta=1305 t-lot=337
This difference suggests that for TZ=Africa/Abidjan and the timestamp -1830383495, tzdb's localtime behaves differently on your platform than on mine, although the two platforms agree on -1830384001 and on -1830382989 (the point of disagreement is halfway between the two points of agreement). localtime should convert this timestamp to 1911-12-31 23:52:17 -00:16:08 LMT (with no DST), but evidently it converts to something else on your platform.
I see three things that could have gone wrong. First, while looking into this I noticed that relevant parts of zic.c and localtime.c rely on implementation-defined behavior when shifting or converting negative integers. Although I doubt that's your problem please try the latest GitHub tzdb development version, which has these fixes I installed today:
https://mm.icann.org/pipermail/tz/2021-April/030025.html https://mm.icann.org/pipermail/tz/2021-April/030024.html
Second, the TZif file for Africa/Abidjan could be incorrect on your platform, which would mean a portability bug in zic.c. I'm attaching my Abidjan file (it's binary data) along with Abidjan-od-t-x1.txt, the output of the shell command 'od -t x1 Africa/Abidjan' (it's a textual representation of that data). Please compare this to your Abidjan file, making sure that it's the actual Abidjan file you're using (you perhaps have multiple near-copies of that file on your system by now...).
Third, there could be a problem in tzdb's localtime code. To test this, please apply the attached patch zdump-2.diff to otherwise-unmodified source code and then run 'zdump Africa/Abidjan' (without the '-v'). The output I get is also attached as zdump-2.txt; what output do you get?
-- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
Hmm, it looks like my previous diagnosis was incorrect. Perhaps the problem is with the abbreviations, not the offsets. Please try the attached zdump-test.diff patch instead (this is against the current development commit a16541786b0d8c9746de8ed558c861550fdc3bc3 dated Apr 26 09:49:29 2021 -0700). What is your output of 'zdump -v Africa/Abidjan' with this patch? My output zdump-Abidjan.txt is attached for comparison.
Hi Paul, thanks for your help, the new tracing seems to reveal a diff in the abbreviations. Regards Manu -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Montag, 3. Mai 2021 20:17 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows Hmm, it looks like my previous diagnosis was incorrect. Perhaps the problem is with the abbreviations, not the offsets. Please try the attached zdump-test.diff patch instead (this is against the current development commit a16541786b0d8c9746de8ed558c861550fdc3bc3 dated Apr 26 09:49:29 2021 -0700). What is your output of 'zdump -v Africa/Abidjan' with this patch? My output zdump-Abidjan.txt is attached for comparison.
On 5/5/21 6:23 AM, Manuela Friedrich wrote:
the new tracing seems to reveal a diff in the abbreviations.
Yes, that seems to be the problem. MS-Windows's struct tm does not have a tm_zone member; localtime merely puts time zone abbreviations into a global variable tzname, a la POSIX. On platforms lacking tm_zone, zdump's recently-changed code for remembering time zone abbreviations attempted to optimize localtime calls too aggressively and got the wrong abbreviation out of tzname. I installed the attached patch into the development repository. It fixes things on Ubuntu when I compile with -DNO_TM_ZONE, which is how I reproduced the bug (NO_TM_ZONE tells zdump to pretend there's no tm_zone member). Please give it a try.
Hello Paul, with the latest code in the repository zdump -v now matches Linux: d:\devsrc\treasure_test\iana>d:\devsrc\treasure_test\iana\tmp\zdump.exe -v d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan -9223372036854775808 = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan -67768040609740801 = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:00:00 -2147481748 UT = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:07 -2147481748 UT = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:07 1912 UT = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:08 1912 UT = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 GMT isdst=0 gmtoff=0 d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan 67768036191676800 = NULL d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan 9223372036854775807 = NULL Thanks for the fix! Regards Manuela -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Mittwoch, 5. Mai 2021 20:05 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows On 5/5/21 6:23 AM, Manuela Friedrich wrote:
the new tracing seems to reveal a diff in the abbreviations.
Yes, that seems to be the problem. MS-Windows's struct tm does not have a tm_zone member; localtime merely puts time zone abbreviations into a global variable tzname, a la POSIX. On platforms lacking tm_zone, zdump's recently-changed code for remembering time zone abbreviations attempted to optimize localtime calls too aggressively and got the wrong abbreviation out of tzname. I installed the attached patch into the development repository. It fixes things on Ubuntu when I compile with -DNO_TM_ZONE, which is how I reproduced the bug (NO_TM_ZONE tells zdump to pretend there's no tm_zone member). Please give it a try.
Hello Paul, recent changes in the sources cause build failures on Windows, see: nmake /A /D /C /S makefile(828) : U1002: syntax error : invalid macro invocation '$' Stop. The related change was https://github.com/eggert/tz/commit/34c4662760df3af2ad9ec0aab5cc3ffba51dde80 Makefile - $(AWK) '/^Link/ {print $$3}' backward | LC_ALL=C sort -cu + $(AWK) '/^Link/ {printf "%.5d %s\n", g, $$3} /^$$/ {g++}' \ + backward | LC_ALL=C sort -cu Can you please recommend a fix for me to test? Thank you! Regards Manuela Friedrich
On 2022-10-28 02:03, Manuela Friedrich wrote:
Hello Paul,
recent changes in the sources cause build failures on Windows, see:
nmake /A /D /C /S makefile(828) : U1002: syntax error : invalid macro invocation '$' Stop.
The related change was https://github.com/eggert/tz/commit/34c4662760df3af2ad9ec0aab5cc3ffba51dde80
Makefile - $(AWK) '/^Link/ {print $$3}' backward | LC_ALL=C sort -cu + $(AWK) '/^Link/ {printf "%.5d %s\n", g, $$3} /^$$/ {g++}' \ + backward | LC_ALL=C sort -cu
I don't see anything wrong with those two new lines, so it appears that this is a bug in Microsoft nmake. I can't easily run nmake and so would appreciate your help in coming up with a workaround. Which version of nmake are you using? What is the value of AWK in your Makefile? What is in your environment? If you run the shell command env | grep '\$' is there anything there with a dollar sign? I ask because this sort of thing has been a problem in the past; see: https://jeffpar.github.io/kbarchive/kb/075/Q75079/ Does it work around the bug if you set 'DOLLAR = $$' in the Makefile, and then use '$(DOLLAR)' instead of '$$'? What happens if you run nmake in an otherwise-empty directory that contains the attached Makefile? Here is what I see when I run GNU Make 4.3; what output do you see? echo 'Link A B' >backward awk '/^Link/ {printf "%.5d %s\n", g, $3} /^$/ {g++}' \ backward | LC_ALL=C sort -cu Can you think of any other way to work around the nmake bug? Perhaps you can edit the attached Makefile and get it to work.
After some more searching on the net, I found this page quoting a 30-year-old Microsoft Programmers Library manual: https://www.pcjs.org/documents/books/mspl13/c/qctools/ It says, for fatal error message U1002, that "To use a dollar sign in the file, type it twice ($$) or precede it with a caret (^)." The "caret" part contradicts POSIX but sounds like the problem you ran into. The tzdb Makefile has three other instances of "^$" but they're all followed by "s" and I guess nmake doesn't mind that, though it misinterprets the definitions in question. Since you're not running the checks (which are the only rules using those other instances) we won't worry about them. Does the attached patch work around the nmake bug? If so, it may be better than my previous suggestions.
Hello Paul, Your patch works fine. Thank you! Can you release a new version with this fix since the 2022f release contains the problematic code and fails to build on Windows? Thank you! Regards Manuela Friedrich -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Samstag, 29. Oktober 2022 04:34 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows After some more searching on the net, I found this page quoting a 30-year-old Microsoft Programmers Library manual: https://www.pcjs.org/documents/books/mspl13/c/qctools/ It says, for fatal error message U1002, that "To use a dollar sign in the file, type it twice ($$) or precede it with a caret (^)." The "caret" part contradicts POSIX but sounds like the problem you ran into. The tzdb Makefile has three other instances of "^$" but they're all followed by "s" and I guess nmake doesn't mind that, though it misinterprets the definitions in question. Since you're not running the checks (which are the only rules using those other instances) we won't worry about them. Does the attached patch work around the nmake bug? If so, it may be better than my previous suggestions.
On 2022-11-01 02:04, Manuela Friedrich wrote:
Your patch works fine. Thank you! Can you release a new version with this fix since the 2022f release contains the problematic code and fails to build on Windows?
Thanks for checking. I installed the attached. This should appear in the next release. I hope we don't need a new release urgently merely due to this issue. Developers building on MS-Windows can use use GNU Make (via WSL, Chocolatey, MinGW-w64, etc.) and if nmake has a serious issue like this one I can't help but wonder whether it has other lurking issues we don't know about (plus, 'make check' is buggy even with this patch); so I might suggest GNU Make anyway. If there's some reason developers can't use GNU Make, they can use the first attached patch in the meantime; it's just one line. There's a good chance we'll need a new tzdb version reasonably soon for some more-urgent reason (Paraguay, say), so this is a temporary situation.
Hello Paul, Unfortunately we cannot move to gnu make. So the earlier you get to cut a new release the better! Thank you! Regards Manuela Friedrich -----Original Message----- From: Paul Eggert <eggert@cs.ucla.edu> Sent: Dienstag, 1. November 2022 19:21 To: Manuela Friedrich <Manuela.Friedrich@actian.com> Cc: Steven Shuriff <Steven.Shuriff@actian.com>; Time zone mailing list <tz@iana.org> Subject: Re: iana build failures on Windows On 2022-11-01 02:04, Manuela Friedrich wrote:
Your patch works fine. Thank you! Can you release a new version with this fix since the 2022f release contains the problematic code and fails to build on Windows?
Thanks for checking. I installed the attached. This should appear in the next release. I hope we don't need a new release urgently merely due to this issue. Developers building on MS-Windows can use use GNU Make (via WSL, Chocolatey, MinGW-w64, etc.) and if nmake has a serious issue like this one I can't help but wonder whether it has other lurking issues we don't know about (plus, 'make check' is buggy even with this patch); so I might suggest GNU Make anyway. If there's some reason developers can't use GNU Make, they can use the first attached patch in the meantime; it's just one line. There's a good chance we'll need a new tzdb version reasonably soon for some more-urgent reason (Paraguay, say), so this is a temporary situation.
participants (5)
-
Brian Inglis -
Guy Harris -
Manuela Friedrich -
Martin Burnicki -
Paul Eggert