Hi Bryan, > I think this problem could be interpreted differently: the invite > specified a specific time and timezone (say, 22:00Z), but we stored the > event using a floating timezone (22:00 floating). As I interpret the > design intention, we should instead have preserved the event's timezone > as GMT (causing it to appear in the 2:00PM spot, but labeled "10:00 PM > GMT"). (I think this design could be improved upon: we could decide that > GMT is less friendly, and convert events to the local system's timezone > on import if their timezone is GMT, whether the timezone preference is > on or off.)
To be clear, in no-timezone mode we *should* be preserving timezones, we're just not displaying them. We can't really safely change the timezones of items we share, and our code base currently doesn't distinguish between sharing and importing, so converting the timezone on import is a little problematic. But rendering UTC differently is still reasonable. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
