diff --git a/data/y2kbug.sgml b/data/y2kbug.sgml index bad8138065..b0d1ea7944 100644 --- a/data/y2kbug.sgml +++ b/data/y2kbug.sgml @@ -1,66 +1,94 @@ + %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.

The current FreeBSD statement is as follows:

"We believe, but cannot guarantee, that FreeBSD is Y2K compliant. We have spent a significant amount of time verifying this to be the case, but it is possible that something may have been overlooked. If a Y2K bug is found in the future, we will attempt to fix it as soon as possible."

David Greenman, Principal Architect, The FreeBSD project

More 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.

+

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.
+ +
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.
+ +
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.
+ +
gnu/4930
+
groff tmac macros have hardcoded 19 for generating some dates.
+
+

Problematic applications

This section is currently a placeholder. As we become aware of applications that have a Y2K problem we will note them here, and also attempt to indicate which versions (if any) of the software are fixed.

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; diff --git a/en/y2kbug.sgml b/en/y2kbug.sgml index bad8138065..b0d1ea7944 100644 --- a/en/y2kbug.sgml +++ b/en/y2kbug.sgml @@ -1,66 +1,94 @@ + %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.

The current FreeBSD statement is as follows:

"We believe, but cannot guarantee, that FreeBSD is Y2K compliant. We have spent a significant amount of time verifying this to be the case, but it is possible that something may have been overlooked. If a Y2K bug is found in the future, we will attempt to fix it as soon as possible."

David Greenman, Principal Architect, The FreeBSD project

More 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.

+

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.
+ +
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.
+ +
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.
+ +
gnu/4930
+
groff tmac macros have hardcoded 19 for generating some dates.
+
+

Problematic applications

This section is currently a placeholder. As we become aware of applications that have a Y2K problem we will note them here, and also attempt to indicate which versions (if any) of the software are fixed.

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;