Date: Fri, 14 Apr 2000 07:41:09 -0400 (EDT) Message-Id: <200004141141.HAA08364@indy.delorie.com> From: Eli Zaretskii To: djgpp-workers AT delorie DOT com Subject: timezone files: the solution Reply-To: djgpp-workers AT delorie DOT com [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.