On Tue, Jan 14, 2003 at 12:27:30AM -0600, Dave Rolsky ([EMAIL PROTECTED]) wrote:
> On Mon, 13 Jan 2003, Martijn van Beers wrote:
> 
> > gives:
> >     [19700329T020000..19701025T030000],
> >     [19710328T020000..19711031T030000],
> >     [19720326T020000..19721030T030000]
> >
> > 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)
> 
> Wouldn't it be better to specify them in something a little more primitive
> (numbers, not a string)?

In iCalendar, the string has significance, because timezones
can be specified as part of it:

"19720326T020000Z" is that date/time in UTC;
"19720326T020000;America/New_York" is that date/time in New York,
whether New York's in daylight savings or standard time.

> > 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.
> >
> > 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 store UTC only, and then use the timezone objects to
> do other things.  So if we 19700328T233000Z and add 4 hours, we end up
> with 19700329T033000Z.  And if the timezone is Europe/Amsterdam, then when
> the user asks for ->hour, they get the right answer.

Where "right answer" involves knowing whether Amsterdam is in 
DST or not right now, I assume?

srl
-- 
Shane R. Landrum         [EMAIL PROTECTED]                __o  
"In the end, you write the book that grabs you                -\<,
by the throat and demands to be written." - Salman Rushdie  (*)/(*)

Reply via email to