🚀 go-pugleaf

Followup to:  <541zwjlq6y.fsf@rrdjazz.nist.gov>
By author:    Przemek Klosowski <przemek@rrdjazz.nist.gov>
In newsgroup: comp.os.linux.development.system

> Someone asked me about Y2K and Linux, and I wrote the enclosed 
> answer. Now they want to actually use it in some internal document,
> so I thought I'd ask around for people to review it for accuracy.
> 
> I understand that Linux kernel doesn't have any year 2000 issues
> (dates are kept as 32-bit integers denoting the number of seconds
> since 1970, so this will last without any problems until 2^31 seconds
> will pass on 03:14:08 GMT, Tue Jan 19, 2038, even for software that
> incorrectly interprets the date as signed integer.  For correctly
> written software it will be yr. 2106 when the date will overflow.

Incorrect.  time_t is *PROPERLY* signed; negative time_t's refer to
dates before Jan 1, 1970 00:00:00 UTC.  Interpreting time_t's as
unsigned is a bug.  We should have migrated to a 64-bit time_t long
before 2038; a 64-bit time_t can represent times on a cosmological
scale.

> Applications rarely use the 2-digit format; I personally don't know of
> any that does that.

Some old versions of date and cvs have these problems; the up-to-date
versions don't.

> The only place where you might run into trouble is because computer
> hardware clock maintains the 2-digit date, so that loading the system
> clock on bootup from the hardware clock would result in a 1900 date in
> year 2000. This is easy to fix; simply, getting years 00 to 90 from the
> stupid hardware clock will result in adding 2000, not 1900, to the
> year, and we are good for 90 more years. Since Linux didn't exist before
> 1990, it is not going to cause problems :^)

This is correct.

	-hpa
-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah�'� -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Mis�rables