[Design] What time zone are custom alarms in?

Grant Baillie grant at osafoundation.org
Fri May 18 11:48:08 PDT 2007


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




More information about the Design mailing list