On May 31, 2005, at 1:16 PM, Rob Kinyon wrote:

What's wrong with porting DateTime?

It's back to the old question of "what's in core?"  Are dates and
times something that are used in such a large proportion of programs
that they deserve to be shipped in the basic grammar?  Or perhaps in
the basic set of packages?

Perl 5 has an entire swath of modules designed to manipulate dates
and times; this suggests that they are (A) commonly used and (B)
something that people feel very strongly about the semantics of.

Which still begs the question - why not port DateTime to P6? Why can't
installing a module provide new keywords?


In reverse order:

- No reason it can't.  Nor did I imply otherwise.

- 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?

Personally, I've always found date handling to be difficult. The various modules go a long way towards simplifying it, but they require calling functions and methods, which forces one to think in a low-level algorithmic style. It would be great if there was a more intuitive time/date handling model built into the language...the kind of quantum leap in power and intuitiveness that we got from the new Rules engine (as opposed to the old regex engine).

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.";

# outstanding_tickets() returns user-written ticket objects; created() returns a time object representing
    #  creation time.  The objects stringify to their report.
    say "Remaining issues, oldest first:";
say "\t $_" for sort { $a.creation().age <=> $b.creation().age } outstanding_tickets();

    #  Prints 'Meetings are...is Sunday, June 19.;
say "Meetings are the third Sunday of each month. The first June meeting is " . (month(6).days(0))[2] but format(/<dayname>, <monthname> <day>/);

The above examples are just noodlings and are not well thought out, but hopefully they point in the right direction.


Reply via email to