[Design][Decision] Floating timezones

[Mimi Yin]

We're about to finalize the floating timezones proposal and wanted to  
gather a final round of input and feedback in case people are sitting  
on thoughts and ideas and haven't had a chance to express them:

Here was the original proposal:
http://lists.osafoundation.org/pipermail/design/2006-January/003758.html

Here was my summary, after much discussion (includes use cases and  
workflow descriptions)
http://lists.osafoundation.org/pipermail/design/2006-January/003894.html

The proposal in brief is:
+ Add a preference to "turn on" timezone support
+ Prior to turning on timezone support, all events are stored as  
"floating". As a result, if you change the timezone on your computer,  
none of your events will shift.
+ Once you've turned on timezone support, all events are stored in  
"local time" (whatever timezone your computer is set to) and then  
timezones proceed to work the way they do today.
+ Nice to have: You turn on timezone support, you make a bunch of  
timezone adjustments. Then you turn off timezone support. We somehow  
remember your timezone adjustments if you turn on timezone support  
again.
+ If you have timezone support turned off and receive, import or  
subscribe to event(s) that have timezone information, the following  
could happen:
++ A dialog pops up telling you that you either have to turn on  
timezone support or lose timezone info on the data you're adding to  
your calendar.
++ The events display in the calendar in "floating time", but in the  
detail view, you can see what timezone they're in.

Mimi

On Jan 17, 2006, at 6:21 PM, Mimi Yin wrote:

> Here is the long-awaited summary of the floating timezones proposal  
> put forth on the design list Jan 6th.
>
> I wrote up a proposal for implementing a variation on how iCal  
> treats timezones in the UI:
> + OOTB, Chandler calendar does not support timezones. No pulldowns  
> to specify or display a timezone for the calendar canvas. No  
> pulldowns to specify or display timezones for individual events.
> + Users interested in timezone support can look for it in  
> Preferences and activate it explicitly.
>
> This split off into 3 separate threads:
> ===
> 1. Should we store events as floating when timezone support has not  
> been activated?
>
> Some use cases for doing this:
> + Users who don't really travel much or don't use their calendar  
> when traveling.
> ++ They only use calendars for work and they mostly travel for  
> vacation or family holidays.
>
> + Users who do travel but prefer to do all the timezone math in  
> their head.
> ++ Described David Allen's way of sorting out timezones in his  
> calendar.
> ++ People get used to identifying certain meetings by their start  
> time or approximate placement physically on the calendar canvas,  
> ie. "that 1:30" meeting, irrespective of what timezone they're in.  
> So keeping the "1:30" meeting in the 1:30 slot is important, even  
> if the user changes the "clock" on their computer to a new timezone.
>
> However, Grant pointed out that in iCal, they actually store the  
> events in the "local" timezone even though the UI pretends to not  
> know anything about timezones. As a result, in iCal if you change  
> your "clock" on your computer to a new timezone, all of the events  
> on your calendar will get moved automatically. If you go from San  
> Francisco to New York, events that started at 1:30PM will show up  
> as starting at 4:30PM.
>
> There are also some complications if you pretend that timezones  
> don't exist:
> + What happens when you receive an invitation for an event that is  
> stored in a specific timezone?
> + What happens when you subscribe to a calendar that is stored in a  
> specific timezone(s)
>
> Some possible solutions:
> + Throw up a dialog to let people turn on timezones support AND/OR
> + The new events show up on your calendar as floating, but the  
> specific timezone they're stored in is displayed, but not editable.  
> So if you have NOT turned on timezone support and receive an event  
> for 1-2PM EST, it will show up in the 1-2PM slot on the calendar  
> and the detail view will display: 1-2PM EST.
>
> ===
> 2. Should we have preferences at all?
>
> Jeffrey wasn't sure whether we wanted to hide timezones by default.
> Philippe pointed out that users looking for timezone support will  
> be motivated to look for it in preferences.
> Brendan thought most student users of calendars wouldn't need  
> timezone support but wasn't sure if that was a valid user group.
>
> ===
> 3. Oren brought up an import bug when importing calendars from  
> Oracle calendar. This is being addressed as a bug in bugzilla.  
> http://bugzilla.osafoundation.org/show_bug.cgi?id=5000
>
> Mimi
>
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060125/541e4718/attachment.html