So should I take your silence on Option 1 to mean that I guessed
correctly that keeping the custom alarm up-to-date with the system
clock is not practical?
What about Option 4: Keep the custom alarm time zone in sync with the
current default time zone?
Mimi
On May 18, 2007, at 11:48 AM, Grant Baillie wrote:
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 :).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
