Date: Sun, 4 Jul 1999 20:27:27 +0100 From: Nik Clayton <nik@nothing-going-on.demon.co.uk> To: Wolfram Schneider <wosch@cs.tu-berlin.de>, Anders.Beckman@midcon.se Cc: freebsd-doc@freebsd.org Subject: Re: [Anders.Beckman@midcon.se: Y2K info] Message-ID: <19990704202726.G71138@catkin.nothing-going-on.org> In-Reply-To: <19990617105102.A21608@cs.tu-berlin.de>; from Wolfram Schneider on Thu, Jun 17, 1999 at 10:51:02AM %2B0200 References: <19990617105102.A21608@cs.tu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 17, 1999 at 10:51:02AM +0200, Wolfram Schneider wrote:
> ----- Forwarded message from Anders Beckman <Anders.Beckman@midcon.se> -----
> Date: Thu, 17 Jun 1999 10:28:46 +0200
> To: wosch@FreeBSD.org
> From: Anders Beckman <Anders.Beckman@midcon.se>
> Subject: Y2K info
>
> Hi!
>
> I read your Y2K page - a readable and informative page, but I disagree
> strongly with the statement under What you can do:
>
> "There are tests that you can perform to see how your system will respond.
> Set your clock to a few minutes before midnight on
> New Year's Eve and watch the system time. Your system should display the
> year as 2000 and not 1900. If the year is displayed
> incorrectly, then you will have plenty of time to update your hardware.
> Operating your organizations information systems under
> their normal daily load with the clock set forward can provide valuable
> insight into your vulnerablility to year 2000 issues."
>
> This test will not reveal BIOS/RTC problems in hardware. And setting the
> clock forward in systems in daily use may result in a lot of unneccessary
> problems (such as bad billing dates, file backup confusion etc etc etc).
>
> Mail me if you need more detailed comments!
I've added the following to this page, which should cover your suggestion.
If you think it should be reworded, please get in touch;
<blockquote>
<strong>Important:</strong> Do <strong>not</strong> do this on a live
production system. You may confuse any applications you have which rely
on dates (billing systems, backup regimes, and so on). Always conduct
tests like this on development systems which can not affect any live
data you may have.
</blockquote>
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christiansen in <375143b5@cs.colorado.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990704202726.G71138>