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)
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
Reporter | ||
Updated•9 years ago
|
Whiteboard: qawanted
Reporter | ||
Updated•9 years ago
|
Comment 3•9 years ago
|
||
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)
Reporter | ||
Comment 4•9 years ago
|
||
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)
Comment 5•9 years ago
|
||
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)
Updated•9 years ago
|
Flags: needinfo?(ktucker)
Comment 6•9 years ago
|
||
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)
Comment 7•9 years ago
|
||
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
Reporter | ||
Comment 8•9 years ago
|
||
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.
Description
•