It seems some layer is interpreting the alarm time being requested as UTC instead of the local timezone, thereby scheduling it 5 hrs too far ahead. It looks like clock and the alarm api expect localtime although this is not explicit in the API doc.
We should ensure that timezone changes are reacted to properly for saved alarms. Perhaps all alarms should be saved in UTC and converted as appropriate.
It seems some layer is interpreting the alarm time being requested as UTC instead of the local timezone, thereby scheduling it 5 hrs too far ahead. It looks like clock and the alarm api expect localtime although this is not explicit in the API doc.
We should ensure that timezone changes are reacted to properly for saved alarms. Perhaps all alarms should be saved in UTC and converted as appropriate.