[Design] Floating timezones

[Mimi Yin]

We started having a time-zone discussion in bugzilla, so I'm moving  
it over to the design list so it has more visibility.

I've copied over the bugzilla discussion below. The main issue is how  
to deal with floating time-zones. One proposal is to do what iCal does:

Have a preference for turning on and off time-zone support. Before  
support has been turned on, all events are automatically assigned a  
floating time-zone, and the calendar itself is time-zone-free. This  
means that when you change the time-zone on you computer, none of the  
events in the calendar will "move or shift" to make up for the time- 
zone difference, they will just pretend like they were always created  
in the new time-zone. Prior to time-zone support being turned on,  
there are no pulldowns for time-zones in either the calendar canvas  
area or the detail view.

Once time-zone support has been turned on however, all events and the  
calendar are automatically assigned the "local time-zone" derived  
from the settings on your computer. At the same time, you can  
explicitly designate different time-zones for both the calendar  
itself and individual events.

If you turn time-zone off again, time-zone information is hidden and  
all events and your calendar return to floating time-zones.

Alec, I checked iCal and it looks like they actually preserve the  
time-zone information so that if I turn on time-zone information  
again, all of my old time-zones reappear and the events shift  
themselves on the calendar accordingly. (Is this hard to do?)

Philippe also pointed out the need to continue to offer the floating  
time-zone option even when time-zone support has been turned on. That  
way, you can differentiate between events that adapt to whatever time- 
zone you're in (ie. morning work-out is always at 7AM) versus events  
that are time-zone specific (ie. flight or meetings).

Mimi

====
We should endeavor to treat time-zones like iCal.

OOTB, time-zone support should be off (no pulldowns in calendar  
summary or detail view). All events are
stored in floating time-zone.

When user turns on time-zone support, then the pulldowns appear and  
the floating time-zone events are
automatically assigned the local time-zone.

------- Additional Comment #1 From Philippe Bossut 2006-01-05 11:36  
PST [reply] -------
On the default TZ: iCal may use floating but I'm wondering if we  
shouldn't instead pull the local TZ from
some system prefs (if any). If users went through the trouble of  
setting the system TZ, they certainly
except a calendar to acknoledge that pref.
I'm not dead set on this though, just thinking it's more practical.

------- Additional Comment #2 From Mimi Yin 2006-01-05 11:41 PST  
[reply] -------
We just got a bunch of feedback from people saying that they don't  
want their calendar to know about
time-zones (ie. David Allen) because they expect and want to do all  
the conversions in their head. So we
should have a no-time-zone option, which is really the simplest use  
case as well.

Another issue for the list.

------- Additional Comment #3 From Alec Flett 2006-01-05 13:08 PST  
[reply] -------
Yes, the simplest use case only when the user ONLY uses floating time- 
zones. As
soon as the user starts using ANY time-zone information, this becomes  
the most
complex use case as we start to get real/floating time-zone interaction.

------- Additional Comment #4 From Mimi Yin 2006-01-05 13:16 PST  
[reply] -------
I'm not sure I understand the need for floating/real time-zone  
interaction. When users turn on time-zone
support, could we just convert all floating time-zone items over to a  
real time-zone and vice versa when
they turn it off?

------- Additional Comment #5 From Alec Flett 2006-01-05 15:26 PST  
[reply] -------
we could, though that means loss of data, at least visually - i.e. if  
I have
specifically set an event at 1pm PST and another event at 3pm CST  
(i.e. both at
the same time) and then turn time-zones OFF in the prefs, do we now  
show them as
occuring at different times? Or do we try to normalize them all to  
some specific
local time-zone without telling them. And if so, which time-zone is  
that? Probably
the system time-zone?

In addition, the time-zone could have been set from an import of a  
calendar, or
from sharing.

I'm not saying these aren't solvable problems, I'm just saying its  
complicated :)

------- Additional Comment #6 From Mimi Yin 2006-01-05 15:51 PST  
[reply] -------
Just looked at what iCal does. They just convert it to the "local"  
time-zone from the operating system. So
something that's 3PM EST will show up as 12PM once I turn off time- 
zones support.

------- Additional Comment #7 From Philippe Bossut 2006-01-05 16:02  
PST [reply] -------
I think you want floating *and* non-floating items in the same  
calendar. e.g.:
- 7am-8am (floating): Go for a run
- 10am (PST): call the bridge for conf call
So if I fly to NYC I can still be reminded of my morning run at 7am  
and be reminded of the conf call at
1pm.

Plus we have the issue of shared calendars as mentioned by Alec.

I think we want to allow both kind of items to exist. "floating" is  
in a sense a special case of TZ. The
pref should be on what default TZ is used for newly created items, it  
should not convert existing items.

BTW, this looks like a conversation we should have on the Design list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060106/b9e01638/attachment.htm