Messages in this thread | | | Subject | Re: time_t size: The year 2038 bug Summary: | Date | Tue, 11 Jan 2000 16:53:19 -0300 | From | Horst von Brand <> |
| |
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/
| |