os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Remove part of setting your clock to the year 2000 to test Y2k compliancy.

Browse source 
We're in 2001 already, if FreeBSD was faulty, we have all been fooled
for almost 1.5 years now.  Amazing.
This commit is contained in:
Jeroen Ruigrok van der Werven 2001-07-19 12:27:38 +00:00
parent b6f32248fe
commit 1fbad0ab43
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=9967
1 changed files with 1 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

19
en/y2kbug.sgml
View file

@ -1,5 +1,5 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY date "$FreeBSD: www/en/y2kbug.sgml,v 1.37 2001/07/08 16:08:57 schweikh Exp $">
<!ENTITY date "$FreeBSD: www/en/y2kbug.sgml,v 1.38 2001/07/13 12:52:11 dd Exp $">
<!ENTITY title 'Year 2000 Compatibility (aka "Millennium Bug")'>
<!ENTITY % includes SYSTEM "includes.sgml"> %includes;
]>
@ -50,23 +50,6 @@
organization apply sound system administration principles as the
millennium approaches.</p>
<p>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 vulnerability
to year 2000 issues.</p>
<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>
<h2>FreeBSD Year 2000 Statement</h2>
<blockquote>