I'd suggest allowing each alarm to be tied to its own timezone.

Use case:
I have an alarm to wake up in the morning: that should always fire at 06:00
local time.
I have an alarm for a weekly international conference call: that should ALWAYS
be at a specific time zone's time, irrespective of my currently active time
zone.

Thus, I'd say each alarm should have a time zone field, that can either adopt a
specific zone or "current".

Good idea David.  Maybe this issue could eventually tie into the larger concept
of device profiles, ie, where you have different alarm settings for different
profiles.  One aspect of profiles could of course be current timezone.

I'd also suggest that the clock applet also display the travel time or be able
to be configured to display whichever of the times you decide

Comment 4 Philippe De Swert 2008-07-16 18:46:33 UTC

re-assign to UI specs

Comment 5 Andre Klapper 2009-02-24 18:19:05 UTC

FYI, current state in Fremantle (and I can't see any changes compared to
Diablo):
* Home city is meant to set system date and time.
* Destination city is only meant to COMPARE to the Home city to see 
  differences in time and date.

Clock alarms are stored using the local time (= home city, not destination
city).
(An alarm always shows in the UI at 8:00, even if the device time is changed.)

I *currently* cannot see any Nokia plans to change this behaviour.

Thanks for responding, Andre, but I feel you are failing to consider:

* design intent is NOT necessarily paramount.  What really matters is the
behavior that users EXPECT or need.  The proposed change is more useful to
travelers than the current mode.

* I have requested that the usability could be added as an OPTION, which means
the intended use can stay intact and yet also take into account how many users
expect to use the alarm.

* This is low-hanging fruit, the sort of easy changes/fixes that maemo
traditionally ignores in favor of "squeaky wheels".  While as a longtime
programmer and business analyst I fully understand the typical necessity of
prioritizing by "noise" level, I also recognize the value in occasionally
knocking out the easy ones in order to, if nothing else, show accomplshment and
please users-- especially during the dry spells between major innovations and
corrections.

I would hope the meamo team would start putting a more serious effort into
studying (and incorporating) user habits and less into making assumptions and
holding original design intent as sacred.

Comment 7 Andre Klapper 2009-02-24 21:57:25 UTC

Hmm, seems I should improve communicating that I'm just the messenger here. :-)

Comment 8 Quim Gil 2009-02-25 09:26:33 UTC

Fixed in Fremantle.

Actually the fix doesn't come from the alarm itself, but on the clock. Thanks
to the cellular data connectivity users will be able to have automatic
synchronization, meaning that your device will show you the local time
automatically no matter where you are, while the alarms will keep ringing at
the time you set them up in the timezone you set them up.

> I have an alarm to wake up in the morning: that should always fire at 06:00
local time.

Interesting use case that I think (but I haven't tried myself) is not
contemplated in Fremantle. However... how many people has such a life that they
would like to wake up at the same time no matter where in the planet they are?
Maybe it's a good feature for your device, but quite insame for your body.  :)  

Anyway, feel free filing a specific enhancement request if it's clear one day
that Fremantle is not having it.