On Fri, 24 Jan 2003, Tim Bunce wrote:

> Would someone do me the great favour of summarizing some things for me?
>
> Just the Goals and Design Principles would be great, an outline of
> the API(s) would be a bonus.
>
> I'm particularly interested in:
>       Basic object API (there is going to be an object right?)

Yes, it will be an object.  The API is not even close to finalized, but
you can take a look at the docs for the DateTime.pm module in CVS to get
an idea of where it's going:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/perl-date-time/modules/DateTime.pm/lib/DateTime.pm?rev=1.16&content-type=text/vnd.viewcvs-markup

>       Extensibility (through subclasses or in other ways)
>       Using the extensibility well to avoid bloat of the basic object
>       Efficiency for common usage

These three are all basically related.

My goal for the core object is to have it handle the following:

- represent a date & time as an object (duh ;)

- be able to return various useful information about that date & time
(year, month, day of week, etc.)

- be able to do basic date math (add 2 days, add 1 year), with the help of
DateTime::Duration
-- handle leap seconds when doing date math.

- be able to do time zone/offset handling, by using DateTime::TimeZone.
Using the Olson DB time zone bits will be heavier weight, but there will
also be an "offset-only" timezone option which lets you just say "this
datetime is in -0600".  The time zone parts are a little more nebulous for
me right now, because the more I work on it the more I realize how complex
it is.


The core functionality will be extensible by simply by having a
well-defined, simple API.  For example, a module that provides ICal
datetime format output does this:

  sub datetime
  {
      my $self = shift; # instance of DateTime::Format::ICal
      my $dt   = shift;

      my $date = join '', $dt->year, $dt->month, $dt->day;
      $date .= 'T';
      $date .= join '', $dt->hour, $dt->minute, $dt->second;

      my $tz = $dt->time_zone;
      # time zone object API is still very much in flux
      if ( ! $tz->is_floating )
      {
          if ( $tz->offset_as_seconds == 0 )
          {
              $date .= 'Z';
          }
          else
          {
              $date = "TZID:" . $tz->name . ":$date";
          }
      }

      return $date;
  }

Obviously, this requires nothing from the core modules beyond what I
already described.

I'm hoping there will be lots of parsing/formatting modules, plus modules
that calculate events (Easter, Chinese New Year, Lunar cycles, etc), and
so on.

As for speed, there's a couple ways to attack this.  First of all, a lot
of the calculations the core object will be doing can be memoized quite
easily, and reset only when the object is changed (which will be
infrequent in most uses).

If it's still too slow, the best solution will probably be to reimplement
part, or all, of the core functionality in C.  The libtai64 library has
already been discussed on the list.

The other bottleneck that may occur is the time zone code.  Since this
will largely be generated from the Olson DB, it's not too much of a
stretch to imagine generating XS code instead of Perl.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Reply via email to