Bugzilla – Bug 14888
Alarm time gets confused with Timezones ?
Last modified: 2011-11-06 23:22:07 UTC
This morning two of our alarms did not fire :((((( I was on a very late 7.4.1 (r7907) in the hope I had a stable system now. Wenn I pressed the power button the firmware-upgrade-screen showed itself, asking me to upgrade. I can't express how disappointed I'm right now - if anything needs to function stable, its the alarm !
Some more information. Now - one hour later - the alarm started (but for some reason the speaker didn't work - just saw it on the menu). It fired one hour late ? The clock on the bottom clearly states 8:00, the alarm is set to 7:00. Tried it again: set the alarm to 7:20, waited for the radio clock to show 8:20 and voila - there is the alarm. Even the alarm popup shows 8:20 !
I realize now, that the shift only happens, when connected to my local SB-Server. After searching a lot I found that it's timezone was set to BST while the Radio shows CEST. This sort of explains the shift by one hour. I thought the radio would sync to the server, shouldn't it have synchronized and thus shown the mistake ? As I'm configuring an alarm relative to the time shown at the clock, this can be very confusing. Either you should take this into account, or there should be a very clear warning if the server has another timezone configured than the radio and the alarm time is relative to the servers timezone rather than the radios timezone. Very confusing and dangerous.
next user thinking alarm is not working due to this bug: http://forums.slimdevices.com/showthread.php?t=70526
Stefan, The user in the forum thread you quote seems to have solved the problem by correcting the time zone setting on his server. I assume you have checked your server to make sure its time and zone are correct?
Yes correcting the timezone on the server solves the problem. I still find it very dangerous and confusing.
Which revision fixes this ?
Having the correct time on the server fixes this "Yes correcting the timezone on the server solves the problem." Unless I'm missing something here, please confirm that the issue is fixed for you
But if the server has a wrong timezone, the alarm is still wrong and there is no sign to the user that he could have configured a wrong alarm. The Radio Clock showed 8 o'clock and if the alarm is set to 8 o'clock it should fire at 8 o'clock. Shouldn't it ? I didn't know the squeezeboxserver-user had a wrong timezone. On linux every user can have another timezone set, so this problem isn't really easy to spot. I was just lucky to wait another hour and hear the alarm which got me thinking about the issue. The user from the forum had a shift by 6 hours and wasn't aware of it. If he created a bug report telling you the alarm didn't fire, would you have been able to spot the problem ? And do I know what timezone MySB.com is running or selecting for me ? Currently I'm just afraid that this problem could sneak in again. For me only one of the following would be a proper solution: - make the radio show the time (and timezone) of the server - thus I would have spotted something was wrong with the server-clock -OR- - popup a clear warning when setting up an alarm, that the server timezone doesn't match the radios timezone and the alarm will fire relative to server timezone. Thus I would have spotted something was wrong -OR- - make the alarm time relative to the timezone of the radio - thus I didn't need to care as long as I'm satisfied with the time my Radio is showing.
Matt: please see comment 8 for alarm settings, this would require a new user UI or some sort of checking for alarm time set.
Will discuss at bug meeting, I'm not sure this is a UI problem necessarily
next one puzzled: http://forums.slimdevices.com/showpost.php?p=483250&postcount=10
What we should consider is displaying the timezone on the alarm-setting screen.
The issue that needs to be corrected is the rather undefined behavior when there is conflicting time zone information between the server and the radio. Radio must always win, regardless of server time zone setting. Any alarm set on the radio must fire when the radio reads that time, regardless of time zone. Any other behavior is incorrect/loose design or a bug I'm afraid.
This seems overcomplicated. Keep the timezone, clock time and the alarm time on the Squeezebox Radio - not on the server! What value is keeping the alarm time on the server, in the server timezone? What value is the server at all, relative to time, alarms, or timezones? Periodically synchronize the radio time with a "real" time server on the internet.
This is marked unassigned, updating bug to force response. Expected behavior: When SB time displayed matches alarm setting, alarm should fire. Matches user expectation of any "normal" alarm clock. Actual behavior: Alarm fires when time matched SBS time. This causes an unexpected result when the SB is not in the same timezone as the SBS. This occurs when user is traveling/expat/using a TZ to work around ISP issues. Does not make any sense in the "normal" alarm clock model.
Unassigned bugs cannot have a priority.