On 11 Aug 2000, Perl6 RFC Librarian wrote:
> In the past, Perl has provided access to date and time information
> through the C library C<localtime()> and C<gmtime()> functions.
> Unfortunately, these functions have several "really bad things" about
> them:
>
> 1. some values are 0-indexed while others are 1-indexed
> 2. they return massive lists as their only interface
> 3. minute and second values aren't 0-padded
> 4. the year has to have 1900 added to it to be correct.
>
> While some of these are perhaps understandable, that last one just plain
> doesn't make I<any> sense
Number 1 is good for indexing, and number 3 is the way it is because
numbers aren't 0-padded -- after all, you didn't write "01." to "04.".
(And number 4 is for hysterical raisins, of course.)
> =head2 Return Values
>
> The return values are dependent on the context within which C<date()> is
> called. For all contexts, the following are the values and their ranges:
>
> $hour = 0 .. 24
> $min = 00 .. 59 # 0-padded
> $sec = 00 .. 59 # 0-padded
> $fsec = 0 .. 1 # fractional seconds per hw clock
I assume $hour, $min, $sec would be dual-valued, a la $!, so that $min
might be 9 in numeric context and "09" in string context. This would save
a string-to-number conversion if I want to calculate with the value of the
variable -- Perl wouldn't have to translate "09" to 9 because it *is*
already 9.
Oh, and what about leap seconds? Shouldn't $sec's range be 00 .. 61?
> $mon = 1 .. 12 # hooray!
> $mday = 1 .. 31
> $year = 1 .. 9999 # 4-digit!
While you're at the padding job, make $hour, $mon, and $mday zero-padded
to two decimal places as well, for consistency. If you say "those who want
04.07. for the Fourth of July can use sprintf", then zero-padding $min and
$sec makes no sense to me, either. So, 04.07.2000 03:06:02, please. (If
you want to be really consistent, zero-pad $year to four places, though
that will give a Y10K problem.)
> I'm still a little uneasy about C<$wday> starting with 1 == Sunday, just
> because Monday seems like the first day of the week to me. But I'm not
> the one writing the calendars, and it seems silly to only have one value
> that's 0-indexed. Oh, well. :-)
So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan',
'Feb') or qw(dummy Jan Feb)... oh well.
> =head3 LIST Context
>
> 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":
>
> ($year, $mon, $mday, $hour, $min, $sec, $fsec,
> $wday, $yday, $isdst, $isgmt, $tz) = date;
>
> This ordering follows the predictable pattern of being in increasing
> granularity and so should be easy to remember. Just think of a
> computer-esque timestamp:
>
> 2000/11/4 12:03:09
The previous ordering follows the predictable pattern of being in
decreasing granularity and so is extermely easy to remember. It also has
the advantage that it goes from more specific to more general, so if you
don't want the general bits (for example, only the time), you just assign
to ($sec, $min, $hr) = localtime; .
> Note that the month, day, and year are not 0-padded.
Apparently, neither is hour. And why not, pray? I'd like to see the
justification for this decision.
> 8. Reverted to GMT from UTC since most systems are internally
> maintained in GMT, not UTC.
What's the difference?
Cheers,
Philip
--
Philip Newton <[EMAIL PROTECTED]>
