PE>> I checked the posix standard, stat() is in there, operates on a

 PE>> filename, include  and  to
get it. The

 PE>> dates are all of type time_t, so you can use strftime() on

 PE>> them.



 BL>   Borland says the opposite about their stat struct,



I looked up the Borland library manual and had a look in the stat.h header
and all the dates returned are type time_t. It certainly looks like Borland
behaves the same was as the POSIX standard in this case.



 BL> but strftime() won't work in Unix anyway.



Errr, Bob, strftime() is an ANSI defined function and will work on any ANSI
compliant compiler *including* those under UNIX.



The bottom line is ignore the Borland manual! If it has a check mark under
ANSI and not UNIX then go ahead and use it anyway.



 BL> I've had to write my own.



Unless you're a masochist who wants to rewrite the standard library there's
really not much point rolling your own when there's a perfectly good
routine that comes standard with the compiler.



 BL>   If you just call stat() and use the struct as time_t you will get

 BL> daylight savings time for New York (that's what *I* got, anyway).



I assume you're not using the actual structure as a variable of time_t? The
three time fields in the structure are type time_t in the Borland headers.
At least they are with the version I've got (version 4.0 -- ie. fairly
old). What version of Borland C are you running anyway?



 PE>> The Posix standard further restricts time_t to be the number of

 PE>> seconds since 1970, although they don't make that clear



 BL>   I thought Borland made it pretty clear it wasn't.



According to my Borland manual, the time() function (which returns a time_t
value) "...gives the current time, in seconds, elpased since 00:00:00
GMT, January 1, 1970..."



 BL> But I can't use the time_t variable anyway, in UNIX.



Yes you can!



Why this emphasis on UNIX anyway? Are you actually running a UNIX system?





Paul



--- GoldED 2.42.G0214+