On Mon, 13 Jan 2003, Martijn van Beers wrote:
> The format of the time strings and the recurrence rules are defined
> in the iCalendar rfc (2445). This was used because the primary use
> of Date::Set was going to be Net::ICal. (not that I'm aware of
> any other syntaxes to specify recurrences in)
Ick, recurrence syntax? We need data structures:
( frequency => ONE_YEAR, # constants from DateTime::Set maybe
...
)
Making your interface require on some complicated string formatting makes
the API _really_ incomprehensible.
I _really_ want to rework the Date::Set API as part of turning it into
DateTime::Set. But I'm not quite ready to get to that yet.
As to timezone objects, regardless of whether or not these are implemented
using DateTime::Set, they will have a different API. Either it will _add_
methods to DateTime::Set, or just offer its own limited set of methods,
and hide the fact that its a DateTime::Set object under the hood.
> So, this sounds like something very high level, which shouldn't be
> considered part of the base object. But.. it is needed for really
> low-level operations, like ->add(). For example:
>
> 19700328T233000 + 4 hours = ??
>
> You'd think 19700329T033000. And you'd be right most of the time,
> but not if that time was a Europe/Amsterdam time. Then, it'd
> be 19700329T043000.
The base object will need to _have_ a DateTime::TimeZone object. It will
not _be_ one.
> So, I think we need to either put all of this inside the base object,
> or make the base object do UTC only.
The base object will probably do UTC only for all math and so on, and the
internal representation should probably be fixed to UTC.
Then the data-returning methods can adjust the returned value based on the
timezone object that the base object has.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
