[Design] [Dogfood] Default TZ and interop

[Bryan Stearns]

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