Closed Bug 1178208 Opened 6 years ago Closed 6 years ago
Wrong time is displayed when the alarm rings after a time zone change
STR 1. In a given time zone (for example America/Vancouver) set an alarm 2. Move to a time zone ahead (like Europe/Paris) 3. Wait until the alarm is fired Results The alarm is fired at the right time, but the wrong time is displayed on the alarm panel. See video for details: https://goo.gl/1AM1VG Repro frequency: 3/3 Additional notes: Happened on my dogfood device after coming back from Whistler.
[Blocking Requested - why for this release]: Mornings while being jetlag are confusing. Having the alarm being displayed at the wrong time might hurt many of our dogfooders (especially after work weeks). Even though, this issue might have existed for multiple releases, I think this issue is worth being fixed before the next work week.
blocking-b2g: --- → 2.5?
Agreed, this is broken core functionality.
blocking-b2g: 2.5? → 2.5+
Hi Dylan, can you have someone take a look to the issue? thanks.
The problem is that the clock app is telling the alarm UI to display the date that it is given by the mozAlarms database and this value is not updated by mozAlarms. Specifically, in the case of this video: - While the device thinks it is 1:45am UTC-7, an alarm is set for 10:47am UTC-7. This goes in the mozAlarms database as a JS Date object in structured clone representation which contains only the milliseconds-since-epoch. This value would have been 1435556820000. However, the AlarmsService adds a private "timezoneOffset" field to the record which it does not make available when notifying about the alarm. - The device's timezone is changes to UTC+2, a net change of 9 hours, making the device think it is 10:45am UTC+2. - The AlarmsService reloads its alarms and recomputes things when it sees this timezone change. AlarmsService._getAlarmTime is aware of the timezone the original alarm was scheduled in and the new timezone, and it applies the 9 hour correction factor for the alarm. However, it does not mutate the mozAlarm record at this time. - The alarm fires, the AlarmsService notifies about the alarm, providing the original UTC value, and still not performing any compensation. - The Clock alarm UI says 7:47pm. It says this because the alarm date without timezone correction is still 9 hours in the future. It seems like there's two possible fixes here, and they both have good arguments: 1) Just make the Clock app display the current time, not the alarm time. There may be UX reasons it does what it does, however. 2) The mozAlarms API should probably be applying timezone correction as part of its _publicAlarm method, if ignoreTimezone is set. The spec at https://wiki.mozilla.org/WebAPI/AlarmAPI says "Whenever the system clock or timezone is adjusted at run-time, all the saved alarms will be rescheduled." which is admittedly ambiguous here, but also the current behaviour is also arguably dumb. The sysapps spec-work to standardize mozAlarms I think was abandoned when sysapps was abandoned, and at least the draft didn't include the ability to ignore timezones, so that's not really any help.
Comment on attachment 8670007 [details] [review] [gaia] mcav:clock-displayed-timezone > mozilla-b2g:master Gandalf, since I'm fresh out of Clock peers and you're the closest I have, asking you for review. This patch is relatively simple: instead of pulling the time from mozAlarms and displaying that (which is incorrect per Comment 4), we pull out the "hour" and "minute" of the alarm and display that, which will always be correct. We already did this in alarm_list.js, presumably for similar reasons. I'm not sure that QA will be able to verify this fixed yet due to the current system-timezone bug fiasco, but this at least fixes the display problem specified in this bug.
Attachment #8670007 - Flags: review?(gandalf)
Comment on attachment 8670007 [details] [review] [gaia] mcav:clock-displayed-timezone > mozilla-b2g:master Ok, that's an r+ for now to fix it, but what we really should do is either fix this: > However, the AlarmsService adds a private "timezoneOffset" field to the record which it does not make available when notifying about the alarm. or add alarm.timezone next to alarm.time, to calculate the right time for the timezone. It's a bit scary that we're playing with raw hour:minutes here.
Attachment #8670007 - Flags: review?(gandalf) → review+
According to the STR of Comment 0, this bug has been verified as pass on latest Flame KK v2.5 and Aries KK v2.5. Actual results: The alarm is fired at the right time, and the corresponding time is displayed on the alarm panel. See attachment: verified_Aries KK v2.5.3gp Reproduce rate: 0/6 Device: Flame KK v2.5 (Pass) Build ID 20151012150203 Gaia Revision 0b934d06c04adff2cd9bdd0bc204f974a18b710f Gaia Date 2015-10-12 12:15:30 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/f4215b484d529e01f0f84ff4005e3321ee98b727 Gecko Version 44.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20151012.183433 Firmware Date Mon Oct 12 18:34:45 EDT 2015 Fireware Version v18D v4 Bootloader L1TC000118D0 Device: Aries KK v2.5 (Pass) Build ID 20151012230518 Gaia Revision 0b934d06c04adff2cd9bdd0bc204f974a18b710f Gaia Date 2015-10-12 12:15:30 Gecko Revision https://hg.mozilla.org/integration/b2g-inbound/rev/11ff0ccb7d59311df4c190d331c8b58c6e35a0c8 Gecko Version 44.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20151012.224830 Firmware Date Mon Oct 12 22:48:38 UTC 2015 Bootloader s1
You need to log in before you can comment on or make changes to this bug.