Re: [ID 20000108.003] Error in localtime(time) function

[Larry Wall <larry@wall.org>]

Russ Allbery writes:
: Francisco Javier <pacho@mangle.univalle.edu.co> writes:
: 
: > The localtime(time) function returns `100' as the year, that's wrong.
: 
: I'm sorry to disagree, but no, it's not.  It's exactly what the
: documentation of localtime has been saying it would return since
: essentially the beginning of Perl.
: 
: windlord:~> perldoc -f localtime
:     localtime EXPR
:             Converts a time as returned by the time function to a 9-element
:             array with the time analyzed for the local time zone. Typically
:             used as follows:
: 
:                 #  0    1    2     3     4    5     6     7     8
:                 ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
:                                                             localtime(time);
: 
:             All array elements are numeric, and come straight out of a struct
:             tm. In particular this means that `$mon' has the range `0..11' and
:             `$wday' has the range `0..6' with sunday as day `0'. Also, `$year'
:             is the number of years since 1900, that is, `$year' is `123' in
:             year 2023, and not simply the last two digits of the year.
: 
: It's somewhat non-intuitive, I realize, but not incorrect.  In this
: behavior, Perl is following the behavior of the underlying C library and
: the format of a struct tm.

I'd love to deprecate that interface...

I suspect Perl ought to support internal time objects, just as it will
someday support internal exception objects.  I imagine that in a scalar
context, localtime and gmtime ought to return a time object:

    my tm $t = localtime($time);

(Or maybe we just switch to a "tm->new($time)" constructor.)

The tm object ought to have methods like:

    $t->sec
    $t->min
    $t->hour
    $t->mday
    $t->mon		# based at 1
    $t->_mon		# based at 0
    $t->monname		# February
    $t->year		# based at 0 (year 0 AD is, of course 1 BC).
    $t->_year		# year minus 1900
    $t->wday		# based at 1
    $t->_wday		# based at 0
    $t->wdayname	# Tuesday
    $t->yday
    $t->isdst
    $t->hms		# 01:23:45
    $t->ymd		# 2000/02/29
    $t->mdy		# 02/29/00
    $t->dmy		# 29/02/00
    $t->date		# Tue Feb 29 01:23:45 2000
    ...

and stringification set to call $t->date, which is what localtime
currently produces in scalar context.  (Plus I still want to make
method calls interpolate someday.  We should maybe deprecate the
current meaning of "$x->foo".)

And of course, you ought to be able to subtract one time object from
another, etc.  All this should be done efficiently so that logging
scripts don't slow down from their current behavior.

We can probably borrow some ideas from CPAN's Date modules as well.

Larry

---

Follow-Ups from:

Tim Bunce <Tim.Bunce@ig.co.uk>

References to:

Russ Allbery <rra@stanford.edu>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---