Joe Wright said:
Thanks for sticking with me so far. The Unix time_t is 32 bits
wide. The reason that it 'runs out' in 2038 is because it is
historically an int and incrementing beyond INT_MAX will be UB. When
time_t time is INT_MAX we will be at "Tue Jan 19 03:14:07 2038", 68
years and change after the Epoch.
If we would make time_t time unsigned and use the full 32 bits, we
extend the Epoch until "Sun Feb 7 06:28:15 2106", some 136 years
after the Epoch.
The Unix time_t is traditionally some integer type, with values other
than (time_t)-1 representing seconds since the epoch (1970). There is
no requirement for it to be only 32 bits, and there are plenty of Unix
and Unix-like systems today on which time_t is 64 bits (two such
systems are within arm's reach as I type this).
In my opinion, switching from signed 32-bit time_t to unsigned 32-bit
time_t would be a serious mistake. It would extend the tail end of
the range from 2038 to 2106, but at the cost of cutting off all times
prior to 1970.
64-bit systems are taking over; even 32-bit systems are capable of
manipulating 64-bit values without much trouble. We're barely more
than halfway from (time_t)0 to (time_t)2**31-1; the halfway point was
January 10, 2004. How many computer systems from 1970 are still
running? How many 32-bit systems from today will still be running in
2038? How many systems running in 2038 won't be able to use 64-bit
time_t? (I believe the answer to all three questions is "too few to
worry about".)
Remember that we're not talking about embedded systems here, or in C
standard terms, freestanding implementations. A freestanding
implementation needn't support <time.h> at all. So in effect, we're
only concerned with hosted implementations; workstations, laptops,
servers, and similar systems.
With a signed 64-bit time_t, with 1-second resolution, we have a
representable range of over 584 billion years. Plenty of systems
*already* support this, and there's more than enough time between now
and 2038 to make sure they *all* do.
Incidentally, The Open Group's specification (IEEE Std 1003.1, 2004
Edition, "POSIX") merely says:
time_t and clock_t shall be integer or real-floating types.
and that time_t is "Used for time in seconds". (I've argued against
using floating-point.)
To steer this back to topicality, *if* a future C standard specifies
the characteristis of time_t more tightly, I suggest that it should
*not* permit it to be an unsigned type.
My proposal (and I'm sure there are a lot of holes to be shot in it):
Require time_t to be a typedef for signed integer type of at least
64 bits. (Or define it in terms of a minimum required range. We
definitely want more than 136 years. We don't really need 584
billion years, but we pretty much get that range for free once we
exceed 32 bits.)
A time_t value represents the number of seconds since the epoch,
which is 1970-01-01 00:00:00 GMT. (I could be persuaded to leave
the epoch unspecified, I suppose.) Leap seconds are handled by
mounting really big rockets on the equator, ensuring that a solar
day is exactly 86400 seconds. (Don't laugh, that's probably the
easiest way to get everyone to agree.) (time_t)-1 is simply one
second before the epoch; use TIME_T_MAX or TIME_T_MIN to indicate
an error. Oh yeah, let's define TIME_T_MAX and TIME_T_MIN while
we're at it.
For precision better than 1 second, provide something like the
POSIX gettimeofday() function, which gives you a structure
containing a time_t and another integer representing microseconds
(we can make it nanoseconds, or attoseconds, or whatever).
Another possibility is to use make time_t a 64-bit signed integer
representing nanoseconds since the epoch; this gives us a range of
584 years. We can then drop the separate gettimeofday()-like
function (unless we want to support better than nanosecond
resolution).
Make sure that all the conversion and formatting functions work
correctly with *all* possible time_t values. Unless we limit
ourselves to the above-mentioned 584-year range, this means years
can be more than 4 digits. Solve the Y10K bug nearly 8000 years
early. Your descendents will thank you (or wonder why you
bothered; "we outgrew computers 7500 years ago!").
And to avoid breaking existing code, we'd have to put all this
into a new header and call the type something other than time_t.
