RE: time_t size: The year 2038 bug?

From: David Schwartz (davids@webmaster.com)
Date: Wed Jan 05 2000 - 19:58:50 EST


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

        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.

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

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

        Right! That _application_ code needs to be fixed now. Before we even thing
about fixing the system and libraries.

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

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

        That's a good compromise. But I still maintain that code that relies on any
specific bit representation or size for opaque types is broken and should be
fixed.

        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:05 EST