Subject: Re: 1.12.maint1, second beta
To: eliz AT is DOT elta DOT co DOT il
Date: Thu, 25 Aug 1994 15:55:18 +0200 (MET DST)
From: Henrik Storner <storner AT olicom DOT dk>
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu

> Forgive me a perhaps stupid question, but how can we expect stat() under
> DOS to know about TZ? 

Because that's the way it should work. You might as well ask: How can we
expect time() to behave correctly ?

> For this to work, the OS itself should know about
> TZ and it should store files' timestamps in GMT, am I right here?

No, you're wrong. It doesn't matter how timestamps are stored, so long
as it is being done consistently: Either local time is used, or GMT is
used. DOS always uses localtime, so if you want stat() to behave like its
UNIX counterpart, a DOS-based compiler should implement a conversion from
localtime to GMT when returning timestamps in the stat structure.

OK - files created just around the time when a switch from DST occurs
may be troublesome (localtime 02:30 occurs twice in one day!), but it 
should be possible to give GMT timestamps on most files.

> > Well, I did some more investigation of the problems with the timestamps
> > returned by stat(). The problems disappears, if go32 is recompiled with
> > BC 3.1 !
> 
> Are you sure it disappears *completely*, or only for files created through
> calls to C library.  What about files created outside your test program,
> does their timestamp changes after you call tzset() like you expect?  The
> point here is, of course, that DOS itself doesn't recognize TZ (if it did,
> there would be no need to fix this in the C library, right?).

go32 uses the Turbo-C or Borland-C  version of stat() to implement the 
DJGPP version. Hence, the behaviour of stat() in DJGPP compiled programs
depend on the behaviour of the stat() function in the compiler used to
make go32.exe . Turbo-C's stat() doesn't handle timezones properly; 
Borland-C 3.1 does.

In fact, Borland's docs on the 3.1 runtime libraries mention that the TZ
environment variable should be set, and tzset() should be called, before
using ctime(), time() or ftime().

And yes, the values are correct, regardless of how the files are created.


> And while on this point, does anyone know where can I found the definition
> of how stat() should use TZ?

It isn't mentioned in my copy of K&R. ANSI must have something to say on 
this, but I don't have the standard.

All UNIX implementations that I know of return the GMT time, though.

> I am very close to finishing a substitute for stat() which eliminates
> many known problems of the current implementation, so I would like to
> make it right.  For the timestamp of the file, I just call the functions
> (mktime) from ctime.c in the library right now.  Is this enough?

My idea on a working stat() would be to get the timestamps directly from
DOS - using the directory scan functions - then converting from localtime
to GMT.
-- 
Henrik Storner        | "Man is the best computer we can put aboard a space-
(storner AT olicom DOT dk)   |  craft ... and the only one that can be mass produced 
System Engineering    |  with unskilled labor."
Olicom Denmark        |                                   Wernher von Braun