Hi Mimi, > It seems like what's actually needed is the ability to assign multiple > timezones to the same calendar canvas. Monday I'm in PST, Tuesday after > 3PM I'm in EST. Otherwise, separate timezones for start and end times of > a flight could result in a flight arriving before it departs on the > calendar (which persists in a single timezone).
Persisting a single timezone per event isn't the only option. It would add a little more complexity, but we could certainly persist an end time timezone, if we wanted to. The calendar wouldn't get confused about how to render the flight, the calendar area occupied by the event would render the same way it does now, representing the true duration of the flight in the current timezone. In the detail view this would mean having two timezone drop downs, one for start, one for end, changes to start change end. > This is another use case for a Floating calendar which is agnostic to > timezone. Hmm. I do think this is an argument in favor of a floating time UI for relatively stationary users, but I think so because I think doing so gives us more leeway to make the timezone UI more complex. I think the Joel Spolsky and Esther Dysons of the world really want complete timezone features. Since we're going to have a timezone-less option to lower complexity for some folks, I'd argue we ought to go ahead and really implement timezones full on for globe-trotters. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
