Hi Mimi,
Thanks for the summary. I'm going to restate some of what you and others
have said -- to make sure that I understand. All y'all can correct me if
I'm off here.
As I understand it, we have two cases where floating events/timezone
events/sharing collide and potentially create problems.
Floating view of timezoned events case:
+ The *calendar canvas* (or view, in the mvc sense of view) does not
have timezones turned on.
+ Events in the calendar being shared have multiple timezones. Events
don't show up with the proper relationship to each other, which could
have unintended consequences.
This case could show up in either Cosmo and Chandler, but it is more
likely in our casual collaborator scenario because the starting point
for the casual collaborator is that they are looking at someone else's
calendar, and that calendar might have timezones turned on. If the
default is that the casual collaborator doesn't have timezones turned
on, we might be setting up a problem.
I'd observe that as long as the canvas/view *does* use timezones, we
don't really have the above problem. It doesn't matter which timezone is
used, events show up in proper relationship to each other.
I'd argue that the reasonable solution here is to turn timezones on in
the Cosmo UI if the shared calendar uses any (non-floating) timezones.
Any timezone will avoid the problem, and the Cosmo user could change the
timezone to fit the one they wanted to view the calendar with. (I guess
this is either your (B) or (C) proposal).
Freebusy case:
+ A user does not have timezones turned on, all floating all the time.
The user is tracking timezone changes in their head.
+ The user shares their collection as free-busy.
+ Other users might not know what is in the first user's head. (Then
again, if they work/live closely together, the subscriber might actually
know how to interpret the times). If free-busy subscriber has timezones
turned on, the system needs to make some guess at the first user's timezone.
+ CalDAV free-busy *requires* a timezone associated w/the calendar to
use for floating events.
This case isn't a barn burner for Preview. That said, presumably we can
pick the user's local timezone and associate it with a published
free-busy collection. You could also require the free-busy creator to
pick a timezone when publishing free-busy.
I am sort of concerned about introducing per-collection timezones and
what they are meant to mean and how they would interact with a UI that
displays multiple collections. Some thoughts...
Mimi Yin wrote:
Issue #2 is more complicated. I'm not even sure what a collection
timezone would do.
+ What does it mean for a collection to have a timezone which in turn
contains individual items that have different timezones?
I assume the individual item's timezone defines the item's time. The
collection's timezone is a suggestion for the view, or *is* the view's
timezone. It is used to pick the timezone when a new event is created.
I understand from Grant that even when items are floating, some timezone
is needed to make a decision about what events get included for a given
day/week. If I understand correctly, right now Chandler defaults to use
the system/local time for floating events. One could use a collection
timezone here, but that sounds hairy to implement for not much benefit
to get some edge cases right.
+ How do we overlay collections that have different timezones in the
calendar view?
You could use the timezone of the "top" collection, just as we do for
picking a color (Grant's idea). As you pointed out to me, this approach
could have the downside of the timezone jumping around as you switch
collections, which might not be what you really want.
+ What is the timezone of an individual item if it belongs to multiple
collections, all with different timezones?
The timezone of the individual item should be the timezone that is used
to define the item.
I'd be concerned about supporting different timezones for different
calendars/collections for Chandler in Preview. Its hard for me to see
how we're not opening up a can of worms if we add the timezone to the
calendar, but perhaps someone can help me here.
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
