On Wed, Jun 01, 2005 at 03:42:57PM +1200, Sam Vilain wrote:
> I've made a start on this.  See ext/Date in pugs.  I don't think that
> your views are necessarily contrary.

That's what I'm looking for.  Thank you!

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

So, if we continue following this API, Perl6 core will contain time(),
but no localtime() nor gmtime().  The Date module will provide human
readable date and time strings, and basic date math.

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

So further date manipulation could be provided by other date modules,
hopefully within the same framework.

Sounds good to me.

-kolibrie

Reply via email to