On Mon, 13 Jan 2003 21:07:15 -0600 (CST), [EMAIL PROTECTED] wrote: >On Mon, 13 Jan 2003, Yitzchak Scott-Thoennes wrote: > >> 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). > >Let's say that if you create a DateTime object with specifying a timezone, >it just uses UTC. Wouldn't that achieve the same effect? In other words, >if you created a datetime of "2002-12-15 19:00:00" and never changed the >timezone associated with it, then it would always represent 6PM on that >date.
That's exactly the same blurring of distinction that Date::ICal suffers from. In iCalendar talk, "20030113T190000Z" is a UTC time and "20030113T190000" (without a TZID set) is a floating time, and they should be representable with different objects. I would expect that if you add a timezone to them, say America/New_York, you would get "TZID=America/New_York:20030113T140000" for the first and "TZID=America/New_York:20030113T190000" for the second.
