[Design] [Sum] What time zone are custom alarms in?

Mimi Yin mimi at osafoundation.org
Wed May 23 09:50:53 PDT 2007


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070523/ca1e8290/attachment.html


More information about the Design mailing list