Closed Bug 1210190 Opened 6 years ago Closed 6 years ago
Alarm time created is displayed as a different time
When changing the time to create an alarm, at the clock app, the alarm time created is not the same as the time inputed. Repro Steps: 1) Update a Aries to 20150930115400 2) Go to Clock app to create an alarm. 3) Press on the upper right bell+ icon to create a new alarm. 4) Press the time bar, adjust the time by changing both hours and minutes. 5) Press OK, and note the time in the Time bar. Press Done at upper right. 6) Observe time of the newly created Alarm. Actual: Time inputted does not reflect the time displayed. Expected: The alarm time created is the same time displayed. Environmental Variables: Device: Aries 2.5 Build ID: 20150930115400 Gaia: 14a64f1ebd353bccc3f1c0399e1a01a03327749e Gecko: 97e537f85183ef31481602ab9e5587a6e7d16b4d Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 44.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 Repro frequency: (4/6) See attached: (video clip and logcat)
No Repro per Flame 2.2 When changing the alarm time, regardless of phone time, the input is displayed correctly for the alarm display. Environmental Variables: Device: Flame 2.5 Build ID: 20150930030225 Gaia: 1bc0b19527777ffee494962b48db4be857b07d64 Gecko: 891ee0d0ba3ec42b6484cf0205b3c95e21c58f74 Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd Version: 44.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Correction to the above comment/statement: No Repro per Flame 2.2 Environmental Variables: Device: Flame 2.2 BuildID: 20150930032502 Gaia: 5dd95cfb9f1d6501ce0e34414596ef3dd9c2f583 Gecko: 65ddad73ad6b Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 RESULTS: When creating an alarm, the time is displayed correctly at the alarm listing. Repro per Flame 2.5: Environmental Variables: Device: Flame 2.5 BuildID: 20150930030225 Gaia: 1bc0b19527777ffee494962b48db4be857b07d64 Gecko: 891ee0d0ba3ec42b6484cf0205b3c95e21c58f74 Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd Version: 44.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 RESULTS: When creating an alarm, the time is not displayed correctly at the alarm listing.
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage+]
Summary: [Aries][Clock] Alarm time created is displayed as a different time. → Alarm time created is displayed as a different time.
This looks weird. In the video, the clock (analog) is showing 2:15. The digital system clock in the statusbar is showing 9:15. It may be a result of bug 1208808. Reporter, can you tell me how the date/time/timezone data looks in the Settings>Date & Time when this bug happens?
The clock look weird every time I flashed Gaia (while doing the regression window of bug 1210234). I did repro the alarm not being set at the right time. I wonder if you don't need some time for the bug to pop up. I come to this conclusion because: * I left both my flame and aries on during the night (with both yesterday's build) and they were both showing the problem. * Once I started to flash my flame, I couldn't repro anymore * Once I rebooted my aries, it went away. * I changed the time zone a couple of time, and I got the right time, each time. Flashing gaia don't fully restart the phone, it just performs a stop/start b2g. I'll leave my devices on to see if it comes back again.
Zibi is right, this is related to bug 1208808. I played with the "Set automatically" button and I managed to get the clock in the state described in comment 0. My assumption about what happened with yesterday's build is that I moved both of my devices into the subway, and they have lost the cell connection and got it back.
For the record, I managed to be in that state by messing with timezone on the latest dogfood build. I wonder if that's not an old issue we just discovered, and calling this problem a dogfood blocker might be overstated. Mr Lee David, can you reproduce the problem that easily after a reboot? If so, do you have different results between an AT&T SIM card and a T-Mobile one? If I remember correctly they don't display the same timezone by default.  Build ID 20150817141354 Gaia Revision 60489c1ff8c5d1633fc4837d4f8019623d4e1940 Gaia Date 2015-08-16 02:21:48 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/a6eeb28458fd2652e12e57334f046b7776d75bb4 Gecko Version 43.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20150619.224059 Firmware Date Fri Jun 19 22:41:08 UTC 2015 Bootloader s1
There is a lot of talk about the alarm timezone issue in this bug and qawanted has been served on it so this is possibly a dupe of bug 1089494.
I don't think it's related to CET/CEST. This bug is showing 7 hour difference, not 1h.
1) There's something messed up after flashing the device. The times are completely off. nhirata-19333:b2g-distro nhirata$ adb shell date Fri Oct 2 08:05:41 EDT 2015 nhirata-19333:b2g-distro nhirata$ adb shell cat /system/build.prop | grep 'ro.build.date=' ro.build.date=Fri Oct 2 04:36:54 UTC 2015 2) There's something in the fTU that changes the time and timezone (the time zone one is filed). I noticed that if you set the time via command line during FTU and then go through the FTU then the time goes off: nhirata-19333:b2g-distro nhirata$ adb shell date Fri Oct 2 11:12:26 UTC 2015 nhirata-19333:b2g-distro nhirata$ adb shell date -s `date -j "+%Y%m%d.%H%M%S"` Fri Oct 2 11:12:35 UTC 2015 nhirata-19333:b2g-distro nhirata$ adb shell cat /system/build.prop | grep 'ro.build.date=' ro.build.date=Fri Oct 2 10:25:42 UTC 2015 3) Setting the timezone in the settings app correctly will yield : bug 1208807 4) Once you set the timezone in the settings app and then change the date to match that of your computer via adb shell data (on mac : adb shell date -s `date -j "+%Y%m%d.%H%M%S"` ) and reset the device, then it will have the correct time. We shouldn't have to do this... the time should get set appropriately via NTP...
Blocking 2.5 with a P2 priority. Need all clock issues fixed for 2.5 release.
blocking-b2g: 2.5? → 2.5+
Priority: -- → P2
This is a manifestation of bug 1208808, as noted by :gandalf in Comment 4.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1208808
You need to log in before you can comment on or make changes to this bug.