Closed Bug 1053411 Opened 10 years ago Closed 9 years ago

Time not updated after setting timezone in first run

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog)

RESOLVED DUPLICATE of bug 1209892
tracking-b2g backlog

People

(Reporter: wlach, Unassigned)

Details

Attachments

(1 file)

I just flashed a new Flame device running 2.0 (using the latest tinderbox build). When I launched first run, the time was set to 6:00pm (~3 hours off). I selected "Toronto" as my timezone. I noticed after finishing first run that the time was still set to 3pm. I went into settings, saw that Toronto was selected, so that was a problem. Only by deselecting then selecting "Set time automatically" did the time go to what I would expect it to be. I would expect FirefoxOS to automatically synchronize time to the correct timezone after finishing first run.
[Blocking Requested]: This is pretty basic for a new phone to be able to set timezone appropriately. It's one of the main reasons for the FTU, so we should probably fix this. Let's find out where this regression happened.
blocking-b2g: --- → 2.0?
Dupe of bug 104979?
Flags: needinfo?(jsmith)
I think you meant to give me a different bug # here?
Flags: needinfo?(jsmith) → needinfo?(jmitchell)
sorry - dupe of bug 1049790 lost a 0 somewhere
Flags: needinfo?(jmitchell) → needinfo?(jsmith)
Might be a dupe of bug 1048154 potentially. Arthur - What do you think?
Flags: needinfo?(jsmith) → needinfo?(arthur.chen)
The root cause is probably the same (tz_select.js or gecko) but this bug is about setting time in FTU, I would prefer to track it with a separate bug.
Flags: needinfo?(arthur.chen)
I am unable to find a build in 2.0 that reproduces this issue as written. William can you provide the build id of the build you used to reproduce this issue so the QA Wanted team can try to reproduce this with that? Leaving the tag so others can try to reproduce. Here are the builds I tried. Engineering 2.0 Environmental Variables: Device: Flame 2.0 BuildID: 20140813070951 Gaia: e215fbf0cb16063b3d2f3e6a4e588c3550b6becb Gecko: 5490354af7dc Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Nightly 2.0 Environmental Variables Device: Flame 2.0 BuildID: 20140815000200 Gaia: 295c7f50707372e5af6d8e83148d2d970076dfd6 Gecko: 879c5208084f 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 2.0 BuildID: 20140813000201 Gaia: cade2fdbb2230670788dcf2fc7b100f4a37b6458 Gecko: a7c673dae1ed Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(wlachance)
I was able to find the build that the reporter was on. It's this build: https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-b2g32_v2_0-flame/20140813063004/ However I'm unable to reproduce the issue. Observed behavior: After factory resetting the phone via Settings > Device Information > More Information, the 4th screen on FTU is to set date/time. On this screen I see the default time is set to EST (New York), and I would set the City to Los Angeles in order for device to be set at PST. At this point the device is then set to the correct time - therefore unable to repro the issue. Bug repro rate: 0/5. With each attempt factory resetting the phone. Tested on: Device: Flame BuildID: 20140813063004 Gaia: e215fbf0cb16063b3d2f3e6a4e588c3550b6becb Gecko: 8e88a30eef43 Version: 32.0 (2.0) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ----- Removing window-wanted tag due to inability to reproduce the issue.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
I'm speculating that maybe the problem was that I selected the same time zone as the default city (New York): EST. Maybe if the phone is set to a *different* time zone, it works as expected?
Flags: needinfo?(wlachance)
Backlog for now. Please re-nom if reproducible.
blocking-b2g: 2.0? → backlog
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
blocking-b2g: backlog → ---
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: