maemo.org Bugzilla – Bug 1693
Alarm should be tied to travel location, or at least provide option
Last modified: 2009-02-25 09:26:33 UTC
You need to
before you can comment on or make changes to this bug.
Problem: I noticed while traveling that the alarm is driven by your home
location. That's fine when you're actually at home, but makes setting the
alarm difficult as you change time zones.
Recommendation: The alarm should be connected to the travel location rather
than home location. Better yet, the locations could be selectable, with the
alarm defaulting to travel, which makes the most sense.
I'd suggest allowing each alarm to be tied to its own timezone.
I have an alarm to wake up in the morning: that should always fire at 06:00
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
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
re-assign to UI specs
FYI, current state in Fremantle (and I can't see any changes compared to
* 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
(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
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.
Hmm, seems I should improve communicating that I'm just the messenger here. :-)
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
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.