-=> Bob Jones wrote to William McBrine <=-

 BJ> More than by half.  I thought it was time_t, but I'd have to look
 BJ> again.

From the man page for time:


NAME
       time - get time in seconds

SYNOPSIS
       #include 

       time_t time(time_t *t);

DESCRIPTION
       time  returns the time since the Epoch (00:00:00 UTC, Jan-
       uary 1, 1970), measured in seconds.

       If t is non-NULL, the return value is also stored  in  the
       memory pointed to by t.

RETURN VALUE
       On  success,  the value of time in seconds since the Epoch
       is returned.  On  error,  ((time_t)-1)  is  returned,  and
       errno is set appropriately.


 BJ> There is a clock structure that has a signifcantly smaller time
 BJ> unit.

That would be this one:


NAME
       gettimeofday, settimeofday - get / set time

SYNOPSIS
       #include 

       int gettimeofday(struct timeval *tv, struct timezone *tz);
       int settimeofday(const struct timeval *tv ,  const  struct
       timezone *tz);

DESCRIPTION
       gettimeofday  and settimeofday can set the time as well as
       a timezone.  tv is a  timeval  struct,  as  specified   in
       /usr/include/sys/time.h:

       struct timeval {
               long tv_sec;        /* seconds */
               long tv_usec;  /* microseconds */
       };

       and tz is a timezone :

       struct timezone {
               int  tz_minuteswest; /* minutes W of Greenwich */
               int  tz_dsttime;     /* type of dst correction */
       };


But note that this isn't used for timestamps on files, which are only
time_t. Also note that, while time() is ANSI C, gettimeofday() isn't even
POSIX, AFAICT.

 BJ> Any 64 bit implementation isn't directly compatiable with older systems
 BJ> I'm familiar with.

Nevertheless, time_t IS 64 bits on Linux/Alpha (for example). This follows
from the definition of "long" on that system (which is the usual base type
for time_t). It still has only one-second resolution there, of course; it 
still counts seconds since the Epoch.

While it's not compatible if you're trying to read a binary struct, that's
of little import; after all, big-endian and little-endian systems aren't
compatible that way, either. If, however, you read an old _value_ into a
64-bit time_t, it's perfectly compatible.

 BJ> And (from memory) the 2038 date is with the 32 bits as unsigned.....  

Sorry, but from fact, it's signed. You can figure it out for yourself --
~2 billion (2^31) seconds from the beginning of 1970 vs. ~4 billion (2^32). 
~31.5 million (60 * 60 * 24 * 365.25) seconds a year. 2038 vs. 2106.

 BJ> I haven't looked at what DJGPP uses,

I have. It uses an unsigned 32-bit long. Which takes it to 2106 (see
above).

 BJ> but the 32 bit issue is one that's been coded in C (and it's 
 BJ> derivatives), and would be in any of the ANSI (or K&R) C compatible 
 BJ> setups....

AFAIK, no standard defines time_t as 32 bits, and certainly not as signed.
I have seen it misinterpreted that way, to be sure -- e.g., because the
error value for time() is defined as -1, some people mistakenly assume that
time_t must be signed. But that doesn't follow (as the DJGPP people
realized); because the real error value is "(time_t) -1", which works just
as well with an unsigned base type.

... Time flies like an arrow, but fruit flies like a banana.
--- MultiMail/Linux v0.44