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.

Important: Do not 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.

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; fixes in FreeBSD-2.2 and above]

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; fixes in FreeBSD-2.2 and above]

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; fixes in FreeBSD-2.2.5 and above]

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; fixes in FreeBSD-3.1 and above]

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; fixes in FreeBSD-3.1 and above]

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; fixes in FreeBSD-3.1 and above]

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; fixes in FreeBSD-3.1 and above]

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; fixes in FreeBSD-3.1 and above]

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; not relevant to FreeBSD releases]

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; fixes in FreeBSD-3.1 and above]

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). [Fixed, now set mod 100, troff/input.cc V1.2 1999/06/03; fixed in FreeBSD-3.3]

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; fixes in FreeBSD-3.1 and above]

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; fixes in FreeBSD-3.1 and above]

bin/9506

Cron uses a raw tm_year and will therefore display 100 for 2000. [Fixed v1.7 1999/01/16; fixes in FreeBSD-3.1 and above]

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; fixes in FreeBSD-3.1 and above]

bin/14472

Date command does not take thousand/hundred digits. [Fixed v1.31 1999/11/10]

misc/14511

Chpass has a problem using 00 for expiration year.

bin/15852 and gnu/16045 and bin/16207

Groff predefined \*(DT [\*(td] string has Y2K bug. [Fixed with import of version 1.15 2000/01/12]

bin/15872

at(1) has a problem with valid time specifications if tm_year is 100, reports `garbled time'.

misc/16238

KerberosIV install does not work properly because there is a hard-wired expiration date of 12/31/99 in the Kerberos source for the ticket granter. [Fixed v1.24 1999/09/19]

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; fixes in FreeBSD-3.0 and above]

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. [Both INN ports upgraded to INN 2.2 1999/05/02; fixes in FreeBSD-3.2 and above]

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; fixes in FreeBSD-3.1 and above]

ports/9300

Nntp-t5 suffers from a Y2K problem during the generation of the NEWNEWS command. [Port patched 1999/01/05; fixes in FreeBSD-3.1 and above]

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, followed by upgrade 1999/05/11; fixes in FreeBSD-3.2 and above]

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; fixes in FreeBSD-3.2 and above]

ports/13694

The slurp port has a problem generating a correctly formatted host file name when tm_year is greater than 100. [Port patched 1999/10/27; fixes in FreeBSD-3.3-STABLE and above]

ports/15477

wwwstat port has a hardcoded 19.

ports/15789

proftpd has a minor Y2K problem. [Port patched 1999/12/22]

ports/15820

sendfile has a problem not setting the atime and mtime properly for files sent after year 1999.

ports/15854

dclock uses localtime and in particular the references to tm_year do not take into account the year 2000. [Port patched 2000/01/04]

ports/15868

The reporting function of hylafax (xferstats) is not y2k compatible. [Port patched 2000/01/24]

ports/15926

A y2k bug in leafnode+ 2.9 considers incoming news articles with the (arguably bogus) Date: header like `Wed, 05 Jan 00 15:01:40 GMT' to be too old, so these incoming articles are dropped. [Fixed by upgrading port to version 2.10 2000/01/24]

ports/16062

Japanese e2ps port has hardcoded 19. [Port patched 2000/01/24]

ports/16073

nntp port 1.5.11.5 has Y2K related problems. [Port upgraded to version 1.5.12.2 2000/01/12]

ports/16167

This is a bug-fix release that corrects a y2k bug in INN 2.2.1 that will show up in the NEWNEWS and NEWGROUPS commands after 2000-01-01 00:00:00 when the date specified to the command is before 2000-01-01 00:00:00. [Port upgraded to version 2.2.2 2000/01/28]

NetHack 3.2.2 and earlier versions are not Y2K compliant (the score file used 2 digit years and will be corrupted if added to in the year 2000). [Port updated to version 3.2.3 2000/01/05]

Japanese mnews port has Y2K problems. [Port updated to version 1.22 1999/12/26]

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.