Front page | perl.perl6.language |
Postings from June 2005
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. -kolibrieThread Previous | Thread Next