Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
I like this proposal, although I do have a lot of remarks.
Consider them constructive!
> The C<$time> specifier can be followed by a C<$timezone> argument,
s/<$time>/<$format>/
> which returns the date relative to that timezone. By default, the time
> is returned relative to the local timezone. You can get UTC, for
> example, by specifying C<UTC> or C<GMT> as the timezone.
Allow numeric (e.g. minutes? seconds?) displacement?
This would also allow
$tomorrow = date(undef,undef,24*60*60);
> $object = date time, undef, 'GMT'; # return object in UTC
s/UTC/GMT/
GMT is not UTC (although it is equal for most practical purposes).
> $hour = 0 .. 24
> $min = 00 .. 59 # 0-padded
> $sec = 00 .. 59 # 0-padded
Why 0-padding? The only reason to add this is out of frustration due
to localtime's behavior. With the new date function you'll never need
to call
sprintf("%02d/%02d/%04d", $tm[3], $tm[4]+1, $tm[5]+1900);
since you can do
date(undef,"%d/%m/%Y")
or something alike.
Also, why not space-pad the mday?
> $isutc = 1 or undef; # is UTC? (see below...)
> $tz = PST|UTC|...; # timezone
Isn't $isutc identical to ($tz eq 'UTC')?
> A list of date/time values is returned. The ordering and format of these
> values has been radically changed to reflect what most of us probably
> view as "ordinary":
>
> ($mday, $mon, $year, $hour, $min, $sec, $msec, $nsec,
> $wday, $yday, $isdst, $isutc, $tz) = date;
>
> This ordering is very easy to remember, in my opinion,
I'd argue that
($year, $mon, $mday, $hour, $min, $sec, $msec, $nsec,
is much easier to remember, since it is a series of continuous
decrasing magnitudes.
> $t->mon # based at 1
> $t->_mon # based at 0
Why? Is it so hard to write $t->mon-1?
> $t->year # based at 0 (year 0 AD is, of course 1 BC).
> $t->_year # year minus 1900
What would year minus 1900 be good for?
> $t->wday # based at 1 = Sunday
> $t->_wday # based at 0 = Sunday
Same here.
> $t->hms # 01:23:45
AM or PM? Or 24h clock?
And why is the hour padded with a leading zero, while that is not the
case with the $hour value in list and other contexts.
> $t->ymd # 2000/02/29
> $t->mdy # 02/29/2000
> $t->dmy # 29/02/2000
Hmm. A lot of duplicate information. And how about
$t->hms # 01:02:33
Wouldn't it be better to have a formatting method, like
$t->format("%m/%d/%Y") # 29/02/2000
$t->format # uses preset format, same as "$t"
and rename your $t->format to $t->set_format?
> $t->isutc # in UTC time?
> $t->tz # timezone (also $t->timezone)
Again, 'isutc' looks superfluous to me.
But I would like to have 'tzsec' (the #seconds displacement for this
timezone).
> The C<$tz> variable might seem hard at first. It's not. There are only 2
> possible values:
>
> 1. UTC or other timezone (user specified)
> 2. Local timezone (none specified)
>
> So, all that would have to happen is C<date()> would have to store the
> correct value in the return object, in the precendence above.
Huh? If the user specifies 'PST' you have to _know_ what 'PST' means.
-- Johan
