On May 31, 2005, at 9:51 AM, Rob Kinyon wrote:

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.

I met a guy once who made his living doing Java programming.  I asked  
him what he liked about Java and he said "Nothing.  I hate it. I only  
do it because it pays."  He then went on to list the reasons he hated  
it--high on the list was that Java is not good at date manipulation.  
Personally, I've done so little Java that I can't really speak to the  
accuracy of his statements, but the message has stuck with me--date  
manipulation is important, and needs to be got right.

To put it another way--it's one of those hard things that Perl 6 is  
trying to make easy.

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

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

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 ... :-)

The biggest reason I didn't use DateTime was that I found it awkward
for the common case; most of the time I just want to stuff in an
ISO8601 date.  I also don't like implicit normalisation to seconds
underneath the hood when I'm doing basic date calculations, and
the way that the "DateTime" base class is inherantly based on the
Gregorian calendar.

The "Date" and "Duration" roles are extremely minimal; see

    http://svn.openfoundry.org/pugs/ext/Date/lib/Date.pm
    http://svn.openfoundry.org/pugs/ext/Date/lib/Duration.pm

The major API is described at:

    http://svn.openfoundry.org/pugs/ext/Date/lib/Date/Gregorian.pod

This module is supposed to be somewhere between DateTime and
Class::Date, with built-in ISO-8601 support (as it's the standard ;)).

With a bit of luck, all Date implementation can share this `Date'
Role, and Gregorian calendar modules share the `Date::Gregorian' Role,
so that the multitude of implementations that crop up will be mutually
exchangable, and the simple case fast, efficient and useful.

Sounds good to me.