Date: Wed, 19 Nov 1997 14:01:28 -0700 (MST) From: Charles Mott <cmott@srv.net> To: freebsd-chat@FreeBSD.ORG Subject: Re: Tell the world about Year 2000 Compliance Message-ID: <Pine.BSF.3.96.971119133613.5181B-100000@darkstar.home> In-Reply-To: <199711191807.LAA05380@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Seriously, almost all unix programs store times/date as milliseconds
> since 1970, so they don't have a Y2K problem, but they have the Year
> 2038 problem. However, it's hoped that by the time this comes about the
> number used to store the time will be bumped to a much bigger #, making
> the problem go away.
>
> However, if that doesn't happen *OR* the programs in question aren't
> recompiled, the problem will be the same for them in 2038. However, by
> then I won't care since I'll be old and grey. :) :) :)
System time is represented in seconds after the birth of Unix, and this
value will reach the maximum positive value for a 32 bit signed integer 68
years after 1970, which is the year 2038 as you mention (I append a brief
forth calculation to confirm this).
Although I am not a personal proponent of DEC Alpha porting, moving
FreeBSD to a 64-bit architecture (Merced?), or any other word size for
that matter, will tend to improve the code base quite a bit and problems
like the 2038 bug can be fixed along the way.
Who knows, maybe FreeBSD will become an enduring edifice like Stonehenge.
Charles Mott
hex 7fffffff decimal 0 d>f .s
<stack empty> 2.147484E+09 ok
365 24 * 60 * 60 * 0 d>f .s
<stack empty> 3.1536E+07
2.147484E+09 ok
f/ .s
<stack empty> 68.09626 ok
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971119133613.5181B-100000>