[ILUG] Linux's 2038 Bug

[Brian Foster]

  | Date: Sat, 07 May 2005 17:53:10 +0200
  | From: Brian Foster <blf at blf.utvinternet.ie>
  | 
  |[... the 2038 CE issue ] is a very well known problem.
  |   IIRC, the rationale to the original 1988 POSIX.1 standard
  |  mentioned this, and postulated that the “solution” was the
  |  world would be 64+ bits by then  [ ... ]  I'll try to remember
  |  to check my hardcopy next week (it's at work)).   [ ... ]

 Ok, from the hardcopy POSIX.1-1988 standard (IEEE Std 1003.1-1988):

 • In the Rationale it says:
      “[ ... ]
       Note that the expression given will fail after the year 2099.
       Since the issue of an overflowing 32-bit integer occurs well
       before that time, both of these will have to be addressed in
       revisions to this standard.”

    So there you have it, an unambiguous statement dating from 1988
    that the problem was known.

 • The “expression” being referred to is from the definition of the
   term “seconds since The Epoch”:

      “[ ... ]
       If year ≥ 1970 and the value is non-negative, the value is
       related to a Coordinated Universal Time name [ seconds (tm_sec),
       minutes (tm_min), hours (tm_hour), days since January 1 of the
       year (tm_yday), and calendar year minus 1900 (tm_year) ]
       according to the expression:

         tm_sec + tm_min×60 + tm_hour×3600 + tm_yday×86400 +
           (tm_year-70)×31536000 + ((tm_year-69)/4)×86400 ”

 I had forgotten about the ≥ 3000 CE issue.

cheers!
	-blf-
-- 
Experienced (20+ yrs) kernel/software Eng: | Brian Foster   Montpellier,
 • Unix, embedded, &tc;  • Linux;  • doc;  | blf at utvinternet.ie   FRANCE
 • IDL, automated testing, process, &tc.   |  Stop E$$o (ExxonMobile)!
Résumé (CV) http://www.blf.utvinternet.ie  |     http://www.stopesso.com