Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: time_t size: The year 2038 bug? | Date | Fri, 7 Jan 2000 08:41:48 -0800 |
| |
> On Wed, 5 Jan 2000, David Schwartz wrote:
> > > It's not that simple. Dates are stored in zillions of files > > > and databases > > > in 32 bit format. Changing the size of time_t will break > > > these programs.
> > It will not break them, it will simply fail to fix them. If > > enlarging a > > 'time_t' breaks a program, the program was broken to begin with.
> True. This kind of program is broken. There is no doubt about it. > Programmers are human beings and and they sometimes write "wrong" code. > They have always done that, they are doing it just now and they will > continue doing it forever.
Well, that's what coding standards and managers are for.
> The problem is that there are too many programs that are broken and there > is no easy way to find them. The work required would be comparable to Y2K.
Yes, except we have 38 years to finish it. :)
> If time_t is extended it will make all those already "broken" programs to > malfunction. There is no point in breaking them now when there is still at > least 25 years time left. It's not our job to punish others just > because they have written wrong code.
Agreed. I'm not suggesting we change time_t any time soon. In fact, I'm arguing against the people suggesting that we need to modify time_t ASAP.
> I agree this problem should be fixed ASAP. However it should be done > in a way that doesn't cause completely unnecessary failures. This can be > done by introducing an alternative "right" way that can be used in all new > software.
I see your point. That would have the benefit of not breaking anything, and allowing us to easily write programs _today_ that will work past Y2.038K without a recompile.
> > > The problem is not writing any new programs properly. The > > > problem is the > > > huge amount of existing code that has been written using > > > wrong practices.
> > Right! That _application_ code needs to be fixed now. > > Before we even thing > > about fixing the system and libraries.
> We are not in position to say that others should fix all their errors > _NOW_ before upgrading to the next Linux version. There is even no > guarantee that all the errors can be fixed. It's not so easy to convert > complex data files to a new format. And what if the error is not noticed > before some program damages the file after it has been recompiled to use > new 64 bit time_t.
Right. That's why I don't think we should change 'time_t' anytime soon. But we should still write programs that correctly treat 'time_t' as an opaque type. That way, these programs can be made Y2.038K compliant with a recompile when the time comes.
> > > You cannot change the size of time_t without causing much > > > worse problems > > > than the ones expected around 2038. > > > > > > A better solution is introducing a new ltime_t type which is 64 or 128 > > > bits long. There is still at least 25 years time to (re)write all > > > applications so that they use this new type.
> > That punishes the correctly written applications.
> I would not call this punishment. If the application is correctly written > then a simple search/replace operation is enought to convert it to use the > new interface. It's even possible to write an utility that does all this > automagically. And there is even no need to do anything in near future.
Yeah, I guess I see your point. Perhaps over the next 5 years or so we can draft, implement, and deploy a new timing standard that will last us thousands of years, with new types and functions. Then we can all code to that in 2010, and we'll all be ready for 2038 without a problem.
A compile or library switch to keep those types to 32-bits on 32-bit architectures would be nice too. That way, people could write code that's Y2.038K compliant with a recompile with no performance penalty.
FWIW, there are plenty of applications today that need to process times over a larger range than 'time_t' supports. It would be nice just to have one standard set of time routines, ideally portable across platforms.
DS
- 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/
| |