[lkml]   [2000]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: time_t size: The year 2038 bug?
    On Wed, 5 Jan 2000, David Schwartz wrote:

    > And my answer to that is that the size of a time_t has no bearing on
    > properly-written application code. 'time_t' is an opaque type, and the only
    > thing that is safe and legal to do with it is to pass it to and from library
    > functions that take or give a 'time_t'.
    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.
    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.

    > People who write bad code will write bad code no matter how large a time_t
    > is or isn't, and then code will break. Even if you make a time_t 64-bits,
    > the people who cast it to an 'int' or write it into a 4-byte database slot
    > will still be screwed on 32-bit machines.
    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.
    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.

    Another approach is making time_t to be 32 bit unsigned int which gives
    about 70 more years. This change will not break any precompiled
    applications (before 2038 dates). It may cause compile problems with some
    programs but are detected during the compile phase and easy to fix.

    Best regards,

    Hannu Savolainen ( (Open Sound System (OSS)) (Finnish OSS pages)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.022 / U:16.852 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site