Ben Bennett <[EMAIL PROTECTED]> schrieb/wrote:
> As another possibility (which is what I did with my obsolete version
> of the ISO8601 parser) is to optionally take an arbitrary DT object to
> use as the base and fall back to today otherwise.
That's why a sublass of DateTime is better: This functionality would
have to be implemented in a lot of parser modules. It's better to have a
class like DateTime::Partial, which can handle all the cases of
incomplete data.
It's also more flexible because the calling programme can detect which
parts of the date were given in the input. With a "base" date, this
information is lost.
My proposed concept for that class is:
Internal storage:
The class stores flags that indicate what of the following is
present/has valid information:
century (YY__)
year of century (__YY)
quarter
ISO week[1]
month
day
hour
minute
second
second precision (for fractional seconds)
Note: no timezone; an unspecified timezone is the floating tz.
[1] 2003W01 would be stored as 2002-12-30T00:00:00.000
internally, i.e. the first point in time of the week.
DateTime compatibility:
If used as a DateTime, the object behaves as if its base had
been set to 1970-01-01T00:00:00, floating tz.
1970 is no leap year.
An unspecified century results in years 1970..2069.
1970 is reasonably far in the past but still near enough so that
we don't have different calendars, missing timezones, etc.
'Get' Methods:
They behave as described under 'DateTime compatibility'. This
ensures that DT::P objects can be used whereever someone expects
a DT object.
new: 'year': is optional, too.
additional parameters:
century
yearofcentury
week
quarter
second_precision
base: takes a DateTime object as a base
base_xxx: a DateTime::Partial object is constructed
from the base_xxx parameters and then used
as the base
set: like new(), takes more paramters and a base date.
set_base: takes a DateTime, a hash reference, or a hash. The later are
used to construct a DateTime::Partial object
The base object is then used to fill in the missing parts of the
DateTime::Partial object.
There should be a parameter whether the next (default), last or
nearest point in time is used.
has_xxx: New functions that return whether the DateTime::Partial
object has valid information for a field xxx.
has_milliseconds: returns whether second precision is smaller than 0.001
has_microseconds: ... smaller than 0.000001
has_nanoseconds: ... smaller than 0.000000001
has_timezone: returns $self->time_zone()->is_floating()
add/subtract[_duration]:
Not sure about these.
Claus
--
http://www.faerber.muc.de