On Mon, 13 Jan 2003 13:55:17 -0600 (CST), [EMAIL PROTECTED] wrote: > >> 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.
The base object should have the option of not being tied to any particular timezone, even UTC, so that the data-returning methods do no adjustment. For instance, if I take my wife out to dinner at 7PM on our anniversary every year, I do so at that local time whether we are in Seattle or Baltimore. One of the flaws of Date::ICal has been that it has a particular timezone and can't represent this kind of date (pun intended). The iCalendar spec calls this a "floating" time and differentiates it from a UTC time or a time w/timezone (or a date without a time).
