🚀 go-pugleaf

In article <19990318.084428.24081@sol.sun.csd.unb.ca>,
James Crooks  <jcrooks@vse.ca> wrote:
:Is this article's statement true for most Canadian Y2K remediation
:efforts?


|From: "Mark Gibbs" <mgibbs@gibbs.com>
|MOST Y2K FIXES WILL ONLY LAST A GENERATION

|The fix used to patch 80% of the worlds' computers to avert a Y2K crisis
|is
|actually only a short-term remedy called "windowing."

|patch is a trick that forces software to "guess" whether dates fall in
|the
|1900s or the 2000s;  typically, lower numbers (perhaps up to 30) will
|belong
|to the new century, whereas higher numbers (such as 87) will belong to
|the
|old century.


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