From owner-freebsd-questions Sat Aug 9 09:39:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA01419 for questions-outgoing; Sat, 9 Aug 1997 09:39:35 -0700 (PDT) Received: from roguetrader.com (brandon@cold.org [206.81.134.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA01414 for ; Sat, 9 Aug 1997 09:39:30 -0700 (PDT) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id KAA28718; Sat, 9 Aug 1997 10:40:07 -0600 (MDT) Date: Sat, 9 Aug 1997 10:40:07 -0600 (MDT) From: Brandon Gillespie To: Robert Chalmers cc: freebsd-questions Subject: Re: Year 2000 tests for PC's In-Reply-To: <33EB99FB.8423F546@chalmers.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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