Mail Archives: djgpp/1994/08/29/15:03:17
> No, experiments don't support that claim. That may be true under Posix
> (although I would have expected a required pathname or something), but
Well, I don't actually have Posix paper on this (I'm still hoping somebody
out there will tell us where it's written and how we can get at it).
What I did was look into code of ctime.c, which is from BSD.
> That depends on the software, but I'll assume NFS does the Right Thing.
> ftp doesn't; modem protocols sometimes (often?) don't.
ftp is also ok, because it ignores the original file's time and gives it
the time of download, which is, of course, local time.
>> 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.
I'm thinking precisely on the case of different timezones. E.g., I might
one day show up in your office with a diskette...
> 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.
The real world is not restricted to C programming, either. C was always
more Unix-like than other languages. But even C doesn't use timezone
when creating files: you get *local time*, not GMT stored in the directory
entry, whereas Unix stores GMT, which makes all machines consistent in their
interpretation of a given time-stamp. What I meant was that if we were
certain all programs are compiled with DJGPP, we could ``fix'' the file
creation routines, so they will store GMT times in the directory entry,
but that's of course doesn't make much sense, as other means of creating
files exist.
> There's a gray zone with respect to machines without a TZ var-
> iable (MSC assumes PST8PDT, djgpp assumes EST5, emx assumes GMT0, etc.),
Unix man page for ctime(3) says:
If TZ does not appear in the environment, the file
/etc/zoneinfo/localtime is used by localtime. If this file fails for
any reason, the Greenwich Mean Time (GMT) offset as provided by the
kernel is used. In this case, Daylight Savings Time (DST) is ignored,
resulting in the time being incorrect by some amount if DST is currently
in effect. If this fails for any reason, GMT is used.
The code in the library's ctime.c file exhibits exactly this behavior,
by calling tzsetwall() routine whenever TZ isn't there. tzsetwall()
searches for that localtime file and failing this uses GMT0. But this
fragment was disabled with #if 0 and EST5 used instead. I wrote to
DJ earlier that he should re-enable that fragment.
What the ``correct'' behavior in this case is is anybody's guess, as
long as we don't see something Posixish.
Eli Zaretskii
- Raw text -