Mike Porter <mike@UDel.Edu> said:
[...]
> I've written some pretty long notes on this in the past, so I'll be
> short. This thinking is what caused the 'Y2K' problem. Most
> likely the world won't suffer too much as a result of Y2K, but
> fixing it was damn expensive, plus we all looked like idiots. I'd
> rather not look like an idiot again in 2038. Lets fix the problem
> before it turns into a crisis.
So to prevent a possible crisis in 38 years time, you want to create one
now.
Using 64 bits for time_t is done today on 64 bit CPUs
Using 64 bits for time_t on 32 bit CPUs gives extremely lame code (due in
part to infelicities in the compiler, but in large part due to the need to
synchronize access to both halves of the time on SMP), and has a _large_
performance impact on applications that use timestamps, particularly severe
on SMP machines. Such applications include databases, and much heavy-duty
networking. Exactly the kind of stuff where you want the extra horsepower.
Better wait a few years (5 should be enough, 10 more than plenty if the
past history is any guide) for 64 bits to become commonplace enough that
this cutover doesn't hurt so much. In the meantime check for 32bitness
elsewhere (I think the next crisis will be because of dusty 32bit formats
forced onto 64bit CPUs. Not so visible as y2k, but just as costly. And much
nearer than 2038).
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:18 EST