[Design][Decision] Floating timezones

[Mimi Yin]

See in-line

On Jan 26, 2006, at 12:16 PM, Sheila Mooney wrote:

> Mimi,
>
> + What is the default when you start Chandler - to have timezones  
> on or off?

The default is OFF.

> + To reiterate Jeffrey and Philippe's comments, it is my assumption  
> that the preference to turn on and off timezone affects the UI  
> only. We don't do any kind of repository conversion.

YUP

> + Will we still have the ability to select floating timezone when  
> we have the timezone preference turned on...like we do now?
>

YUP

> Sheila
>
> On Jan 25, 2006, at 5:51 PM, Mimi Yin wrote:
>
>> 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
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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/20060126/c94924ff/attachment.html