Closed Bug 1178208 Opened 6 years ago Closed 6 years ago

Wrong time is displayed when the alarm rings after a time zone change

Categories

(Firefox OS Graveyard :: Gaia::Clock, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.5+, b2g-master verified)

VERIFIED FIXED
blocking-b2g 2.5+
Tracking Status
b2g-master --- verified

People

(Reporter: u504868, Assigned: mcav)

References

Details

(Keywords: foxfood)

Attachments

(2 files)

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?
QA Whiteboard: [foxfood-triage]
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.
Flags: needinfo?(doliver)
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.
Flags: needinfo?(doliver)
Assignee: nobody → m
Priority: -- → P2
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+
master: https://github.com/mozilla-b2g/gaia/commit/35c97cf4aea972181c09cb418e6fb271d3762f50
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
QA Whiteboard: [foxfood-triage] → [foxfood-triage], [MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.