🚀 go-pugleaf

By 2038 there should be very few 32 bit systems left.  Those systems will
be a problem, however, in AIX 4.3.2 (a 64 bit OS) time_t is defined as
typedef int32long64_t and this latter typedef is wrapped in an ifdef
__64BIT_KERNEL to be signed long on a 64 bit OS and signed int otherwise.

On one of our Solaris 7 systems (largely 64 bit OS, Sun is getting to 64 bits
in several releases rather than one) time_t is defined as typedef long
without testing the kernel support.  I believe the compiler generates the
appropriate code based on compiler options and whether the actual hardware
supports 64 bits.

Support of 64 bits in the file system was introduced in Solaris 2.6.

Again, however, the major problem will be applications which make assumptions
about the values they are dealing with.  If applications assume that time is
32 bit integer rather than using the definition from the OS header files
then those applications are in trouble.  Applications which use machine
dependent time representations to store in external files or data bases
are also in trouble.

The "natural" way to store data in Unix files is in flat ASCII text files
typically using some delimiter character such as white space or whaterver.
If you store your time as the decimal number returned by, say the Perl
time function, then that value simply adds an additional digit as it
surpasses each next order of magnitude.  You can always use a year-month-day
format, however, the internal time value makes a lot of date arithmetic
trivial and it's a lot faster to convert the internal clock value to the
appropriate local time zone external format than vice versa.

In short, the Unix community planned from the start that the 32 bit clock
was not a long term solution and even now with less than half the 32 bit
epoch having passed, the evolving solution is 64 bit operating systems
which should yield a clock that will last till well after our Sun explodes
but we may have problems before the last black hole evaporates.

Interestingly, I did an experiment back when preparing a seminar on the
Unix OS and Y2K in which I set the clock to just before the 2038 overflow
time.  What happened immediately was that the keystroke repeat rate in
the windowing system went "crazy."  It appears that the X windowing system
figures out how many characters to repeat by subtracting the time that you
depress the key from the time you release the key and was confused by the
overflowed clock.  It was impossible to strike a key without having at least
three or four repeats of the key.  Once I got back to the console command
line, the system appeared to behave normally but, of course the results from
commands such as date were confused.  Actually, I think they correctly calculated
the date as some 70 years before the start of the Unix epoc (i.e. did the
arithmetic correctly if you assumed the time could be legally negative.)
What else, though, would you expect from the sort of people who wrote the
cal program which correctly prints September of 1752 omitting the 11 days
lost when the British empire converted to the Gregorian calendar.

> While it is true that "windowing" has been used in a number of fixes, I
> would point out that in 2038 there will be another big date crisis:  in
> that year, UNIX and NT and all POSIX compliant systems run out of
> time.
>
> The ANSI C time_t is defined to be an "arithmetic type" [so it cannot
> be a structure], and POSIX defines time() to return time_t and requires
> that it be the number of seconds since the Epoch, with the Epoch
> defined as starting Jan 1 1970 UTC. There is no explicit requirement
> that time_t be signed but it is in practice. As a signed value the
> counter will overflow in 2038. (I've heard that Windows 95 runs out in
> 2035 for some reason.) On many 32 bit machines, a 32 bit long *is* the
> biggest "arithmetic type" available, so there isn't anywhere to expand
> to without breaking the standards. And there will always be legacy code /
> systems of course.
>
> There simply isn't any defined way at present to write POSIX compliant
> code that is certain to survive the end of the Epoch -- there is no
> time64() call etc. Filesystems will need to be converted too, as 32 bit
> timestamps are what are stored on Unix filesystems -- imagine what a mess
> that's going to be!!
>
--
O-  J. Anthony Fitzgerald,   jaf@UNB.ca,   http://www.unb.ca/~jaf  -O