Hi Folks, I'm sorry to say I'm reopening a discussion we've gone around and around on in the past, but our past compromise just isn't sitting right with me, so I'd like to broach the topic again.
For reference, a summary from the last time we discussed this: http://lists.osafoundation.org/pipermail/design/2006-January/003894.html In a different, more recent, thread, Mimi then Grant said: >> A question for the Chandler developers: How much work is it to >> share the publisher's calendar canvas timezone when publishing >> shares? ... > > I don't think it's a lot of work to add it when sharing (and it's a > good idea for CalDAV, too, assuming we don't already do it). > > However, I'm not quite sure how things are supposed work out if you > subscribe to a calendar with a different timezone than yours, and > that calendar has floating events. Would you want Chandler to > interpret "floating" differently depending on the share/collection? > That seems as if it would be difficult (barring a brilliant idea from > someone like, say ... Jeffrey :) . I'm not sure how difficult it would be, but if we follow the iCalendar concept of floating events, it's really not what we're supposed to do: floating events are really *intended* to mean different absolute times in different timezones. It happens that floating events do the right thing when someone lives their calendared life in one timezone and always interacts with other folks in that timezone, but I think this is misleading. As soon as that person transitions to collaborating with people in a different timezone, all their existing events are actually wrong. My sense is that other calendar apps that don't display timezone UI are still by default creating timezoned (not floating) events. They're just not displaying the timezone if it's local. This seems like it should meet non-timezone users needs, and it transitions well if such users later discover the joys of geographically dispersed events. So it seems to me we're defaulting to UI that caters to (from the summary link above): + Users who do travel but prefer to do all the timezone math in their head. I realize some users actively want a 2PM EST and 2PM PST event to show up in the same time slot. In the past I've deferred to the argument that we should make the calendar work right for these folks. But I've gotten fairly steady private feedback that this is really weird, and very little positive feedback. I'll freely admit that all that feedback is coming from calendaring people, so my anecdotal sample group may not correlate perfectly with Chandler's target audience. But I still think this isn't something we want to default to. I'd prefer that we use two timezone preferences, one "display timezone information", defaulting to off, that would control whether timezone drop downs were visible, but wouldn't affect where events were rendered on the calendar (2PM EST and 2PM PST would show up at different times, non-local timezones would continue to show up with their "EST" next to 2PM). This would suffer from the poorly-set-system-timezone issue, but perhaps we could address that issue by prompting users for their timezone when Chandler first starts? We could add an "ignore timezones when positioning events" option that would default to off, to support users who really actively want to do what we're doing now by default, e.g. A) showing 2PM EST in the same slot as 2PM PST, and B) creating floating events by default Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
