Closed Bug 1141258 Opened 9 years ago Closed 9 years ago

[Flame][Settings]The time zone change followed by turning on "Set automatically" changes to an incorrect time

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: njpark, Unassigned)

References

Details

STR:
Precondition: 'Set Automatically' is enabled, and Region: America, City: Toronto is set

- Open settings, open Date & Time
- Turn off 'Set Automatically', check the time is unchanged.
- Select Vancouver in the City list, press OK.

Expected:
The header time changes as well.
Actual:
The header time shows Toronto time, while the time shown on the page shows Vancouver time.

- Turn on 'Set Automatically'
Expected:
The time on the page is unchanged.
Actual:
The time is pushed back by an hour.

(Note: this was done on the day after the daylight saving time came to effect, if that makes any difference)

Version Info:
Gaia-Rev        fea83511df9ccba64259346bc02ebf2c417a12c2
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/eab4a81e4457
Build-ID        20150309010232
Version         39.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150309.043836
FW-Date         Mon Mar  9 04:38:47 EDT 2015
Bootloader      L1TC000118D0

QAwanted to see whether it repros on 2.1, 2.2
Whiteboard: qawanted
No longer depends on: 1100261
See Also: → 1100261
Blocks: 1140027
QA wanted for a branch check.
Keywords: qawanted
Whiteboard: qawanted
Unable to reproduce this issue on latest Flame 3.0 

Same time is shown on status bar and time & date page after following STR in comment 0. Were any unlisted steps performed? Device used had both cell data and wi-fi enabled, changed to America - Toronto in Date & Time settings, restarted phone, then performed STR as stated in comment 0.

Is more info available from reporter?

Device: Flame 3.0
Build ID: 20150326010205
Gaia: 8dc256a2de273be3abfa2cb2103d872d677834f7
Gecko: 37d3dcbf23a9
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
Flags: needinfo?(npark)
Actually, I cannot reproduce the first issue that I reported, but the 2nd one still reproduces:

- Turn on 'Set Automatically'
Expected:
The time on the page is unchanged.
Actual:
The time is pushed back by an hour.

I believe the first issue is fixed by Bug 1144713, Sorry about listing two anomalies in one bug.
Another thing is that I am located in Toronto, so that might change things a bit.  If you replace 'Toronto' with the city that you are currently in, and 'Vancouver' with the city that is 3 hours behind, you should be able to repro this.
Flags: needinfo?(npark)
I can't reproduce this issue. My STR:

1) With a SIM in the device, flash to today's 3.0 nightly
2) Progress past FTU without changing anything

- Note the time is incorrect because it defaults to New York time (and we're 3 hours behind)

3) Go to Settings > Date & Time > disable Set automatically > change City to Los Angeles (to get the correct time) > enable Set Automatically

- device is now in the correct time

4) Disable Set automatically > change Region to Pacific Ocean and City to Honolulu (the only City that's 3 hours behind from what this website tells me http://www.timeanddate.com/worldclock/?sort=2 )
5) Turn on set automatically again

- I observed that the device doesn't set to Honolulu time, instead it kept my correct current time which is set at step 3. I don't see my time being pushing back one hour.

----
Leaving qawanted for others to attempt.
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
Blocks: 1167848
See Also: → 1183092
Blocks: 1183092
Using the STR's from Comment I was not able to repro this issue.

However, instead of using Honolulu, I used Anchorage as the City to set a time, 
and switching between Automatic and manual the time presented was as expected. 

(0/10) Attempts NO Repro. 

Environmental Variables:
Device: Flame 2.6
BuildID: 20151202030236
Gaia: 7847a3c1b28e039631509978518b36fd3c5f9585
Gecko: 470f4f8c2b2d6f82e56e161a4b05262c85f55b59
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Environmental Variables:
Device: Flame 2.5
Build ID: 20151201163815
Gaia: 07462becf08f0c26ebd64daf89646e7403a336c5
Gecko: 33a575e711faf3344aa2e31ca2ea066b4cd8aafa
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a2 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

----
Leaving qawanted for another to attempt.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
No-Jun we've had 3 testers unable to reproduce this issue.  Are you still seeing this?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado) → needinfo?(npark)
Keywords: qawanted
I just rechecked this on aries, and this is no longer reproducing, seems like it is fixed.  thanks for reminding me!
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(npark)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.