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 (*)/(*)