develooper Front page | perl.perl6.language | Postings from May 2005

Re: date and time formatting

Thread Previous | Thread Next
Rob Kinyon
May 31, 2005 11:22
Re: date and time formatting
Message ID:
> - I didn't say we shouldn't port DateTime.  My point was simply that,
> based on the amount of date-related code on CPAN, this is an issue
> that many people care about quite a bit.  We would probably be well
> served to consider it carefully and decide on what semantics we
> really want.  Maybe DateTime is exactly what everyone wants and all
> we need to do is port it.  On the other hand, there is something to
> be said for Nathan's approach; isn't it worth discussing?

What I'm trying to get at isn't that DateTime's API should be
preserved. I'm saying that the concept of DateTime should be ported.
Core or not core - it doesn't matter. When use'd (or installed), it
should override now() (and anyone else we can think of) to return an
object that DWIMs, plus provides the interface you've outlined below.

> Perhaps something like the typed operations that were discussed
> recently:
>      my ($launch_date = now() + 6 weeks) but time(9am);
>      say "We will launch on a $lauch_date.day_of_week, at
> $launch_date.time_of_day.";
>      say "This gives us " . $launch_date but hours . " hours,
> including weekends and evenings.";

Sure. $launch_date is of type DateTime. It will numify to the
seconds-since-the-epoch, stringify to some date string, and provide
all the neat-o-keen methods you want it to have.

Frankly, I think we're in violent agreement here. I don't think this
is something that needs to be built into the language. This is
something that should be strongly-recommended for downloading. Kinda
like you always expect DBI to be around when you go to a new major
client, but it's not core.

Well, I always expect DBI to be around ... :-)


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About