Re: ls default time style

[Paul Eggert]

> cc: address@hidden
> From: Markus Kuhn <address@hidden>
> Date: Tue, 11 Dec 2001 14:58:03 +0000
> 
> Andreas Schwab wrote on 2001-12-11 14:50 UTC:
> > Both Linux/Alpha and Linux/ia64 use 64-bit time_t....
>
> In practice, I fear that you will just get in a 64-bit integer word a
> 32-bit timestamp passed in the least significant half.

I doubt it.

My experience is more with 64-bit Solaris, though.  It has had 64-bit
time_t for years -- ever since Solaris 7 came out.  The time_t values
are in the filesystems, and can be passed to the usual C library
routines.  Careful C code must now take into account the fact that
localtime() and gmtime() can fail, because with sufficiently large
64-bit time_t values, the 32-bit tm_year field would overflow.

I assume that 64-bit Linux is similar.

> Does at least GNU software do that?

The GNU applications that I help maintain will operate on such hosts,
though things get a bit tricky with huge time stamps.  For example,
GNU 'ls' will simply output the decimal time_t value for files whose
time stamps correspond to years outside the range (- 2**31 + 1900)
.. (2**31 - 1 + 1900), as localtime will fail on these time stamps.

Those years are in some sense "impossibly large" -- the Gregorian
calendar won't survive that long -- but since we're dealing with a
proleptic calendar we have to pretend that the calendar extends
indefinitely into the past and future, so the code has to do
something.

> Is there a recommended coding practice for what to do exactly when
> converting 32-bit seconds-since-the-epoch to 64-bit?

That conversion is easy: just do sign-extension, assuming the usual
case where time_t is signed.  If time_t is not signed, or if it
changes in both size and signedness, it can be a little trickier since
(time_t) -1 is a special case.

When converting from 64-bit to 32-bit time_t, system functions should
fail and set errno to EOVERFLOW if the resulting value doesn't fit.