1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
"http://www.FreeBSD.org/XML/doc/share/sgml/xhtml10-freebsd.dtd" [
<!ENTITY title 'Year 2000 Compatibility (aka "Millennium Bug")'>
]>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>&title;</title>
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
</head>
<body class="navinclude.docs">
<p>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.</p>
<p>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.</p>
<h2>Background information</h2>
<p><i>(This section based on the text from the <a
href="http://www.linux.org.uk/mbug.html">Linux Y2K compliance
page</a>)</i></p>
<p>As with all Unix and Unix-like 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.</p>
<p>Note that the OS being Y2K compliant will not fix errant applications
that are not Y2K compliant.</p>
<p>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.</p>
<h2>What you can do</h2>
<p>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
<strong>not</strong> 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.</p>
<h2>FreeBSD Year 2000 Statement</h2>
<blockquote>
<p>"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."</p>
<p align="right">David Greenman<br/>Principal Architect, The FreeBSD
project</p>
</blockquote>
<h2>Fixed problems</h2>
<p>The following Y2K problems have been identified and fixed in
FreeBSD.</p>
<dl>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=1380">misc/1380</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=1382">conf/1382</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=3465">misc/3465</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=4930">gnu/4930</a> and
<a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=8321">gnu/8321</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=9323">bin/9323</a></dt>
<dd>In its obsolescent form, touch doesn't treat the two digit 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]</dd>
<dt><a
href="http://cvsweb.FreeBSD.org/src/usr.sbin/xntpd/parse/util/dcfd.c">xntpd/parse/util/dcfd.c</a></dt>
<dd>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]</dd>
<dt><a
href="http://cvsweb.FreeBSD.org/src/gnu/usr.bin/tar/getdate.y">tar/getdate.y</a></dt>
<dd>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]
</dd>
<dt><a
href="http://cvsweb.FreeBSD.org/src/usr.bin/fetch/http.c">fetch/http.c</a></dt>
<dd>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 <a href="ftp://ftp.cdrom.com/pub/internet/rfc/rfc2068.txt">RFC
2068</a> 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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=9500">misc/9500</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=9501">bin/9501</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=9502">bin/9502</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=9503">bin/9503</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=9505">bin/9505</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=9506">bin/9506</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=9507">bin/9507</a></dt>
<dd>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]</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14472">bin/14472</a></dt>
<dd>Date command does not take thousand/hundred digits. [Fixed v1.31 1999/11/10]
</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14511">misc/14511</a></dt>
<dd>Chpass has a problem using 00 for expiration year.
</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=15852">bin/15852</a> and
<a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16045">gnu/16045</a> and
<a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16207">bin/16207</a>
</dt>
<dd>Groff predefined \*(DT [\*(td] string has Y2K bug. [Fixed with import of
version 1.15 2000/01/12]
</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=15872">bin/15872</a></dt>
<dd>at(1) has a problem with valid time specifications if tm_year is 100,
reports `garbled time'.
</dd>
<dt><a
href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16238">misc/16238</a></dt>
<dd>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]
</dd>
</dl>
<h2>More information</h2>
<p>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 <a
href="mailto:freebsd-bugs@FreeBSD.org">freebsd-bugs@FreeBSD.org</a>.</p>
</body>
</html>
|
