develooper Front page | perl.datetime | Postings from January 2003

Parser/Backend API proposals

Thread Previous | Thread Next
John Peacock
January 16, 2003 18:27
Parser/Backend API proposals
Message ID:
I've been thinking about the API for parsers and storage methods and I have a 
different suggestion than what has been discussed before.  The current model 
seems to assume that there is a single DateTime object type, regardless of 
backend storage method.  Or at the very least, the current model will require 
additional backend work to completely emulate the existing scheme.  Although 
Date::ICal seems to be a fine base, others have already mentioned wanting to 
implement in other internal schemes, for example TAI64.

I suggest that the parsing modules (currently referred to as DateTime::Formats) 
be strictly limited to parsing some subset of the possible input formats and 
return an object with a few standard methods which would retrieve a normalized 
representation.  Then, the parsed and normalized object could be used by the 
chosen backend to store the date for later processing.

For example, DateTime::Formats::XXXX would return an object which would have the
following methods:
	$obj->as_array     # "big endian" array of date/time values
	$obj->as_unix_time # seconds since the epoch
	$obj->as_string    # some sort of "standard" text format
	$obj->as_ical      # the ICal normalized format

as well as the possibility of other methods for specialized purposes (like
TAI64).  That way, the parser doesn't have to know what ultimate storage method
will be used.  Ideally, a given parser would only need to do one parse when the
->new() is called (to be sure that it recognized the date in question), and be
able to generate the other three only if requested by the DateTime::Storage class.

I've actually been programming some sample code, so for this object:

	my $prs = DateTime::Formats::ISO8601("1998-06-03T12:30:01");

you would have these possible methods:

     $prs->as_array => ARRAY(0x8064c68)
        0  1998
        1  06
        2  03
        3  12
        4  30
        5  01
     $prs->as_unix_time => 899483401
     $prs->as_string => '1998-06-03T12:30:01'
     $prs->as_ical => '19980603T123001'

I would suggest that the DateTime objects themselves simply be a wrapper for the 
DateTime::Storage::XXXX module, which itself would rely on the DateTime::Format 
modules to provide it with a normalized date format.  The DateTime->new() method 
would be very shallow:

     my $self = {
         DATE => DateTime::Storage->new(DateTime::Format->new($val)),

     bless $self, $class;

so we would always know which backend module to use (since we know what class 
the DATE is), we would be able to store object specific information in the hash. 
  I don't think there is any utility to knowing what the input date string 
looked like, but there is no reason that couldn't be maintained as well.

I have DateTime::Formats::ISO8601 done (well formed ISO dates only); I attach it 
for your pleasure.  I can work on DateTime::Formats::Date_Parse for the more 
difficult parses.  Then I will set my eyes on DateTime::Storage::TAI64 (no I 
don't like the naming convention much either).

John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About