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:6.809 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site