delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/08/29/14:28:46

To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Why TZ=EST5EDT fails
Date: Mon, 29 Aug 94 17:14:00 +0200
From: eliz AT is DOT elta DOT co DOT il

> 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).
>
> I seriously doubt Posix would claim that TZ=EST5EDT (or TZ=PST8PDT) is
> equivalent to TZ=GMT0.

No, it doesn't claim that.  EST5EDT means that there should be a file called
by that name in a suitable directory, so DST data (offset, start and end)
could be determined.  If you don't have that file, GMT0 is the default.

>                            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 

Unix ``standardly'' behaves this way, because it always has those files.
Did you try to see what happens if the file is nowhere to be found?

> 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,

Between DOS and Unix this should (and would) be taken care of by the
network software.  But what about between two DOS machines by means of
a diskette?  If you run stat() on the same (copied) file on two machines,
the time fields of stat_buf will return different.  I'm not familiar
enough with how various archive programs store time, that's why I asked
the question aloud.  But at least for PKZIP, file times are stored in
local time, so when you unzip them on another machine, that gets
interpreted as local time *on that other machine*.  In addition, we
should remember that not only DJGPP programs are used on a PC, so taking
a time value returned by stat() (which now will correctly return
GMT-relative values) and feeding it to non-DJGPP programs will cause
trouble (yes, I know it should be rare to do such crazy things, but
a limitation is a limitation is a limitation).

	Eli Zaretskii

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019