Re: ls default time style

[Paul Eggert]

> From: Markus Kuhn <address@hidden>
> Date: Tue, 11 Dec 2001 14:31:50 +0000

> > What about 64 bit time_t?
> 
> I still have to actually see that on a POSIX system. Even the DEC Tru64
> operating system has 32-bit time_t,

Actually, I've heard that Tru64 has two time_t types, one 32-bit and
one 64-bit.  It's a real pain, reportedly.  I've also been told that
64-bit HP-UX has 64-bit time_t, and that many modern BSD flavors use
64-bit time_t on 64-bit hosts.  The machine that I'm typing this
message on has 64-bit time_t (64-bit Solaris 8).


> as do NFS and many other file systems, formats and protocols.

Older NFS versions only had 32-bit (unsigned) time stamps, but NFSv4
has 64-bit (signed) time stamps.  More precisely, they're 64-bit
integer second counts, plus an extra 9 decimal digits for nanosecond
resolution.  Please see Internet RFC 3010 and look for "nfstime4".

The Solaris filesystem has had 64-bit integer + nanosecond resolution
since Solaris 7 came out.

Obviously there is a conversion issue here, but the world is slowly
moving to 64-bit time_t.


> we are most likely *not* going to have 64-bit time_t on 64-bit CPUs,
> and the 2038 problem will have to be solved with windowing
> algorithms, for which at that time the Y2K-hack patents should have
> expired.

I disagree; I think much of the GNU/Linux and Unix world has already
gone to 64-bit time_t.  It's overkill perhaps, but it solves the Y2038
problem.