5 Jan
2000
5 Jan
'00
5:32 a.m.
Here's Brian Kernighan's note on troff and Y2K:
in n1.c, numtab[YR] is set to localtime()->tm_year, which is the
number of years since 1900. in 2000, this will contain 100.
the troff manual says that \n(yr contains "the last two digits of
the current year", but nowhere in the code is this set, and the
year can be set to anything. so it's really "the current year
minus 1900". the manual and the code are
inconsistent, which is always a problem.
in any case, in most installations troff and nroff are legacy
systems for which there is no source code, so changing them is
not feasible. furthermore, any change to troff is likely to
require changes in macro packages anyway, and may cause silent
errors by conflicting with current behavior or colliding with
previously unused names.
fortunately, it seems straightforward to fix the macro packages
that are the most likely sources of problem; individual macro
packages will have to be fixed by individuals. grepping for
"yr" will find most trouble spots.
typical macros packages use \n(yr in two ways. one is
ds ]W (printed \n(mo/\n(dy/\n(yr)
which assumes that the year is 2 digits and to be printed as 2
digits. presumably the first day of 2000 is to be printed as
1/1/00, so the fix here is to set register yr to 2 digits
.nr yr \n(yr%100
either once at the beginning (under the assumption that the year
isn't changed by the macro package) or each time \n(yr is going
to be used (providing locality at the price of more changes).
the other common usage is
.ds ]W \*(]m \n(dy, 19\n(yr
the easiest way to fix this is to add, at the beginning again,
.nr yr 1900+\n(yr
and change all subsequent uses from 19\n(yr to \n(yr.
any macro package that uses both of these constructions will need
a bit more care to unify things; the easiest fix is likely to be
two registers, one with the full year and one with the last two
digits.
.nr YR 1900+\n(yr \" 4-digit year
.nr yr \n(yr%100 \" last two digits
this will break code that happened to use this register name.
some macro packages (e.g., -mm) try to be clever about dates,
and include explicit tests to determine whether a user-provided
date has 2 or 4 digits, and then adjust by 1900; this is another
case that has to be fiddled by hand.
any approach that changes register yr at the beginning fails if
the year is set explicitly later on, as it might be by some of
the date macros in -ms and -mm. this still seems like the best
fix, however.
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id KAA35876
for pups-liszt; Wed, 5 Jan 2000 10:35:21 +1100 (EST)