Closed Bug 826285 Opened 12 years ago Closed 12 years ago

Use automatic detection off the phone to determine a correct default timezone in the FTE Date & Time screen

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-basecamp:-)

RESOLVED DUPLICATE of bug 873962
blocking-basecamp -

People

(Reporter: jsmith, Unassigned)

Details

(Whiteboard: testrun 2, interaction, UX-P2, leorun3)

In the date & time screen in the FTE: We should try to automatically detect what we think the user's timezone is and display that by default.
I’m not sure this is technically doable at the moment. I can think of two workarounds: • store a default timezone in the settings; • drop the timezone selection in the FTU app and rely on automatic date/time instead. It’s not an either/or, we could do both — and in my opinion, we /should/ do both. Remember that automatic date/time works fine in Brazil, whereas choosing a wrong timezone will create an offset in the time. Josh, sorry to bother you again with this but we badly need a UX decision here.
Flags: needinfo?(jcarpenter)
blocking-basecamp: --- → ?
We don't block, we don't want to enter into this complicated dev in the nexte couple of weeks.
blocking-basecamp: ? → -
(In reply to Fabien Cazenave [:kaze] from comment #1) > I’m not sure this is technically doable at the moment. I can think of two > workarounds: > • store a default timezone in the settings; > • drop the timezone selection in the FTU app and rely on automatic > date/time instead. > > It’s not an either/or, we could do both — and in my opinion, we /should/ do > both. Remember that automatic date/time works fine in Brazil, whereas > choosing a wrong timezone will create an offset in the time. Let's start by enabling partners to specify a default time zone. That seems like the biggest return on the least dev effort. Then we can look into auto config, either for this version or the next.
Flags: needinfo?(jcarpenter)
Last week I talked to Gene, the platform time automatic setting owner. From him I had learned that: 1. Currently automatic time setting is based on one of ril's feature. It is, if the user don't have a SIM card, even the setting is enabled on this, the time updating would fail. 2. Even ril works, you would ONLY get a timezone shift info like UTC+0800, instead of precise location string like `Asia/Taipei`. That's a limitation of this feature. We should either support update time from Wi-Fi(in the future...) or disable the setting if we could not get the ril function work(I don't know if the SIM Pin matters.) And we should learn the fact that get the `location` from this feature is not practical.
Whiteboard: testrun 2
Whiteboard: testrun 2 → testrun 2, interaction, UX-P2
The issue still reproduces on Leo device, The device doesn't automatically recognize a current time zone location, it's New York(EST) instead of PST Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/8e3f39363c54 Gaia: ce3b99781d182ad550a325206990c249b0dbcf0e Platform Version: 18.0
Whiteboard: testrun 2, interaction, UX-P2 → testrun 2, interaction, UX-P2, leorun3
Quick sum-up: • there’s no real timezone auto-detection; the best we can do at the moment is to propose a default timezone for each carrier — and for US carriers, we’re using New York by default, see bug 873962; • when NITZ is supported, I think it’s a major mistake to auto-define another timezone; that’s why it’s been proposed to remove the timezone selection panel in the FTE when NITZ is supported, see bug 826359. (In reply to Jason Smith [:jsmith] from comment #0) > In the date & time screen in the FTE: > We should try to automatically detect what we think the user's timezone is > and display that by default. This is what we do: we *try* to detect the timezone (bug 873962). We can’t do much more at the moment, but we’re trying to improve the situation with SNTP (see bug 878001). Closing as a duplicate, please have a look at bug 826359 and bug 878001 instead.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.