Hola, Mimi
Mas in-line ...
--Grant
On 18 May, 2007, at 10:48, Mimi Yin wrote:
[This is not something we need to resolve for Preview. Just trying
to understand the issues so we can accurately capture them to
include in the list of known issues/bugs.]
Okay, so the workflow goes something like this:
User has not turned on time zones in Chandler.
+ Alarms are set to the system time zone, both custom alarms and
event-date-dependent alarms.
User turns on time zones and selects a default time zone.
+ All existing events are assigned this time zone.
+ Alarms' absolute times *change* so that they fire at the same
time as before, but are displayed in the new time zone.
- 3PM America/Los_Angeles (System time zone); becomes
- 6PM America/New_York (New default time zone).
+ What about event-date-dependent alarms? My 3PM Floating event is
now 3PM America/Los Angeles. When does my 15-minute before alarm
fire? It used to fire at 2:45PM America/Los_Angeles. Does it now
fire at 5:45PM America/New_York (that would be weird?) or 2:45PM
America/New_York?
+ If the latter is true, then there is a difference between the way
custom alarms and event-date-dependent alarms behave when users
turn on time zone support.
+ If the former is true, then I think we have a bug ;o)
Event-date-dependent alarms always fire relative to the event start
time. So, it is the latter.
Option 1: I wonder if custom alarms should just always adhere to
the system clock's time zone. Why? People sometimes change the
default time zone just to see their calendar from a different
perspective.
So let's say you're in Auckland, NZ attending the semi-annual
People-Living-In-Time-Zones-That-Are-Off-By-A-Half-Hour Unite! and
you want to see the OSAF Office Calendar in Pacific_Rim_South/
New_Zealand/Auckland time zone (what an awesome time zone!) because
you're too jet-lagged to do the math and you need to call into the
staff meeting. While you're in Auckland time, you remember a task
you need to do when you get back to the Bay Area and set a custom
alarm to fire end-of-day, the day you get back. That custom alarm
will be set to Auckland time, no?
When you get back to the Bay Area, you re-set your time zone to
America/Los_Angeles, but who knows when that custom alarm is going
to fire!
Option 2: So...if it's hard to keep the custom alarm time zones in
sync with the system clock...could we always set them to the 1st
default time zone the user defines? Or is that not something we store?
It's not something we store (though we could if we really wanted). It
just seems weird to me to base everything off something from
wayback ... e.g. if you moved from San Francisco to Hawaii, and
changed your default timezone accordingly, it would be odd to be
stuck with the timezone from your previous life :).
Option 3: OR, we could add another field to the DV! and have a time
zone pulldown for custom alarms.
Not technically a big challenge (we have mastered the date+time
+timezone combo for editing events), but visually more cluttered, I
guess. Still, it would mean that coming up with some groovy date-time-
editing widgetry would be doubly beneficial.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
