Philippe Bossut wrote:
Hi,
I'm going to make a plea for changing the default behavior we
currently have (namely, using "floating" TZ) and ask for using the
default system TZ. I know I'm negating a previous opinion of mine but
I just got really confused in a recent scenario and think less
knowledgeable users will be even more confused.
Scenario:
- I received an invite from a 3rd party. This invite showed up as an
email in my IMAP InBox.
- Chandler correctly detected and parsed the VCALENDAR data
- Las, because I didn't check "Use Timezones" in the view menu, the
event was displayed using its raw GMT time, i.e., 8 hours ahead, i.e,
out of view on my calendar...
- For a while, I thought the calendar was broken, I started logging a
bug and it's only when I read the vcalendar data myself that I
realized that it was a TZ issue. I turned TZ on in Chandler, set it to
PST (which it does automatically) and the event displayed in the right
place... no bug...
Take away: I'm afraid that this scenario will be fairly common with
initial Chandler users and that it will be counted against us as an
"Interoperability" issue. The bug is very shallow but since people
using all the default options will run into it, this is a concern. I
think default options should be set so that the system "just works" in
the most common cases.
Proposal: When TZ is not turned on, Chandler should use the current
system TZ instead of floating as a default. People who wants floating
(i.e. people moving around across TZ but wanting to maintain their own
TZ bubble) will have to turn TZ on and set "floating" if they want to.
Thoughts?
- Philippe
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.)
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
