1061797 - [Flame][Clock Time] After restarting the phone, the time and date displayed are wrong until there is a connection to the Internet

Status: RESOLVED DUPLICATE of bug 1110010

(Firefox OS Graveyard :: Vendcom, defect)

Description

[Ralph Daub [:rdaub]]

ENVIRONMENT:
Device:   Flame
Version:  2.0.0.0-prerelease
Build ID: 20140831000202

STEPS TO REPRODUCE:
1. Activate Airplane Mode to disable data and wi-fi connections.
2. Restart the device.

EXPECTED RESULTS:
The phone should remember the time and date from before - in my test, it should show September 2 @ 9:45am.

ACTUAL RESULTS:
The phone shows the wrong date and time - August 31 @ 10:43pm.


Once I deactivate Airplane mode, and the phone has data, the time and date are displayed correctly again.

Please let me know if there is any information I could provide to help with the investigation and troubleshooting of this issue.

Thanks!!

- Ralph

Comment 1

[Jason Smith [:jsmith]]

QA Wanted for branch checks.

Comment 2

[Chris Kreinbring [:CKreinbring]]

The bug repros on Flame 2.2, Flame 2.1, Flame 2.0, Flame 1.4, and Open C 2.2
Actual result:  Restarting the device after enabling airplane mode will cause the device to not show the proper time until the airplane mode is disabled.

Flame 2.2
BuildID: 20140903062451
Gaia: 52670853c17fc0d3d33065c667c0ce124c93b98f
Gecko: 5e9826980be5
Platform Version: 35.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.1
BuildID: 20140903085050
Gaia: fbb297c39aab5f17b179533d2a9a6c5166b2c197
Gecko: 31dad821234e
Platform Version: 34.0a2
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Flame 2.0
BuildID: 20140903060552
Gaia: d056733f8a7a1a152f5458b323f092c47dbffa48
Gecko: 5137a70489dd
Platform Version: 32.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4
BuildID: 20140903033752
Gaia: 2ee5b00bfbb8a67a967094804390b4afce8ecf54
Gecko: f5a75c0dd74e
Platform Version: 30.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Open C 2.2
BuildID: 20140903062451
Gaia: 52670853c17fc0d3d33065c667c0ce124c93b98f
Gecko: 5e9826980be5
Platform Version: 35.0a1
Firmware Version: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Comment 3

[Joshua Mitchell (Inactive)]

[Blocking Requested - why for this release]: not a regression but telling the time (properly) is one of the most quintessential tasks of any device.

Comment 4

[Brian Huang [:brianhuang][:brhuang]]

I also encounter this issue in 2.1 also.

STR:
1. restart device with wifi on and 3G on
2. after b2g is ready. the time is wrong. Can't find "Set automatically" switch.
3. Need to disable wifi and access web via 3G. Then date and time is correct.

Comment 5

[Jason Smith [:jsmith]]

QA Wanted to see if this happens with 2.0 with the KK image.

Comment 6

[Adam Alldredge [:AdamA][Inactive]]

I was unable to repro this issue in 2.0 on the KK base. When I restarted the phone with airplane mode on the time was off by a maximum of 5 minutes. I never observed the time being different by a manner of hours.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140908131505
Gaia: 59a670d40ad7f5966ec7fafcab0f05009bea97ab
Gecko: de70f9a40834
Version: 32.0 (2.0)
Firmware: V165
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Repro rate:
0/5

Comment 7

[bhavana bajaj [:bajaj]]

This is a JB issue and given the 2.0 is shipping on KK not blocking here and moving this out of blocking queue.

Comment 8

[Ralph Daub [:rdaub]]

Hi,

I was able to replicate this issue on a Flame device with KK base image and Master branch flashed. (KK Base image v180 + v2.2 flashed user build).

Is QA able to verify whether this is indeed still replicating on KK-based images? Thanks in advance for the help!

- Ralph

Comment 9

[Joshua Mitchell (Inactive)]

QA-Wanted to re-check KK Branch

Comment 10

[Pi Wei Cheng [:piwei] (inactive)]

I'm able to reproduce the issue on Flame 2.2 master, Flame 2.1, and Flame 2.0.

Observed behavior on Flame 2.1: After rebooting the phone with airplane mode turned on, the phone is in a date 3 days earlier and also in different time before rebooting. The date&time adjust itself to the correct ones when I disable airplane mode (data doesn't need to be turned on, and I didn't have wifi connection either).

Observed behavior on Flame 2.0 and Flame 2.2: After rebooting with airplane mode turned on, the time is about 6 hours earlier than it should but it's on the same date.

Device: Flame 2.2 Master (shallow/full flash, 319MB mem)
BuildID: 20141013042753
Gaia: 2a536e4df82410178d8440cc710d8f838a95a0b9
Gecko: 71edd80236b2
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Device: Flame 2.1 (shallow flash, 319MB mem)
BuildID: 20141010110704
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (shallow flash, 319MB mem)
BuildID: 20141013043753
Gaia: 21fc294d6c9b78997142153fc32c3175b4835a89
Gecko: 93530962cca3
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

-----------

This issue does NOT occur on Flame base image v180 only. Date and time continues to display correctly after rebooting the phone with airplane mode turned on.

Comment 11

[bhavana bajaj [:bajaj]]

(In reply to Pi Wei Cheng [:piwei] from comment #10)
> I'm able to reproduce the issue on Flame 2.2 master, Flame 2.1, and Flame
> 2.0.
> 
> Observed behavior on Flame 2.1: After rebooting the phone with airplane mode
> turned on, the phone is in a date 3 days earlier and also in different time
> before rebooting. The date&time adjust itself to the correct ones when I
> disable airplane mode (data doesn't need to be turned on, and I didn't have
> wifi connection either).
> 
> Observed behavior on Flame 2.0 and Flame 2.2: After rebooting with airplane
> mode turned on, the time is about 6 hours earlier than it should but it's on
> the same date.
> 
> Device: Flame 2.2 Master (shallow/full flash, 319MB mem)
> BuildID: 20141013042753
> Gaia: 2a536e4df82410178d8440cc710d8f838a95a0b9
> Gecko: 71edd80236b2
> Version: 35.0a1 (2.2 Master)
> Firmware: V180
> User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
> 
> Device: Flame 2.1 (shallow flash, 319MB mem)
> BuildID: 20141010110704
> Gaia: d18e130216cd3960cd327179364d9f71e42debda
> Gecko: 610ee0e6a776
> Version: 34.0a2 (2.1)
> Firmware: V180
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
> 
> Device: Flame 2.0 (shallow flash, 319MB mem)
> BuildID: 20141013043753
> Gaia: 21fc294d6c9b78997142153fc32c3175b4835a89
> Gecko: 93530962cca3
> Version: 32.0 (2.0)
> Firmware: V180
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> 
> -----------
> 
> This issue does NOT occur on Flame base image v180 only. Date and time
> continues to display correctly after rebooting the phone with airplane mode
> turned on.

Wesly, this does sound like a vendor bug. Can you help follow-up with T2M here ?

Comment 12

[Wesly Huang (EPM)]

Hi Pi Wei:

Would you help verify this again with v184 base image (FFOS 2.0)? If that works then try with Shallow flash to 2.1 & 2.2. (my hope is it works for them all)

The reason is, in v184 T2M has added a QCT fix to "remember" the time after restarting phone (which is intended to fix bug 1069863, though QA can still met this in some corner cases), thus I think in your case (doesn't set device time to some extreme one) this solution should be helpful.

Thank you.

Comment 13

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Wesly Huang from comment #12)
> Would you help verify this again with v184 base image (FFOS 2.0)? If that
> works then try with Shallow flash to 2.1 & 2.2. (my hope is it works for
> them all)

Test results:

v184 base-only - issue does NOT repro
v184 base + 2.1 - issue DOES repro. Phone boots up to a date yesterday with a wrong time
v184 base + 2.2 - issue DOES repro. Phone boot up to the correct day but wrong time

The results are the same as v180 tests.

2.1 & 2.2 environmental variables:
Device: Flame (shallow flash, 319MB mem)
BuildID: 20141015143144
Gaia: 477a9e61c3edf12f32a62a19d329cd277202cc6b
Gecko: 67573e422a0f
Version: 34.0 (2.1)
Firmware: v184
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame (shallow flash, 319MB mem)
BuildID: 20141016070843
Gaia: 5c636a7a54b2c86d8ff6bc1aa1e5f9594c7bc586
Gecko: 77f3ca1fe052
Version: 36.0a1 (2.2 Master)
Firmware: v184
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Comment 14

[Wesly Huang (EPM)]

Thanks PiWei, sorry I was not aware the status of v180 base image. Anyway to me it looks like no problem with vendor's SW image, and issue occurs once put new Gaia/Gecko above?

@Bhavana: what's your view about it? Per PiWei's v180/v184 result it's ok with vendor's release, and issue only seen after shallow flash 2.0/2.1/2.2.

Comment 16

[Julien Wajsberg [:julienw]]

I still have the issue in v188 base image (after v2.1 full flash on top of v188).

Comment 18

[Gabriela [:gaby2300]]

Connecting to Internet makes no difference in my case using v188 base image and 2.2 with today's OTA update, the time and date displayed are still wrong after restarting the phone.

Comment 19

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

B2G 2.2 20141101040202 on Flame (v188 base image)

There seems to be a dependency on the presence of a SIM card and the slot which it uses for this issue to reproduce:

No SIM card: FAIL, wrong time
1 SIM card in slot 1 ("3G"): PASS, time correct
1 SIM card (same as before) in slot 2 ("2G"): FAIL, wrong time
2 SIM cards: previously used in slot 1, new one in slot 2: FAIL, wrong time

But this should maybe treated as separate bug if that's only because the time gets fixed by time retrieval from the cellular network.

Comment 20

[jorge alves]

B2G 2.1 20141102001201 Flame (v180)

My strategy to keep the clock in sync is to always keep "Set Automatically" to false. After every reboot I go there, set it to on, let it sync, and then turn it off again. Any other way will get me a bad date/time (if I let in ON it will sync to some junk date). Maybe the use case of airplane-mode + "Set Automatically" OFF would be a good place to start fixing the issue of not persisting the clock?

Comment 24

[bhavana bajaj [:bajaj]]

(In reply to Wesly Huang from comment #14)
> Thanks PiWei, sorry I was not aware the status of v180 base image. Anyway to
> me it looks like no problem with vendor's SW image, and issue occurs once
> put new Gaia/Gecko above?
> 
> @Bhavana: what's your view about it? Per PiWei's v180/v184 result it's ok
> with vendor's release, and issue only seen after shallow flash 2.0/2.1/2.2.

Looks like the follow-up comments and the DUP's reported could point this to be a vendor issue. can you help follow-up ?

Comment 25

[Wesly Huang (EPM)]

Strange, after comment#14 all I see is issue repro. after shallow flash? 

qawanted to check if this can be seen in latest vendor release v188.

Comment 26

[Wesly Huang (EPM)]

Just to be clear, I would like to see it this can be repro. w/ "pure" vendor release, v188 base image. Thanks. keep ni on me for tracking.

Comment 27

[Cody Roesch [:croesch]]

Here are my results with the following 188 base image

Environmental Variables:
Device: Flame v188 Base
BuildID: 20141016183911
Gaia: 8c5c956ee6909408e29f375cc7d843a03d92f3d8
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Prerequisite: Time and location set manually in FTU after Flashing to the Base.

1. Disabled Wifi and Data
2. Enabled Airplane Mode
3. Power off the device
4. Set Test A,B or C. 
--------------------------
Test A: Power on with AT&T sim in slot 1:    RESULT - Pass (correct time and date)
Test B: Power on with AT&T sim in slot 2:    RESULT - Pass (correct time and date)
Test C: Power on with No sim card installed: RESULT - Pass (correct time and date)

***NOTES: I only got the correct results when Airplane mode was ENABLED. If i instead had wifi and/or Data enabled, Test C fails and shows the wrong time and date. However for this test I was trying to stick to the STR's provided by the reporter.

If you would like me to provide further results, please specify the scenario you would like run as there are many combos for time and date checking with various setups.

Comment 28

[Dietrich Ayala (:dietrich)]

There are a number of duplicates on bug 1021698 and bug 1069863 (which are both dupes of this bug, kinda) about *only* the Last Updated field in Settings.

That field is *not* updated from 1970 after connecting to the internets. Same bug as this one? Or different?

Comment 29

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Dietrich Ayala (:dietrich) from comment #28)
> That field is *not* updated from 1970 after connecting to the internets.
> Same bug as this one? Or different?

It's arguably the same bug because what's causing that field to be set to early 1970 is the following sequence:

- The phone starts up, the clock has been reset to the Epoch (1970-01-01T00:00:00Z)

- The update service confirms the application of an update thus needs to populate the "Last Updated" field; to do so it reads the clock

- The clock hasn't been set to the proper date yet, so the update service gets the 1970-ish date

- The update service stores this date in a pref so even when the clock is finally adjusted to the correct date, the wrong one will stick

If the clock value would be properly persisted between reboots we wouldn't have this issue hence I think it's safe to consider it a duplicate.

Comment 30

[Wesly Huang (EPM)]

Thanks Cody, then clear ni from me since test pass in base image and pls feel free to ni me again if we need support/fix from vendor.

Comment 31

[Gabriele Svelto [:gsvelto] (PTO)]

FYI I've been testing the v18D base image plus the current gecko+gaia nightly build and I can still reproduce this problem.

Comment 32

[Daniel Holbert [:dholbert]]

FWIW, this prevents users from logging in to any 2-factor-auth protected sites like Gmail, Facebook, Github, etc., because the authenticator protocol relies on having the correct time. If your phone has a bogus time, auth apps like https://marketplace.firefox.com/app/gauth-authenticator just generate incorrect codes, and users can't get past the login page.

(gsvelto mentioned this over on dupe bug 1069863 comment 12, but I thought it was important to bring up on this main bug as well.  I hit this issue myself while visiting family who live in a rural no-cell-service area over the holidays.)

Comment 33

[Martin Creutziger [:MMx]]

FWIW, the observation I just made:
after a nightly update my Flame was a few minutes ahead of time *although* WiFi connection was active and SIM2 registered to 2G network (no data there).
toggeling automatic time setting off and on again made it even *worse* - then it was almost 30min ahead of time.
After an additional reboot, everything was correct again (WiFi still active)

Comment 34

[shawn ku [:sku]]

ni myself for issue tracking.

Comment 35

[shawn ku [:sku]]

Hi Ralph:
 Could you please try to uncheck "Set automatically" from "Date & Time", and try your repo. STR again?

Note:
 "Set automatically" needs to be shown when device have NITZ or SNTP information.

Comment 37

[Ralph Daub [:rdaub]]

Hi Shawn Ku,

I tested it on Base Image v18D, and noticed that the "Set Automatically" is no longer displayed when the device is not connected to the Internet (no NITZ or SNTP information I'm assuming) - is there a bug number for this change? This behavior of a menu item "simply disappearing" without any explanation does not seem user friendly.

RESULTS:
v18D Base Image 
- Restarting the device KEEPS the time
- Unchecking "Set automatically" and restarting the device KEEPS the time
- Turning off WiFi and restarting the device KEEPS the time

V18D Base Image with latest v2.2.0.0-prerelease (BuildID 20150122002808)
- Restarting the device KEEPS the time
- Unchecking "Set automatically" and restarting the device KEEPS the time
- Leaving "Set automatically" unchecked, WiFi off, changing the time significantly, and restarting the device DOES NOT KEEP the time. The time reverts back to what it was prior to changing the time manually.

Additionally, there seems to me a small difference between the device's time and what is shown on Settings. On a few occasions, the "manually configured time" inside the Settings application was 1-minute ahead of the time shown in the notification bar. (see the screenshot in comment 37 below)

Comment 38

[Ralph Daub [:rdaub]]

Attachment: Time difference between Settings and Notification bar

Comment 39

[Mark Trompell]

(In reply to Ralph Daub [:rdaub] from comment #38)
> Created attachment 8553440 [details]
> Time difference between Settings and Notification bar

Something like this is discribed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1116091#c16 and following comments

Comment 40

[Ralph Daub [:rdaub]]

Shawn,

Do you know if there is a bug open for the behavior change in the "set time automatically", where that menu option disappears when there is no NITZ or SNTP information? Is this done on purpose, or was there any discussion behind this?

Comment 41

[shawn ku [:sku]]

(In reply to Ralph Daub [:rdaub] from comment #40)
> Shawn,
> 
> Do you know if there is a bug open for the behavior change in the "set time
> automatically", where that menu option disappears when there is no NITZ or
> SNTP information? Is this done on purpose, or was there any discussion
> behind this?

Ralph:
 The logic for show/hide "set time automatically" wasn't changed for a long period of time.
Setting AP observes the key - "time.clock.automatic-update.available" written by radioInterfaceLayer.js.
And Gecko will update the setting db by receiving NITZ or SNTP information.


Below seems a new issue which does not included in my radar. 
--------------------------------------------------------------
I will check it later.V18D Base Image with latest v2.2.0.0-prerelease (BuildID 20150122002808)
- Restarting the device KEEPS the time
- Unchecking "Set automatically" and restarting the device KEEPS the time
- Leaving "Set automatically" unchecked, WiFi off, changing the time significantly, and restarting the device DOES NOT KEEP the time. The time reverts back to what it was prior to changing the time manually.
--------------------------------------------------------------


Please file a bug for below case, and ni?[e-mail] to check.
--------------------------------------------------------------
Additionally, there seems to me a small difference between the device's time and what is shown on Settings. On a few occasions, the "manually configured time" inside the Settings application was 1-minute ahead of the time shown in the notification bar. (see the screenshot in comment 37 below)

Comment 43

[shawn ku [:sku]]

Per comment 37, it looks like original issue symptom is not there.
Please file a new bug for tracking the new issue be found.

Comment 44

[Ben Francis [:benfrancis]]

Still reproducing on a newly flashed v188 base image (latest publicly available image) + latest production 2.2 build for the Flame. Connecting to the Internet doesn't seem to make any difference.

I don't understand why we've shipped releases for our reference device which can't keep the time, but in my opinion we definitely shouldn't ship another one. This is a real dogfooding blocker.

What's the latest thinking on the cause of this bug?

Comment 45

[Julien Wajsberg [:julienw]]

Hey Ben, our latest available image is v18D (albeit not public yet -- I hope it will be soon), so it would make sense that you test with this image instead.

Comment 46

[Ben Francis [:benfrancis]]

Hi Julien, it would be great to hear whether v18D will fix this but I intentionally dogfood the latest publicly available build, otherwise it isn't dogfood.

Comment 47

[Gabriele Svelto [:gsvelto] (PTO)]

v18D still exhibits the same behavior.

Comment 48

[Ben Francis [:benfrancis]]

(In reply to Gabriele Svelto [:gsvelto] from comment #47)
> v18D still exhibits the same behavior.

Since v18D became public I just updated my dogfood device, and I can confirm this is the case :(

Gabriele, do you have any idea what the cause is?

Comment 49

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Ben Francis [:benfrancis] from comment #48)
> Gabriele, do you have any idea what the cause is?

I've spent a lot of time trying to figure it out in bug 1051083 but couldn't come up with a definitive answer. What came up in various discussions is that the Flame doesn't have a traditional battery-backed RTC clock and thus is unable to keep the time across reboots using normal means. To do so it uses the time taken from the modem instead via a vendor-specific blob which interfaces directly with Gecko via XPCOM. The said component isn't compatible with our current master (because of differences in the XPCOM interfaces it expects) and thus doesn't work correctly. :gerard-majax tried hacking our interfaces to make it run nevertheless but with little success.

Comment 50

[Michael Vines [:m1] [:evilmachines]]

(In reply to Gabriele Svelto [:gsvelto] from comment #49)
> The said component isn't
> compatible with our current master (because of differences in the XPCOM
> interfaces it expects) and thus doesn't work correctly. :gerard-majax tried
> hacking our interfaces to make it run nevertheless but with little success.

Bug 1110010 comment 21 contains a sketch of what Gecko proper is missing here.

Comment 51

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #50)
> Bug 1110010 comment 21 contains a sketch of what Gecko proper is missing
> here.

Thanks, I wasn't CC'd on that bug otherwise I'd have acted upon it.

Comment 52

[Ben Francis [:benfrancis]]

(In reply to Gabriele Svelto [:gsvelto] from comment #49)
> the Flame doesn't have a traditional battery-backed RTC clock and thus
> is unable to keep the time across reboots using normal means.

Aha! I have suspected this might be the case for a long time (I remember another device which had the same issue), but I had no idea how to test for it.

(In reply to Michael Vines [:m1] [:evilmachines] from comment #50)
> Bug 1110010 comment 21 contains a sketch of what Gecko proper is missing
> here.

Thanks Michael! Hopefully this is the key to a fix.

Comment 53

[Ralph Daub [:rdaub]]

I've been able to replicate this issue once again in the last two weeks. Running Flame Full Image v2.1 on top of Base Image v18D:

Gaia-Rev        e8eba437af02820f74d122aec83b6001df6f89e3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/9d04f9149ca4
Build-ID        20150217001459
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150213.035917
FW-Date         Fri Feb 13 03:59:27 EST 2015
Bootloader      L1TC000118D0

Comment 54

[Stephany Wilkes]

We were able to repro this easily on a Flame in B2G triage (like others have, above). Blocking on the relation between correct time display and account authentication noted in comment #32, as it prevents users from accomplishing tasks.

Comment 55

[Marek Antoži]

I can confirm that time is correct after phone restart when 188 base image with master build (currently 3.0.0.0-prerelease) shallow flashed over is used. I used nightly from February 17th.

Comment 56

[Julien Wajsberg [:julienw]]

Marek, if your wifi or gsm is enabled, then the time is synchronized by other means. Can you confirm you tried this with Internet disabled?

Comment 57

[Marek Antoži]

(In reply to Julien Wajsberg [:julienw] from comment #56)
> Marek, if your wifi or gsm is enabled, then the time is synchronized by
> other means. Can you confirm you tried this with Internet disabled?

Steps I took to reproduce:

1. turned off automatical time synchronization
2. set time by hand
3. turned airplane mode on
4. turned cell phone off for more than one hour
5. turned cell phone back on

After I turned the cell phone on, time was correct. I cannot confirm skew as I did not measure it.

Comment 58

[Marek Antoži]

Hello.

I am terribly sorry to announce that I am unable to reproduce the correct phone behavior I described here yesterday :-( For some kind of reason my phone stopped to be able to keep time over restarts. I do not know what caused it. Truth is I was setting time with "adb shell toolbox date" command instead of just setting it automatically or by hand from gaia. After that I tried to reset the phone, flash it again without restoring backed up data, but I was unable to reproduce correct behavior. :-(
Have no idea what happened.

Sorry.

-Marek

Comment 59

[Marek Antoži]

Hello.

First, let me applogize for spamming. Second, I was able to reproduce correct behavior today.

1. Flash phone with v188.
2. Get B2G source tree, repo sync, git pull for Gaia.
3. Run build.sh, flash.sh.
4. Turn off automatical time synchronization, set time by hand (probably adb shell toolbox date command would work too), set Airplane Mode on, turn phone off, take SIM card out.

After those steps when I turned phone off and on again, time was correct.

I even tried to shallow flash the phone with production nightly build I downloaded on February 17th. Time is still correct after powering the phone off and on.

Please tell me anyone else is able to reproduce this.

Regards.

-Marek

Comment 60

[howie [:howie]]

Hi Hsin-Yi, we may need your input here, thanks.

Comment 61

[howie [:howie]]

So, it works correctly now as Comment 59 menetioned, qawanted to check.

Comment 62

[Pi Wei Cheng [:piwei] (inactive)]

Changing title to better reflect the bug - it doesn't only affect 2.1; it's affecting all branches.

This issue still reproduces on latest master nightly engineering build.

What I did:
0) Phone has AT&T SIM card on slot 1
1) Base phone to v188 image
2) Shallow flash latest nightly master gaia + gecko on top
3) Progress past FTE without changing anything
4) Go to Settings > Date & Time > toggle off Set Automatically, change timezone to Pacific Time (default is Eastern Standard Time) > toggle ON Set Automatically again (observe time is now correct)
5) Turn on Airplane mode and reboot

- Observe time is wrong after reboot, though it is still on the same date.

I got the same result for full flashing with same STR.

It has been established that this occurs on v18D base image on previous comments as well.

Device: Flame 3.0 Master (shallow flash/full flash/319MB memory)
BuildID: 20150306010207
Gaia: 7a91c16bfa348be8b25e09719178efa051512988
Gecko: 0189941a3fd5
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (3.0 Master)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Comment 63

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Looks discussion and solution are on-going in bug 1110010.

Comment 64

[howie [:howie]]

Hi Hsin-Yi, so this one can be dup to bug 1110010 ?

Comment 65

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to howie [:howie] from comment #64)
> Hi Hsin-Yi, so this one can be dup to bug 1110010 ?

Yes, per my understanding, bug 1110010 also aims at "keeping time and date right after rebooting (remembering the time from before)." 
This sounds a duplicate to me.