Date: Sun, 28 Aug 94 14:43:29 CDT
From: "Cave Newt" <roe2 AT midway DOT uchicago DOT edu>
To: dj AT ctron DOT com, eliz AT is DOT elta DOT co DOT il
Subject: Re: Why TZ=EST5EDT fails
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu

dj> * TZ works now, including stat.  I used the routines from V2.0 and
dj> added zoneinfo files from BSD.

Indeed, everything is now consistent, regardless of the setting of TZ
(well, I didn't use the long Posix version because I don't know the
format, but the "simple" forms work, as does no TZ at all).  It also
appears that zoneinfo is irrelevant, but none of my settings triggered
a DST correction.

The only remaining bug (that I can detect) is that "PST8PDT" is still
interpreted as "GMT0".

me> Picking the default rule [for a TZ=EST5EDT setting] to
me> be the same as if TZ=EST5 is much better than the current default of
me> pretending it's GMT0; and guessing at the dates for DST is better still

ez> I think this is not a question of what's ``much better'' but rather ``what
ez> POSIX says'' (or any other document which DJGPP should conform to).  Once
ez> again, is there anybody who knows where the definition of ctime and friends
ez> can be found, besides Unix man pages?  Or should we just take the behavior
ez> of ctime.c in the library as the de-facto standard?

I seriously doubt Posix would claim that TZ=EST5EDT (or TZ=PST8PDT) is
equivalent to TZ=GMT0.  Even if it does, the de facto standard is the 
Unix behavior, and that treats EST5EDT exactly the way it looks:  an off-
set of 5 hours from GMT during standard time, and an offset of 4 hours 
during the other half of the year (i.e., a one-hour offset for DST).  
This may very well be US-centric, but the fact remains that *this is 
the existing Unix behavior*.

Since djgpp predefines "unix" (which I would argue is wrong, too, but 
that's another topic), it seems logical that it should behave like Unix 
with respect to TZ settings of the form "xST#xDT".

ez> I don't know if this presents a problem
ez> (file moved inside archives, maybe?).  If anybody does, let him speak now.

I don't understand your point here, but transferring between Unix and
DOS systems is not a problem unless the stat() and timezone functions
are broken--that, you may recall, is how this whole thing got started,
since UnZip failed mysteriously only when compiled with djgpp.  When
everything is working as it's supposed to, the only problem is moving
archives across timezones (which unfortunately is often a problem for
an Internet-based workgroup like Info-ZIP).  Even that is only a prob-
lem because of PKWARE's adoption of DOS-format filetimes as part of
their .ZIP standard.  I would guess that newer archivers like UC2 and
HPACK (possibly even ARJ) attempt to deal with timezones rationally.

Btw, note that some buggy zmodem implementations also screw up timestamps
between Unix and MS-DOS systems.

fr> transportation methods that commonly transfer files over 
fr> timezones (e.g., FTP) should be using a standard representation of the 
fr> file's time and convert from that standard to the local representation of 
fr> time.

ftp ignores file times.  What you get is the time you transferred the 
file.

Greg Roelofs