> > The C<$time> specifier can be followed by a C<$timezone> argument,
> s/<$time>/<$format>/
Ooops! Thanks. :-)
> Allow numeric (e.g. minutes? seconds?) displacement?
> This would also allow
>
> $tomorrow = date(undef,undef,24*60*60);
Good call. The function could use a string as a timezone, or a number as
seconds of offset. I'll put this in.
> GMT is not UTC (although it is equal for most practical purposes).
Ok, I'll have to research this a little. I've heard both ways (it is, it
isn't, it's supposed to be...)
> > $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")
True, but notice that you have to specify a format. You might not want a
format, but just a constant-length date/time suffix for your backup
files:
$backup_suffix = join '', ((date)[0..6]);
This is why I think 0-padding is invaluable. Granted, the same thing
could be done with a format, but the above would probably be quicker.
Plus, I don't see the 0-padding as having any negative side-effects
(remember, localtime() will still be in Time::Local).
> Also, why not space-pad the mday?
Actually, given what I just said above - good point! This is actually a
whole issue by itself. Here's the question: how should day/month/year
look:
02/05/0982 # 0-padded
2/5/982 # not 0-padded
Geez, I can really see it both ways (although I probably prefer the
former because it's easier to work with).
> Isn't $isutc identical to ($tz eq 'UTC')?
Yes. The difference is that it makes comparisons much cleaner:
if ($isutc) { ... }
if ($date->isutc) { ... }
And since we already have one for $isdst, I figured it was useful.
However, if there's a lot of counter-opinion, it can be removed.
> 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.
Sounds good, I agree. It actually makes things much more usable too.
> > $t->mon # based at 1
> > $t->_mon # based at 0
>
> Why? Is it so hard to write $t->mon-1?
All the examples you mention are actually requests from Larry himself.
Check out the link I mentioned at the bottom of the RFC.
That being said, if we don't like them, we can remove them still. I
intentionally only left them accessible via the object form, but I think
they are pretty useful actually (they give you access to localtime()
formatted stuff). We might want to change the names a little.
> 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"
Well, this one took a lot of thinking. I actually spent a good day just
on this. Here's the issue: we need to be able to get the format given to
date() into both the object and the scalar. Setting the format with a
function that doesn't print something out seemed the right thing to do.
So, follow the call (which assumes you've read an RFC I just submitted
which hasn't been published yet :-):
$date = date undef, '%m/%d/%Y'; # puts format into $date->format(),
# returning a date() object
print "$date"; # calls $date->SCALAR, which is
# a reference to $date->date(),
# which relies on $date->format()
# ... time passes ...
$file = "$filename.$date"; # same thing again
So you see why we need a persistent format() function. However, I think
your real issue is a one-time call that just changes the format
temporarily:
print $date->strftime('%H:%M'); # print the time
print "$date"; # without touching this
I'll put strftime() back in, I think that's probably the best thing for
this.
> But I would like to have 'tzsec' (the #seconds displacement for this
> timezone).
It's in there:
$t->tzoffset # timezone offset in seconds
> Huh? If the user specifies 'PST' you have to _know_ what 'PST' means.
Right, I wasn't sure how to say this. All I meant was *maintaining* it
might be tricky. But it's not. I'll just take this part out.
-Nate
