Mail Archives: djgpp-workers/2000/04/14/06:53:13
[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...
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.
- Raw text -