lkml.org 
[lkml]   [2000]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: time_t size: The year 2038 bug?
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.

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.

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.

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.

> > Problem is the same when dates are passed between two machines or between
> > a program and a dynamically linked library. Both sides need to use the
> > same size for time_t.
>
> Umm, no they don't. If _you_ decide to write a value to a file or pass it
> over a network connection, or pass it between a program and a dynamically
> linked library, _you_ have to choose the size of the object and its bit
> representation. It is programming negligence to fail to do this.
>
> If you have done this, changing a 'time_t' won't hurt you. If you haven't
> done this, nothing will save you.
Of cause I will take care about this kind of issues. However I cannot
guarantee that all the code I wrote 15 years ago is written in this way.

>
> > 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.

> > 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.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:1.713 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site