Currently there is potential for confusion around time zones for
custom alarms because we don't provide any visual cues to tell the
user what time zone their custom alarms are set in.
Custom alarms are different from alarms that cue off event date/times
because many of the use cases we've talked about for custom alarms
are completely independent of the event.
Use case: I get an invitation to attend a destination wedding in New
Zealand in October. The event on my calendar is set to Auckland time.
However 3 months before, I need to make sure I RSVP by email. When I
RSVP, I'll still be in the US of A, or traveling somewhere, but most
likely, not in New Zealand. Or put another way, just because the
wedding takes place in New Zealand doesn't say anything about where
I'm going to be when my custom alarm fires.
So, when I set a custom alarm to RSVP by end of day July 1st, I want
the alarm to fire at 5PM on July 1st, where I happen to be on July
1st. I don't want the alarm to fire at 5PM on July 1st in Auckland time.
Also, there's little side issue that in Chandler, all items can have
custom alarms, not just events. So for tasks, notes and messages, we
really need to figure out what time zone
Today, we assign the app's '1st default time zone' to custom alarms.
That roughly corresponds to your system clock, assuming you don't
change the time zone on your system clock.
So if you live in Detroit and your system clock is set to Detroit
time and you turn on time zones in Chandler, your 1st default time
zone is Detroit time. If you then change your default time zone to
Dresden or Kiev, custom alarms will continue to be created in Detroit
time. This covers most cases and is probably the best solution for
Preview.
However, there may be funny cases where users are traveling and
change their system time zone and/or change their default Chandler
time zone and custom alarms are still firing as if they were still in
Detroit. What if I move? Am I stuck with Detroit time on all my
custom alarms forever?
In the future however, we may want to consider the following
alternatives:
1. Poll the OS to find out if the user has changed their system time
zone. If they have, change all upcoming custom alarms to that new
time zone. That way when a custom alarm fires at 3:30PM, you'll look
up at the clock on your OS and say: Yup, I understand why that custom
alarm fired at 3:30PM. My computer says its 3:30PM!
2. Keep the custom alarm time zones in sync with the Chandler default
time zone. This will be a little funny when you're just changing the
default time zone to glance at someone else's calendar from their
point of view (as in, you have not physically changed location
yourself.) However, those use cases are usually short-lived, so most
of the time, custom alarms will fire *in the time zone you are
currently in*.
If 1 and 2 are impractical, we can try the following *once we have
expando date/time widgets and can show/hide all those date/time
fields we have*...http://chandlerproject.org/Journal/
ExpandoDateTimeFields
3. Provide users with a time zone picker for custom alarms. This is a
more onerous workflow however, but at least the user will have an
explicit visual cue re: what's going on and has a way to change it.
Anyway, lots of options. Let's see what dogfooders say. What I'm
describing may be such an edge case that most people don't even notice.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
