[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Perl localtime() Problems [was Re: *ping*]



I must say,

   In all fairness to Matt and others of us who have been using Perl for a
   while, the Version 4 documentation is somewhat to blame:

o  It doesn't explicitly describe what's returned for the year.
   (The Version 5 document says "the year has had 1,900 subtracted from it")

o  Examples show the following use pattern:

	($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)
		= localtime(time);
	$month = (January,February,March,April,May,June,
		July,August,September,October,November,December)[$mon];
	 . . . "$month $mday, 19$year" . . .

in response to what Russ Allbery <rra@stanford.edu> wrote:

> Sabrina Downard <viv@ziggurat.org> writes:
>
>> We had a "y2k bug."  Yep, a very important one.  The date on our main
>> web site, generated by a perl script from Matt's Script Archive, rolled
>> over to the year 19100.  :-)
>
> Most experienced Perl programmers have a very dim view of the general
> quality of scripts in Matt's Script Archive.  Many of them have precisely
> this bug and have for a long time, and I believe the author has even been
> informed of this in the past and hasn't bothered to fix it.
>
>> Of course, the $Year variable was being set by saying "if ($Year > 95)
>> { print '19$Year' };", and for whatever reason it was rolling 99 to
>> 100.
>
> It's the documented behavior of localtime, in both the system C libraries
> and inherited by Perl.  The correct way of deriving a four-digit date from
> the return of localtime in both Perl and C is to add 1900.  The most
> common Y2K bug in Perl scripts is caused by programmers being more subtle
> than they should be and not reading the localtime documentation.  They
> assume that localtime is returning a two digit year when it's explicitly
> documented as returning the number of years since 1900.
>
> (It would have been much better and less confusing for the world had the C
> library functions always just returned four-digit dates.  Ah well.)

- Ed Lyon <EALyon@Cisco.Com>, Cisco Systems Inc.