Sxean Lee-David [:sxean] Reporter
	Description • 9 years ago

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)

	Sxean Lee-David [:sxean] Reporter
	Comment 1 • 9 years ago

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

	Sxean Lee-David [:sxean] Reporter
	Comment 2 • 9 years ago

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.

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 3 • 9 years ago

[Blocking Requested - why for this release]:

	Zibi Braniecki [:zbraniecki][:gandalf]
	Comment 4 • 9 years ago

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?

	Johan Lorenzo [:jlorenzo]
	Comment 5 • 9 years ago

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.

	Johan Lorenzo [:jlorenzo]
	Comment 6 • 9 years ago

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.

	Johan Lorenzo [:jlorenzo]
	Comment 7 • 9 years ago

For the record, I managed to be in that state by messing with timezone on the latest dogfood build[1]. 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.


[1] 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

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 8 • 9 years ago

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.

	Zibi Braniecki [:zbraniecki][:gandalf]
	Comment 9 • 9 years ago

I don't think it's related to CET/CEST. This bug is showing 7 hour difference, not 1h.

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 10 • 9 years ago

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...

	Mahendra Potharaju [:mahe]
	Comment 11 • 9 years ago

Blocking 2.5 with a P2 priority. Need all clock issues fixed for 2.5 release.

	Marcus Cavanaugh [:mcav]
	Comment 13 • 9 years ago

This is a manifestation of bug 1208808, as noted by :gandalf in Comment 4.