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
DateTime-Formats-ISO8601-0.01.tar.gz
Description: application/gzip
