1180257 - mozAlarm fires alarms not at the expected time after a timezone change

Status: RESOLVED DUPLICATE of bug 1181489

(Core :: DOM: Device Interfaces, defect, P1)

Description

[Johan Lorenzo [:jlorenzo]]

Bug coming from :padenot's device.

Steps to reproduce
1. Get an Aries in Vancouver and set some alarms
2. Fly back to France, and don't touch any of your alarms
3. Wait.

Results
The always are triggered at the same time (in the afternoon) but not at the expected time. This is not due to a simple timezone difference. For instance (see logs): 2 alarms are set, one at 8:30am UTC+2 and the other at 8:53am UTC+2 => The alarm rang at 5:06pm UTC+2.

After taking a look at the log, nothing seems to be wrong on the Gaia side, as the first log line generated is from the mozAlarm handler[1].
More over, this is not a problem with the internal clock, like we have on the Flame. This is happening on the Aries, which was at the right time when the alarm rang.

Comment 1

[Johan Lorenzo [:jlorenzo]]

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/clock/js/panels/alarm/active_alarm.js#L83

Comment 2

[Marcus Cavanaugh [:mcav]]

Noting that we set 'ignoreTimezone' when scheduling alarms, which should cause mozAlarms to fire at the same local time regardless of timezone (an alarm at 8:30am should fire at 8:30am in whatever time zone you're currently in)[1].

[1] https://developer.mozilla.org/en-US/docs/Web/API/Alarm_API#Alarms_ignoring_time_zones

Comment 3

[Johan Lorenzo [:jlorenzo]]

Attachment: Clock logs

ignoreTimezone was set. But if I understand correctly and if I refer to the logs, the alarm should be triggered at 6:30am in whichever timezone. However, the alarm is displayed to be at 8:30am.

Comment 4

[Johan Lorenzo [:jlorenzo]]

[Blocking Requested - why for this release]: Shipping a device which sometimes can't handle time zones, is a problem that can annoy our end users.

Comment 5

[Mahendra Potharaju [:mahe]]

Basic functionality broken. Blocks 2.5

Comment 6

[Mahendra Potharaju [:mahe]]

Marcus, 

Can you please set a priority and owner for this bug?

Thanks

Comment 7

[Ken Chang[:kenkai]]

Tim, do you think if there is anything you can help for this bug?

Comment 8

[Tim Huang[:timhuang]]

I can help on this bug for sure. And I think we could try the patch on bug 1181489 first :).

Comment 9

[Mahendra Potharaju [:mahe]]

Setting a P1 priority.

Comment 10

[Ken Chang[:kenkai]]

According comment 8, since bug 1181489 has been fixed, please check if this bug still exists.

Comment 11

[Candice Serran (:cserran)]

(In reply to Ken Chang[:ken] from comment #10)
> According comment 8, since bug 1181489 has been fixed, please check if this
> bug still exists.

Ken, who should assigned owner be on this? Currently it says nobody

Comment 12

[Ken Chang[:kenkai]]

Tim can help take this bug first.

Comment 13

[Johan Lorenzo [:jlorenzo]]

I arrived in Mountain View yesterday, so I am able to test the timezone changes in real conditions.

However, I can't set an alarm on my dogfood due to bug 1208807. Combined with bug 1208808, all the alarms I set are not at the time I want to. 

Removing qawanted, while the dependency gets solved.

Comment 14

[Ken Chang[:kenkai]]

Is this bug a regression?

Comment 15

[Mahendra Potharaju [:mahe]]

Johan, 1208807 is set as part of backlog. Do you mean it should block 2.5 as 1208807 and 1180257 are dependent bugs?

Comment 16

[Johan Lorenzo [:jlorenzo]]

(In reply to Ken Chang[:ken] from comment #14)
Hard to know, time has always been an issue on Flame. 

(In reply to Mahendra Potharaju [:mahe] from comment #15)
Sorry, I forgot to update this bug, once we figured out bug 1208807 was partly dupe of others, and partly a feature. 

Now that I found a workaround to by pass bug 1208808, I'll try to reproduce this problem once I change of timezone, before next week.

Comment 17

[Andrew Sutherland [:asuth] (he/him)]

Based on how mozAlarms works, I don't think we need realism on the timezone change.  The only thing distinctive about a realistic time change is we would expect to potentially have _onTimezoneChanged and _onSystemClockChanged fire in rapid succession.  It appears it would be possible for a race to occur where a deemed-expired-on-reload alarm could fire twice instead of once in that case, but that would not describe the problems manifesting here.  Those problems are already covered by other bugs that are believed fixed.  Specifically:

Comment 0 describes bug 1181489, and comment 3 describes bug 1178208, both fixed.

Comment 18

[Johan Lorenzo [:jlorenzo]]

After a timezone change, every single of my 3 alarms was triggered at the right time on [1]. I am not the person who created the alarms mentioned in comment 0. Maybe some steps are missing. :padenot, is the time set automatically? Or did you change the timezone manually?

If you're in the second case, we're likely blocked by bug 1208808.

[1] Build ID               20151009104251
Gaia Revision          1609aecaba381c14eff95d5084e59280f53b7d8b
Gaia Date              2015-10-09 07:16:19
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/d01dd42e654b8735d86f9e7c723cc869a3b56798
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.naoki.20151007.074137
Firmware Date          Wed Oct  7 07:41:46 PDT 2015
Bootloader             s1

Comment 19

[Johan Lorenzo [:jlorenzo]]

(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #18) 
> If you're in the second case, we're likely blocked by bug 1208808.
I meant the first case.

Comment 20

[Paul Adenot (:padenot)]

I don't know for sure, I don't want to lead you on the a wrong path.

Comment 21

[Andrew Sutherland [:asuth] (he/him)]

Okay, then I think we can resolve this since the problem identified in the subject is fixed by bug 1181489, and everything else is tracked on other bugs, some of which are fixed.  I'm duping to bug 1181489 rather than resolving worksforme because we've had so many clock/alarms related issues that it seems helpful to have them clearly duped rather than requiring people to parse the bug comments.