> 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/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:09 EST