Re: time_t size: The year 2038 bug Summary:

[Matti Aarnio]

On Sun, Jan 09, 2000 at 10:47:29AM -0800, David Schwartz wrote:
.... 
> > > 	5) Enlarge 'time_t' for newly-compiled code. Try
> > > recompiling old code. See
> > > what breaks and fix it. (Beginning around 2025.)
> 
> > This should be step 1.
> 
> 	It can't be. As soon as we enlarge 'time_t', non-compliant code will
> break. There's too much non-compliant code out there. I don't want to wait
> until all the non-compliant code is fixed to begin working on the problem.
> And I don't want to needlessly break code today that would work fine for 30+
> years.

	I don't know what IA64 time_t will be, however if DEC Alpha is
	of any model, the problem is *not* that bad.  (Alpha has 64-bit
	time_t)

	Presuming the software in next 20 years will widely be written
	in 64-bit machines (with 64-bit time_t), it will become trivial
	to change time_t in 32-bit cadgets.

	After all Linux 'jiffies' counter does overflow far sooner, and
	system seems to survive it just fine these days. (ia32)

> 	DS

/Matti Aarnio