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

["Edward A. Lyon" <EALYON@cisco.com>]

> At 11:46 AM 1/3/00 -0800, Edward A. Lyon wrote:
>>    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")
>
> The perl 4 documentation hasn't been maintained in almost 10 years
> (June 12, 1992).  All documentation since has been much more explicit.
> The documentation does say that the results are straight from the C tm
> structure.  A simple man of localtime (the C function) is very explicit.

    Granted, but that's certainly how I got started on the wrong foot with
localtime() use.  Besides, the documentation explicitly suggests that one
not worry about what the tm struct is.

>>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" . . .
>
> There is no example in the perl source (any version) that shows this.
> There is no example in the Camel or Llama (either version) that shows this.

    Uh, the code excerpt shown was copied exactly from my edition of the
Version 4 Camel book, Programming perl; Copyright 1990; Printed March, 1992;
page 320-321.

> The Perl FAQ for a long time has had the proper information in it
> (at least in '94/'95, when I was maintaining it).

    I gather I inadvertantly stepped on your toes.  My appologies.

> There is no excuse for improper coding when there is ample documentation
> available on how it should be done.

    I concur, but I was trying to show that the documentation has not always
been so ample.  I was certainly pointed in the wrong direction until I read
the Version 5 books.

> There is even less excuse when the programmer has been notified of the
> problem but doesn't bother to fix it.

    I have to agree there, but am ignorant of any details in this case.

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