Hi,
Jeffrey Harris wrote:
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").
But that only works if Chandler "knows" that PST is the time zone of the
user. May be that is the case but that was unknown to me. I thought that
the default was that the whole TZ arithmetic was simply bypassed. OK, if
this is not the case, then I'm fine with the current default, assuming
we do the correct TZ arithmetic.
(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.
What about other timezones? Can we receive events expressed in something
else than UTC? If yes, will they display at the wrong time under your
proposal? (i.e. will I miss my call?)
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
