This started on one of my devices a couple of days ago. I've just checked my other device, and that also fails. STR --- 1) Have your device in manual mode for ages (due to bug 1032101). 2) Device suddenly decides to use incorrect time from a month ago. 3) Try and set the date and/or time. => Date & Time are set on the display 4) Reboot the device => Date & Time return to what they were. I also did this on a second device which was showing a correct time, and tried to change it to an incorrect time, and the same effects were seen. First device: v122 base image with 20140803160202, gaia rev 5fd14b8b Second device: v122 base image with 20140802040202, gaia rev 5fd14b8b

QA Wanted for branch checks.

This bug repro's on: Flame 2.1, Flame 2.0, Flame 1.4 Actual Results: Setting the Time and Date to Automatically [off], shows incorrect time. Setting the correct time then rebooting will result in previous wrong time being set again. Repro Rate: 5/5 Environmental Variables: Device: Flame Master Build ID: 20140807084328 Gaia: 54c3c19d439f7dbafda5c6cc3b4850b545a068ba Gecko: 2f198e81ed98 Version: 34.0a1 (Master) Firmware Version: v123 ------------------------------------------------ Environmental Variables: Device: Flame 2.0 BuildID: 20140807215456 Gaia: 8d4599d18fbfc41f88ea494ab9cce0bb99cffac3 Gecko: aad73d079368 Version: 32.0 (2.0) Firmware Version: v123 ------------------------------------------------ Environmental Variables: Device: Flame 1.4 Build ID: 20140808033135 Gaia: 2b2849a61cd38e909ed1c3e4586d104bc96f7001 Gecko: 931bf8651711 Version: 30.0 (1.4) Firmware Version: v123 ------------------------------------------------ ------------------------------------------------ This bug does NOT repro on: Buri 2.1 Actual Result: Setting the Time and Date to Automatically [off], shows correct time. Setting the correct time then rebooting will keep the correct time. Repro Rate: 0/5 attempts Environmental Variables: Device: Buri Master BuildID: 20140806134618 Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f Gecko: a31cd48facbf Version: 34.0a1 (Master) Firmware Version: v1.2device.cfg

not a regression - based on those branch checks

[Blocking Requested - why for this release]: nomming for 2.0 because this is a pretty bad bug - we should never lose data that the user is intentionally setting themselves. High level of user frustration.

(In reply to Joshua Mitchell [:Joshua_M] from comment #3) > not a regression - based on those branch checks Err, this *used* to work, certainly as of a month or two ago. Otherwise I'd have never been able to set the time correctly (bug 1032101 has always caused automatic mode to have the wrong time for me).

QA Wanted to double check the branch checks per comment 5.

This issue DOES occur on the latest 2.1 Flame, 2.0 Flame, and 1.4 Flame. Manually setting the time only lasts until the phone is restarted. Environmental Variables: Device: Flame Master BuildID: 20140808131609 Gaia: 2d2475b521351e200136e463358e6c8e91957702 Gecko: 08bfcc7c6789 Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Environmental Variables: Device: Flame 2.0 BuildID: 20140808095913 Gaia: 4c8c6569f2fded3c610cb6baf2e86355b1004653 Gecko: 45fb39baedc6 Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Environmental Variables: Device: Flame 1.4 BuildID: 20140808033135 Gaia: 2b2849a61cd38e909ed1c3e4586d104bc96f7001 Gecko: 931bf8651711 Version: 30.0 (1.4) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 This issue does NOT occur on the latest Buri 2.1. The time setting persists. Environmental Variables: Device: Buri Master BuildID: 20140806134618 Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f Gecko: a31cd48facbf Version: 34.0a1 (Master) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

after some spot-checking I can conclude that everyone is correct - The branch checks were correct - Mark is correct - this is a regression and 'used to work' I found the following: 20140620094247 - can set correctly but not correct after restart *20140627063530 - can set correctly - persists after restart 20140708061447 - can set correctly but not correct after restart *so we can see that at one point this was broken and then fixed (or at least 'working') and then broke again

Unable to find a regression window due to the bug occurs to earliest Flame central build (20140417000006) that we have available. The phone ALWAYS reboots to a date/time in January 1970 with a central Flame build. But with only base image v122 or v123, the bug does NOT repro. So the regression occurred in between a date that we can't find. Comment 8 mentioned build ID 20140627063530 did not reproduce the bug which is NOT true. I've tried multiple times and it does reproduce the bug. To avoid confusion, I'm writing down what I did: 0) A SIM card is present in the Flame 1) Flash a Flame central Gaia+Gecko build on top of v122 or v123 gonk. 2) Progress through FTU/FTE without changing any settings on it. 3) Unplug the phone from USB (so it does not influence the reboot later) 4) Go to Setting > Date & Time > un-toggle Set Date & Time Automatically, and manually set time to current time. 5) Long press power button and select Restart. - observe the time goes to sometime in January 1970 after reboot.

Unfortunately I do not seem to be able to repro my one instance of a "working" build. I've used the same device and set-up as before and not gotten a repro (of it working - 0/15 tries). Either I was incorrect in my findings initially or the 'working' is incredibly intermittent. I'm leaving the regression tag alone but without a solid 'working build' (which we have looked around for but have not been able to find) we will not be able to do a regression-window.

I've been researching this bug and it's funny because when you try to change the date manually twice, it works. Only fails the first time you try to change it. So I'm going to make a deep research. If anyone has any ideas...you're welcome

Hi Arthur, I'm trying to solve this bug but I don't understand how the automatically date feature works. It seems when you toggle "Set automatically" on Settings/Date&Time panel, a "moztimechange" event is thrown twice and I don't really know where the system is setting the new date time. Could you explain me how it works? Thanks!

(In reply to Manuel Casas Barrado [:mancas] from comment #12) > I've been researching this bug and it's funny because when you try to change > the date manually twice, it works. Only fails the first time you try to > change it. This doesn't work for me currently for either of my phones - although I've had them in manual mode for a couple of months now, so maybe that's different (it actually sounds a bit like what was seen in bug 1032233). I'm willing to try re-flashing one or both of them, if you want me to do specific tests, feel free to drop me a line over irc or email.

Manuel Casas Barrado, since you're looking at this bug, would you mind taking the ownership on this bug? Thanks.

(In reply to Kevin Hu [:khu] from comment #15) > Manuel Casas Barrado, since you're looking at this bug, would you mind > taking the ownership on this bug? Thanks. Sorry, it seems I forgot to save changes

Hi Manuel, as the issue is related to the gecko so I'm not able to provide more useful information. From gaia we simply set the key "time.clock.automatic-update.enabled" and then gecko determine the time by itself.

(In reply to Arthur Chen [:arthurcc] from comment #17) > Hi Manuel, as the issue is related to the gecko so I'm not able to provide > more useful information. From gaia we simply set the key > "time.clock.automatic-update.enabled" and then gecko determine the time by > itself. Ok, thanks Arthur. I think there is a bug in a Gecko deamon because when you toggle "Set automatically switch" only an API call is done. But if you disabled this option and set a date/time manually, the new date is updated, however, if you enabled again the "set automatically button", two API calls are done. This cause an overlapping in the calls and the result is a wrong date. If you want to reproduce this, follow this steps: 1. Go to settings/Date&time panel 2. Disable "Set automatically" 3. Set manually a new date or time 4. Enable "Set automatically" 5. See a wrong date Following the trace, a moztimechange event is throw two times, once you set up manually a date.

Discussed this with :fabrice and he can look at this issue, but the comments here seem confusing on if this is reproducible consistently. Can we please try with the latest base image available to confirm this regression ?

I wonder if bug 1032233 comment #13 and following are related to this.

(In reply to bhavana bajaj [:bajaj] from comment #19) > Can we please try with the latest base image available to confirm this regression ? Comment 9 is still true in latest build with v123 base. Bug repro rate: 2/2 Tested on: Device: Flame BuildID: 20140819054116 Gaia: b33b4d9558e0b9eabbfda7be23435e2b38fd40bf Gecko: a38daccaa557 Version: 34.0a1 (2.1 Master) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Maybe Aus can help out here?

I'll take a look at this ASAP!

Potentially useful extra information I sent to Manuel just over a week ago: - I flashed v123 of the base image (using the gecko+gaia it installs), and set it up without wifi and without a data connection (to avoid issue of automatically set date & time getting in the way). => Changing the date, powering off & starting up again KEPT the date change - Then I did a shallow flash of Gaia and Gecko for latest master, again no wifi, no data connection => Changing the date, powering off & starting up again LOST the date change - returning to the original date and time.

(In reply to Mark Banner (:standard8) from comment #25) > Potentially useful extra information I sent to Manuel just over a week ago: > > - I flashed v123 of the base image (using the gecko+gaia it installs), and > set it up without wifi and without a data connection (to avoid issue of > automatically set date & time getting in the way). > > => Changing the date, powering off & starting up again KEPT the date change > > - Then I did a shallow flash of Gaia and Gecko for latest master, again no > wifi, no data connection > > => Changing the date, powering off & starting up again LOST the date change > - returning to the original date and time. That's is hugely useful! Thanks Mark!

This is most likely a bug with the v122 or v123 base image. One doesn't even need b2g to reproduce this. STRs: 1. Boot up phone, connect via adb shell, stop b2g process (you can hack the scripts to skip starting b2g automatically). 2. Set date ('date -s 20140825', for example). 3. Reboot (from shell, 'reboot'). 4. As soon as device starts booting up and you can connect via adb shell, look at the date using 'date'. You'll notice it reset itself to what is essentially a timestamp of '0'.

QA Wanted to see if this reproduces with the kitkat image.

(In reply to Ghislain Aus Lacroix [:aus] from comment #27) > This is most likely a bug with the v122 or v123 base image. > > One doesn't even need b2g to reproduce this. > > STRs: > > 1. Boot up phone, connect via adb shell, stop b2g process (you can hack the > scripts to skip starting b2g automatically). > 2. Set date ('date -s 20140825', for example). > 3. Reboot (from shell, 'reboot'). > 4. As soon as device starts booting up and you can connect via adb shell, > look at the date using 'date'. > > You'll notice it reset itself to what is essentially a timestamp of '0'. Oh great Obi Wu Kenobi, does this sound more like a hardware or driver bug to you?

> This is most likely a bug with the v122 or v123 base image. Confirmed that v122 *and* v123 exhibit the same issue. 'date -s' always fails to set the time so that it is preserved after reboot.

I was unable to reproduce this issue on the v165 KitKat Base image.

Smoketest blocker on v123 base from duplicate bug 1057589.

(In reply to Ghislain Aus Lacroix [:aus] from comment #30) > > This is most likely a bug with the v122 or v123 base image. > > Confirmed that v122 *and* v123 exhibit the same issue. 'date -s' always > fails to set the time so that it is preserved after reboot. Moving to vendcom per proof of this being a vendor bug & adding needinfo on Francis to get someone from T2M to take a look.

(In reply to Ghislain Aus Lacroix [:aus] from comment #27) > This is most likely a bug with the v122 or v123 base image. > > One doesn't even need b2g to reproduce this. > > STRs: > > 1. Boot up phone, connect via adb shell, stop b2g process (you can hack the > scripts to skip starting b2g automatically). > 2. Set date ('date -s 20140825', for example). > 3. Reboot (from shell, 'reboot'). > 4. As soon as device starts booting up and you can connect via adb shell, > look at the date using 'date'. > > You'll notice it reset itself to what is essentially a timestamp of '0'. This isn't supported, unfortunately. QC hardware has its own special way to set time, which gecko has support for if you have the right extension in gecko. The date command, on the other hand, doesn't use this special API, so dates set via the command won't work. Set the date via the settings app and it should work.

Ok. I know what's happening, but I need to reach out to QC. Stay tuned.

(In reply to Michael Wu [:mwu] from comment #35) > (In reply to Ghislain Aus Lacroix [:aus] from comment #27) > > This is most likely a bug with the v122 or v123 base image. > > > > One doesn't even need b2g to reproduce this. > > > > STRs: > > > > 1. Boot up phone, connect via adb shell, stop b2g process (you can hack the > > scripts to skip starting b2g automatically). > > 2. Set date ('date -s 20140825', for example). > > 3. Reboot (from shell, 'reboot'). > > 4. As soon as device starts booting up and you can connect via adb shell, > > look at the date using 'date'. > > > > You'll notice it reset itself to what is essentially a timestamp of '0'. > > This isn't supported, unfortunately. QC hardware has its own special way to > set time, which gecko has support for if you have the right extension in > gecko. The date command, on the other hand, doesn't use this special API, so > dates set via the command won't work. Set the date via the settings app and > it should work. Ah, that's good to know! However, I think it's the same root issue that's occurring. The call itself to set the time fails so when the device restarts the time is lost.

Unblocking this for being a vendor bug.

The workaround in bug 1057589 comment 17 works for me. However, I suggest that we keep this bug open until this is publicily available on https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame#Updating_your_Flame%27s_software in either workaround form, or in a fresh release.

I have this issue in 2.0 and 2.1 with base image 123. It happens every time I reboot or power off my Flame.

Firefox OS is not being worked on