🚀 go-pugleaf

Przemek Klosowski <przemek@rrdjazz.nist.gov> writes:

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

looks pretty good to me, a few minor nits...

> I understand that Linux kernel doesn't have any year 2000 issues
                                ^ and glibc
> (dates are kept as 32-bit integers denoting the number of seconds
                    ^ signed
> 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.

no, time_t is defined as a signed integer, so it will hit in 2038 for 32
bit platforms (ie, x86).  I'm pretty sure it's a signed 64 bit on 64 bit
platforms such as alpha and sparc64, which gives you a time range
signifigantly greater than the expected age of the sun.

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

cvs 1.9 does it, this is already fixed in the current testing versions, and
a few older packages such as older versions of gnu fileutils were
vulnerable. 

> 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 :^)

also synching the time from a time server will set the OS clock correctly. 

-- 
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.res.wpi.net RH 5.0 kernel 2.0.33/2.1.89p5 i586 | at public servers
"Never make any mistaeks."
(Anonymous, in a mail discussion about to a kernel bug report.)