Mail Archives: djgpp-workers/2000/04/14/11:16:19
On 14 Apr 2000, at 7:41, Eli Zaretskii wrote:
> [Those of you who don't read comp.os.msdos.djgpp, can find the details
> in the thread Re: "timezone problems: tm_isdst not set; strftime("%z")
> is -0000".]
>
> Summary of the thread on c.o.m.d.: timezone files in djtzn203.zip are
> broken; if you rebuild them on a native DJGPP platform, the results
> are okay. (In the meantime, I replaced djtzn203.zip on SimTel, so it
> is no longer broken.)
>
> I think I understand why the original djtzn203 was broken. DJ's Irix
> machine, where v2.03 was produced in a cross environment, defines
> time_t as a signed integral type, whereas our libc uses an unsigned
> time_t. Thus, the range of years representable on those two systems
> is different: Irix can represent years 1901-2038, whereas DJGPP
> supports years 1970-2106. When zic runs on Irix, it produces timezone
> files that are misinterpreted by our libc functions due to this
> mismatch. For example, if I use the file Israel from the original
> djtzn203, the library thinks it's year 1912 outside, and uses GMT
> offset of 2:20:40 that evidently was used when Palestine was under the
> Turks...
I'm getting broken djtzn203.zip also when building it under Linux (on
ix86 of course)
C:\DJGPP\TEST\tz>set TZ=c:/djgpp/zoneinfo/Europe/Helsinki
C:\DJGPP\TEST\tz>tztest
Fri, 14 Apr 2000 17:47:09 +5992
Fri, 14 Apr 2000 17:47:09 HMT
C:\DJGPP\TEST\tz>set TZ=c:/djgpp/zoneinfo/Europe/Riga
C:\DJGPP\TEST\tz>tztest
Fri, 14 Apr 2000 17:47:22 +0000
Fri, 14 Apr 2000 17:47:22 GMT
With new djtzn203.zip downloaded from ftp.cdrom.com:
C:\DJGPP\TEST\tz>tztest
Fri, 14 Apr 2000 17:57:58 +10800
Fri, 14 Apr 2000 17:57:58 EEST
C:\DJGPP\TEST\tz>set TZ=c:/djgpp/zoneinfo/Europe/Riga
C:\DJGPP\TEST\tz>tztest
Fri, 14 Apr 2000 17:58:05 +7200
Fri, 14 Apr 2000 17:58:05 EET
Which seems to be Ok.
>
> Solving this problem would involve hacking zic and its subroutines to
> not use the native time_t, but instead accept a command-line option
> that says how to interpret time_t. zic is linked with its own
> versions of gmtime and related functions, so this might be doable
> without major implications on the library. However, it's far from
> trivial, although volunteers are welcome, as usual ;-).
>
> A simpler bandaid would be to use the -s switch to zic: it forces zic
> to put into the timezone files only those rules which yield the same
> time_t values with both signed and unsigned time_t types. This way,
> we won't need to bother until the year 2038 ;-).
>
> Comments?
>
> P.S. Btw, strftime's %z operation has an additional bug: it prints
> "-0000" for any time zone with negative GMT offset. I fixed the bug
> in my local version and will check it into the CVS when I have time.
Andris
- Raw text -