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 log in 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. 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
re-assign to UI specs
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.
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 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.