diff --git a/en/y2kbug.sgml b/en/y2kbug.sgml
index 1b9c0eb4a7..34f2bce42c 100644
--- a/en/y2kbug.sgml
+++ b/en/y2kbug.sgml
@@ -1,255 +1,255 @@
+
%includes;
]>
-
+
&header;
As management understanding of the Year 2000 problem (aka, "The
Millennium Bug") increases, more and more companies are demanding
official statements from the vendors of their hardware and software
as to how their product will handle the year 2000 date rollover.
Organizations that use unix and unix like operating systems
such as FreeBSD are already one step ahead of the problem. FreeBSD
will properly maintain time long after year 2000 passes.
Background information
(This section based on the text from the Linux Y2K compliance
page)
As with all Unix and Unixlike operating systems, time and dates in
FreeBSD are represented internally as the number of seconds since the
1st of January 1970 (the Unix "epoch"). Currently, that figure is stored
as a 32 bit integer, and will run out part way through 2038. By then we
should (hopefully) be using a counter of 64 bits (or greater) which
should be good until the end of the universe.
Note that the OS being Y2K compliant will not fix errant
applications that are not Y2K compliant.
Note also that the OS expects to read the current date and time from
the CMOS clock of your computer. Not all of these devices correctly
handle the year 2000. You are advised to test each platform individually
to ensure that your hardware clock behaves correctly when going from
1999 to 2000, and that it correctly interprets the year 2000 as a leap
year.
What you can do
FreeBSD will continue to properly maintain time well into the
next century. Third party applications, however, might not.
Your best defense against year 2000 issues is a good
offense. Listening to stories claiming the coming meltdown of
the world as we know it are not the way to
solve the millennium bug. Nor is waiting until the last
minute. The FreeBSD Project recommends that your organization
apply sound system administration principles as the millennium
approaches.
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.
FreeBSD Year 2000 Statement
"After extensive analysis and testing, we believe that FreeBSD is 100% Y2K
compliant. In the unlikely event that something has been overlooked, we
will do our best to fix it as soon as possible."
David Greenman
Principal Architect, The
FreeBSD project
Fixed problems
The following Y2K problems have been identified and fixed in
FreeBSD.
- misc/1380
- Several programs have a hardcoded 19%d in responses for the year.
Affected programs include: yacc, ftpd, and make.
[Fixed: yacc v1.2 1999/01/18; ftpd v1.7 1996/08/05;
make v1.4 1996/10/06]
- conf/1382
- The sed script in /etc/rc.local that builds the host/kernel ID line
for the message of the day relies on the year not going past
1999.[Fixed v1.21 1996/10/24]
- misc/3465
- The etc/namedb/make-localhost command generates the DNS serial
number as YYMMDD. In the year 2000, this will be generated as
1YYMMDD.[Fixed v1.2 1997/08/11]
- gnu/4930 and
gnu/8321
- groff tmac macros have hardcoded 19 for generating some dates.
[Fixed: tmac.e v1.3 1998/12/06; doc-common v1.10 1999/01/19]
- bin/9323
- In its obsolescent form, touch doesn't treat the two digit year
year specification correctly. Years in the range 00-68 are treated
as 1900-1968 instead of 2000-2068.[Fixed v1.7 1999/01/05]
- xntpd/parse/util/dcfd.c
- The leap year calculations for the number of days in a year, and
the conversion of DCF77 time to seconds since the Epoch were wrong.
These errors affected all years.[Fixed v1.6 1999/01/12]
- tar/getdate.y
- Function Convert() was hard-coded for two digit years in range 70-99.
Now adjusted to allow two digit years for 1970-2069. The function
does not allow for century non-leap years - y2k1 alert!
[Fixed v1.4 1999/01/12]
- fetch/http.c
- The HTTP protocol includes an obsolete date format which uses a
two-digit year. Previous versions of fetch would interpret all such
dates in the 1900s; subsequent to this revision, the pivot described
in RFC
2068 is employed, which causes two-digit years to be interpreted
as always belonging to the current century unless they would be
50 or more years in the future. Since the HTTP servers which
use this obsolete format are no longer widespread, this is not expected
to have a significant impact.[Fixed v1.24 1999/01/15]
- misc/9500
- The `edithook' script in the CVSROOT directory uses a raw tm_year and
will therefore display 01/01/100 for 2000-JAN-01.
[Fixed v1.2 1999/01/17]
- bin/9501
- Several cvs contrib files are not Y2K compliant.
The log.pl and sccs2rcs.csh scripts prepend `19' to the year
resulting in a display of 19100 for 2000. The log_accum.pl
script uses a two digit year in one place and in another
place assumes that the tm_year is year within century rather
than years since 1900.
[Fixed: log.pl v1.2 1999/01/15; sccs2rcs.csh v1.3 1999/01/15]
- bin/9502
- The groff number register `yr' is assigned from a (struct tm).tm_year
and therefore represents the number of years since 1900, not the
year within the century (see definition in troff/input.cc).
- bin/9503
- PicoBSD's simple_httpd uses a raw tm_year and will therefore
display 01/01/100 for 2000-JAN-01.[Fixed v1.2 1999/01/16]
- bin/9505
- Adduser uses a raw tm_year and will therefore display 100/01/01 for
2000-JAN-01.[Fixed v1.42 1999/01/15]
- bin/9506
- Cron uses a raw tm_year and will therefore display 100 for 2000.
[Fixed v1.7 1999/01/16]
- bin/9507
- tcpslice(8) uses a raw tm_year and will therefore display
100y01m01d... for 2000-JAN-01. For compatibility, use a two-digit
year until 2000.[Fixed v1.8 1999/01/20]
Problematic applications
- ports/7681
- TkDesk 1.0 uses a hardcoded 19 in the file listing window. A
file with a date > 2000 is displayed with a year looking like
"191xx" where xx is the last two numbers of the real date. This
bug has been fixed in version 1.1.[Port updated 1998/10/10]
- ports/9295
- INN 1.7.2 suffers from 2 Y2K related problems. One occurs when
pulling news (-f option to nntpget) and the other relates to
the Expire header with relative dates past 2000.
- [Fixed v1.30(both inn and inn-stable) 1999/01/13]
+ [Ports upgraded to INN 2.2 1999/05/02]
- ports/9298
- Knews suffers from 2 Y2K related problems. One occurs during
the generation of the NNTP NEWGROUPS command. The other occurs
because knews doesn't think that 2000 is a leap year.
Both are fixed in knews-1.0b.1.[Port updated 1999/01/07]
- ports/9300
- Nntp-t5 suffers from a Y2K problem during the generation of
the NEWNEWS command.[Port patched 1999/01/05]
- ports/11144
- The tiff port has a hardcoded 19xx. While this is in the
contrib section (for converting Sun rasterfile format to
TIFF), and not installed by default, this should be patched.
[Port patched 1999/04/18]
- ports/11145
- The dgs port suffers from the same TIFF related problem
as the tiff port. [contrib routine for converting Sun
rasterfiles to TIFF] [Port patched 1999/04/18]
More information
If you have further questions about FreeBSD's year 2000 compliance, or
you have discovered an application running under FreeBSD that is not Y2K
compliant, please contact the project at freebsd-bugs@FreeBSD.ORG.
&footer;