From: pavenis AT lanet DOT lv
To: Eli Zaretskii <eliz AT delorie DOT com>, djgpp-workers AT delorie DOT com
Date: Fri, 14 Apr 2000 18:00:28 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: timezone files: the solution
Message-ID: <38F75CBC.26889.B18BE4@localhost>
In-reply-to: <200004141141.HAA08364@indy.delorie.com>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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