Re: Personal y2k issue [was: *ping*]

[Russ Allbery <rra@stanford.edu>]

anderson johnston <ajohns5@alumni.umbc.edu> writes:

> I don't use X11 to watch my money disappear, but I did have problems
> with exactly that perl bug in some legacy code written by my
> second-order predecessor.  It seems to be cropping up all over the list.
> If anyone has perl code that builds a four-digit year it's probably a
> good idea to check and make sure the coder didn't just stick a "19" on
> the front of the (until yesterday) two digits that perl returned.

I hate to pick on this point, but to me one of the important aspects of
being a system administrator is accurate diagnosis and assignment of
problems.  I therefore have a hard time letting things like this stand
without a correction.

This is no more a Perl bug than it is a C bug.  If the documented behavior
of localtime, which has remained unchanged since the early days of the C
library is to be called a bug, it's still unfair to place the blame on
Perl.  The tm_year field is epoch-based; it returns the number of years
since 1900 AD and always has.  If you found a system in which it returned
00, that system would have an extremely serious Y2K bug.

Moral:  Always read the documentation for interfaces that you're using.
Just calling localtime, seeing that it returns a two-digit year *this*
year, and drawing conclusions from that paves the road to subtle and
difficult bugs.  For another good example in this regard, the RCS file
specification uses two-digit years up through 1999, and then begins using
four-digit years.  This may be counterintuitive, but it is not a bug, nor
does it cause Y2K problems when used properly.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>