Date: Sat, 9 Aug 1997 10:40:07 -0600 (MDT) From: Brandon Gillespie <brandon@roguetrader.com> To: Robert Chalmers <robert@chalmers.com.au> Cc: freebsd-questions <freebsd-questions@FreeBSD.ORG> Subject: Re: Year 2000 tests for PC's Message-ID: <Pine.BSF.3.96.970809103251.28696A-100000@roguetrader.com> In-Reply-To: <33EB99FB.8423F546@chalmers.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 9 Aug 1997, Robert Chalmers wrote: > Here's some tests I came across for testing your gear for Y2K > complience(or not) > > The Millennium Bug: > To determine if your PC suffers from the Millennium bug, follow these > steps > 1. Set the date to 31/12/1999 > 2. Set the time to 23:59 > 3. Turn off the PC, and wait 1 minute > 4. Turn on the PC, and check the date. > > The millennium bug occurs when the RealTimeClock year changes from 99 to > 00; those > BIOS that always add 19 will continue to do so, making the year after > 1999 1900. > Those BIOS that apply a value from CMOS fare little better, until that > extra value is > updated to 20, they to will continue adding 19 as the century code. Unix uses a 32bit integer to represent time, based off the number of seconds since 'epoch' which is defined as January 1st 1969 (I think). With this in mind, there is really no 'year 2000' bug that exists in the CORE operating system. However, people who have written bad sub programs may have the problem you describe, especially if they use 'localtime()' which will return the current year MINUS 1900. Many people did as you say, and just concatenate the given year onto '19' which is not what they should do. Instead they should do year+1900, which will give them the correct year. For instance, localtime() will return '114' for the year 2014, and 114+1900 => 2014. With this in mind, there will be a problem around the year 2030 or some such (Its been a while since I figured it out). However, at that time all that has to be done is to increase the size of the time storage integer to something larger, so it doesn't overflow. I am not sure how FreeBSD handles syncing with the BIOS clock, I am fairly sure it will handle it correctly. Somebody else can update you on the y2k effort with FreeBSD. Basically, a while back I recall a flurry of activity to hunt out problems like I mentioned above (simply concatenating 19, instead of adding 1900). Overall, I for one am not concerned about it. -Brandon Gillespie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970809103251.28696A-100000>