Mail Archives: djgpp/1994/08/29/02:55:39
Eli Zaretskii writes:
> 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.
No, experiments don't support that claim. That may be true under Posix
(although I would have expected a required pathname or something), but
it is definitely not the case for Irix 4.x. Assuming there even *are*
any timezone files somewhere (the localtime man page says /lib/cftime,
but it doesn't exist), I can just about guarantee that there isn't any
file called "FOO8BAR". Yet that gives exactly the same result as "PST8PDT"
--and, you'll note, we're in the middle of DST, at least in the US.
("date" returned the correct time with "BAR" as the timezone name.)
> 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?
Yup, see above. I'll try this again under Linux and/or SunOS in the next
few days, as I get access to those systems and have time to experiment.
> Between DOS and Unix this should (and would) be taken care of by the
> network software.
That depends on the software, but I'll assume NFS does the Right Thing.
ftp doesn't; modem protocols sometimes (often?) don't.
> 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.
Not if they're in the same timezone, they won't. The DOS copy command
preserves the (local) timestamp. If the local time is the same and the
timezone is the same, the GMT time returned by stat() will be the same.
A floppy is no different from a standard ZIP archive in this respect.
> 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*.
Yes, that's what I said. (Strictly speaking, however, it's not quite
true: Unix PKZIP stores all three stat() times and presumably restores
them as well. I don't have a copy, however.)
> 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).
I think I made the point in an earlier message that all known DOS compilers
(with the apparent exception of old versions of Turbo C) handle timezones
correctly. There's a gray zone with respect to machines without a TZ var-
iable (MSC assumes PST8PDT, djgpp assumes EST5, emx assumes GMT0, etc.),
but the basic name-offset format is handled correctly by everybody (and
therefore by everybody's apps), and the name-offset-altname format is han-
dled correctly by everybody but djgpp.
Greg Roelofs
- Raw text -