847342 - [Buri][NITZ]The UI Time zone information should be shown and kept (when switching from automatic to manual)

Status: VERIFIED FIXED

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

Description

[sync-1]

Firefox v1.0.1,  build identifier： 20130228114642
 
 +++ This bug was initially created as a clone of Bug #414259 +++
 
 DEFECT DESCRIPTION:
 (1)When the automatic time update is activated, the time&date&timezone information will be hided. NOK1 
 
 (2)When deactivate the automatic time update, we will find the TIME&DATA information is correct shown and editable, but not the TIME zone info. All of the region and city are "Empty" --- NOK2
 
 REPRODUCING PROCEDURES:
 
 EXPECTED BEHAVIOUR:
 NOK1,This is not friendly to the end user. Could we still display such information to end user, just don't permit him to edit them?  Otherwise, The end user will never know the TIME zone info at all.
 
 NOK2, Please keep the current time zone(got from NITZ), and display it to end user.
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 
 REPRODUCING RATE:
 
 For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #414259 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
 DEFECT DESCRIPTION:
 
 REPRODUCING PROCEDURES:
 
 EXPECTED BEHAVIOUR:
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 
 REPRODUCING RATE:
 
 For FT PR, Please list reference mobile's behavior:

Comment 1

[buri.blff]

Attachment: screenshot

Checked on the latest version. It will always display the first region and first city in the list, if we change back to Manual. This is really not acceptable.

At least the NOK2 is blocking issue. Please help checking.

Comment 2

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

I believe NOK1 is per design. 
For NOK2, I agree it would be nice to transfer the timezone information that we obtained from NITZ here but is that really a blocker.  Why?  I would not expect this to be an operation that users perform often.

Although in the process of looking at this, I found bug 853152 that seems more severe.  Feel free to nominate that if this would be consider blocking as well.

Comment 3

[buri.blff]

while, if we keep NOK2 behavior,we will never be able to know whether the NITZ function is fully working well.Because we have no means to check current time zone.And it is a more reasonable behavior for end user.

and for the pr you mentioned,if the nok2 is fixed,that pr will get benefit. as at least it will change to right time zone by nitz, seems normal behavior. not like current behavior,every time you change to manual mode,it just display the a.../a... one by default.

Comment 4

[Andrew Overholt [:overholt]]

Josh, can we get some UX input as to the design here?

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

triage: tef+ as this creates confusion to users when switching from automatic to manual. time is correct but timezone is incorrect but supposedly timezone should change time so in this case it is confusing

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

evelyn, can you take a look at this initially? thanks

Comment 7

[Evelyn Hung]

Rudy, can you help on this?

Comment 8

[Alex Keybl [:akeybl]]

Please make sure to design a solution here without string changes. If string changes are needed, please change blocking-b2g to tef?, add the late-l10n keyword, and CC [e-mail]. Any string changes would delay l10n complete by ~2 weeks.

Comment 9

[Evelyn Hung]

Redirect to Rudy, he can help. Thanks!!

Comment 10

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi all,

1. For NOK1, we would need UX input on this, since the current implementation follows the spec.
See p.17 of http://people.mozilla.com/~lco/Settings_B2G/Release_1_Specs/R1_Personalization_v3.pdf

2. For NOK2, the time zone part, AFAIK, what we get from NITZ is just a time offset, could be converted to UTC + x, instead of the region/area info.
However, on the settings UI, we would show the region of the time zone and there is no direct mapping from the time offset to the region.
   One possible way to deal with this is to show one of the region that has the same time offset as we got from NITZ, but I think this would be confusing, too.

[+cc Larissa]
Hi Larissa,

Would you have any comments to guide us on NOK1?
Thank you.

Comment 11

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi all,

For NOK2, here is another proposal,
 1. Only show the time offset, like UTC+8 when the user change the mode to "manual".
 2. When the user clicks on the time offset, show the region selection UI as the current implementation of settings app.

Thank you.

Comment 12

[Daniel Coloma:dcoloma]

NOK1: I do not think this must be changed.

NOK2: Is there any way to show the latest region/area the user selected manually?

   E.g. User firstly configures manually area to Europe/Madrid, then he changes setting to automatic and the new area is, for instance, Europe/London. When changing the setting back to manual, Europe/Madrid is put back as the area.

   If no previous manual configuration was done, the solution suggested in comment 10 may not be perfect, but should suffice to address partner concerns.

Comment 13

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Daniel Coloma:dcoloma from comment #12)
> NOK1: I do not think this must be changed.
> 
> NOK2: Is there any way to show the latest region/area the user selected
> manually?

Yes, I think we could keep that user-selected time zone separately in our settings, say, "time.timezone-user-selected".
However, I am afraid this won't address the issue when the user try to set the time zone for the first time, right?
Because the default setting for time update is currently set as "auto", and there will be no default value for "time.timezone-user-selected".

Is it OK we ignore the case for the first time?
Thank you.

Comment 14

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi all,

Now we are trying to at least show the first "time zone region" that matches the same time offset. (See Comment 10)

For this to work, we have to know the format that Gecko may set into "time.timezone" of mozSettings.

From my test, when NITZ is not available, it might be set as: 
CST-08 

And so far I could not get NITZ to work, so not sure what format it will be in with NITZ.

Hi Gene,

Could you please help confirm the format we should follow?
Thank you.

Comment 15

[Gene Lian (I already quit Mozilla)]

(In reply to Rudy Lu [:rudyl] from comment #14)
> Hi Gene,
> 
> Could you please help confirm the format we should follow?
> Thank you.

Fire bug 857545 to ensure the time.timezone is uniformly in the format of a UTC string representation.

Comment 16

[Josh Carpenter [:jcarpenter]]

Late response (was on PTO when this came through). 

(In reply to sync-1 from comment #0)

>  DEFECT DESCRIPTION:
>  (1)When the automatic time update is activated, the time&date&timezone
> information will be hided. NOK1 
>
> . . .
> 
>  EXPECTED BEHAVIOUR:
>  NOK1,This is not friendly to the end user. Could we still display such
> information to end user, just don't permit him to edit them?  Otherwise, The
> end user will never know the TIME zone info at all.

Agreed. When set to "Automatic" we should show the date and time in a non editable format. I agree with Daniel that this probably is not a blocker, but it should be resolved at some point. Flagging for UX follow up.

Comment 17

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

This issue depends on Bug 857545.
Gene and I are going to finalize the way how Gecko expose time offset to Gaia.
So that we could do the mapping from offset to region/city.

The mapping code in Gaia is almost done and should be able to land after Bug 857545 is landed and verified.

Thanks.

Comment 18

[Alex Keybl [:akeybl]]

Daniel - the solution for this bug is getting complex (see https://bugzilla.mozilla.org/show_bug.cgi?id=857545#c15). Does that change your calculus at all for whether or not this blocks 1.0.1?

Comment 19

[Daniel Coloma:dcoloma]

(In reply to Alex Keybl [:akeybl] from comment #18)
> Daniel - the solution for this bug is getting complex (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=857545#c15). Does that change
> your calculus at all for whether or not this blocks 1.0.1?

If it becomes risky what we should do is just do the first part of comment 12:


DO:

NOK2: Is there any way to show the latest region/area the user selected manually?

   E.g. User firstly configures manually area to Europe/Madrid, then he changes setting to automatic and the new area is, for instance, Europe/London. When changing the setting back to manual, Europe/Madrid is put back as the area.

NOT DO:

   If no previous manual configuration was done, the solution suggested in comment 10 may not be perfect, but should suffice to address partner concerns.

Comment 20

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi all,

Then I think we can introduce another setting key, named "time.timezone.user-selected" to record the timezone the user selected manually.

A patch is on the way.
Thank you.

Comment 21

[Gene Lian (I already quit Mozilla)]

(In reply to Rudy Lu [:rudyl] from comment #20)
> Hi all,
> 
> Then I think we can introduce another setting key, named
> "time.timezone.user-selected" to record the timezone the user selected
> manually.

I don't like the approach at all. It sounds very weird to me to create another setting key |time.timezone.user-selected|. If the user has manually *selected* a timezone for sure, it means the system timezone should reflect on that.

Comment 22

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Gene,

Yes, the system timezone should be affected as well.
Let me elaborate what I want to do here,
When the user selects a specific timezone, say "Taipei", this value would be set in both "time.timezone" and "time.timezone.user-selected".

time.timezone should work as the original design.
time.timezone.user-selected is used to store the value so that when time.timezone is updated (with NITZ) as time offset (say UTC-08:00), we could still get the value from time.timezone.user-selected.

Hope I make myself clear.
Thank you.

Comment 23

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9138

Pointer to Github pull-request

Comment 24

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 736748 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9138

This patch includes a change to keep the user selected time zone in a separate setting entry.
Please refer to the above comments for more details.

Hi Eve,

Could you please review this one?
Thanks.

Comment 25

[Gene Lian (I already quit Mozilla)]

(In reply to Rudy Lu [:rudyl] from comment #22)
> time.timezone is updated (with NITZ) as time offset (say UTC-08:00)
                                                      ^^^^^^^^^^^^^^^
So do you still want the platform to specify the DST part? Like the format I propose at bug 857545, comment #17?

Comment 26

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

(In reply to Gene Lian [:gene] from comment #25)
> (In reply to Rudy Lu [:rudyl] from comment #22)
> > time.timezone is updated (with NITZ) as time offset (say UTC-08:00)
>                                                       ^^^^^^^^^^^^^^^
> So do you still want the platform to specify the DST part? Like the format I
> propose at bug 857545, comment #17?

No, the current patch does not need toe format change to work.
Thank you.

Comment 27

[Daniel Coloma:dcoloma]

Can we then remove the dependency on bug 857545, right?

Comment 28

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi Daniel, 

Yeah, we could do that.
Thanks for the reminding.

Comment 29

[Evelyn Hung]

Comment on attachment 736748 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9138

The patch looks good, but there is one thing not being defined:
When user switch from auto to manually, the manual selection panel shows latest region/area the user selected, but the timezone doesn't actually switch to that timezone. Is it what we want? I feel confused about that inconsistent UI.

clear review flag and wait for the question being addressed.

Comment 30

[Daniel Coloma:dcoloma]

(In reply to Evelyn Hung [:evelyn] from comment #29)
> Comment on attachment 736748 [details]
> Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9138
> 
> The patch looks good, but there is one thing not being defined:
> When user switch from auto to manually, the manual selection panel shows
> latest region/area the user selected, but the timezone doesn't actually
> switch to that timezone. Is it what we want? I feel confused about that
> inconsistent UI.
> 
> clear review flag and wait for the question being addressed.

We should also change the TZ, this is what other devices do. Is that feasible?

Comment 31

[Evelyn Hung]

(In reply to Daniel Coloma:dcoloma from comment #30)
> (In reply to Evelyn Hung [:evelyn] from comment #29)
> > Comment on attachment 736748 [details]
> > Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9138
> > 
> > The patch looks good, but there is one thing not being defined:
> > When user switch from auto to manually, the manual selection panel shows
> > latest region/area the user selected, but the timezone doesn't actually
> > switch to that timezone. Is it what we want? I feel confused about that
> > inconsistent UI.
> > 
> > clear review flag and wait for the question being addressed.
> 
> We should also change the TZ, this is what other devices do. Is that
> feasible?
Rudy, does it make sense to you? If yes, please update the patch and change TZ to be consistent with what UI shows, and then ask my review again. Thank you.

Comment 32

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 736748 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9138

The patch has been updated to address Comment 31.

Dear Eve,

Could you please have a check?
Thank you.

Comment 33

[Kai-Chih Hu [:khu]]

Talked with Evelyn and she is working on it.

Comment 34

[Evelyn Hung]

Comment on attachment 736748 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9138

r=me, tested it works well. Thanks.

Comment 35

[Evelyn Hung]

Merged into gaia-master.
https://github.com/mozilla-b2g/gaia/commit/40d6e1385b8abc1e80a6d5723c7be0132da16c0f

Comment 36

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9306

Pointer to Github pull-request

Comment 37

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 739470 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9306

Hi Eve,

Sorry that the previous commits break the lint check.
Please help review this fix.

Thank you.

I did not open another bug to hope this fix could be uplifted together.
Let me know if any concerns.

Comment 38

[Evelyn Hung]

Comment on attachment 739470 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9306

r=me, sorry I didn't pick out the lint error before.

Comment 39

[Evelyn Hung]

merged into gaia master:
https://github.com/mozilla-b2g/gaia/commit/dd796c4e0356514eee4fe423ddc24fc5a8a94213

To someone who does uplift:
This patch includes two commits on gaia-master(see comment 35 and comment 38). Sorry for the inconvenience.

Comment 40

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Gaia v1.0.1:
c4d75d9cdf96348af73c26698b56f23c72a6dfe4

Gaia v1-train:
ffc6ac77647bdbe178fabdf77e6d166ac2526508

Evelyn,

Thanks for the review.

Comment 41

[Sreenidhi]

Tested on a Buri with the following build information :

Gaia   63c3b1d463c142c4aa7aa88b5ee3d173d1edbbc6
BuildID 20130426200111
Version 18.0

Issue (Not able to edit time zone) is not reproducible. Henceforth, changing the status to 'Verified'.

Comment 42

[Jeni]

Verified fixed on 

Inari Build ID: 20130430070201
Kernel Date: Feb 21
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/010498e599a7
Gaia: de0f1fc6c58616b8a33fca482f1f8684d4e74e9e

Comment 43

[Cody Roesch [:croesch]]

Unable to test on the Buri device. Marking as QARegressExclude.

Comment 44

[sync-1]

Hi,we want when disactive NITZ,the zone&time&data is also displayed.And the zone is keep the data which got from NITZ.Thank you.

Comment 45

[sync-1]

Hi,how about this bug?Could you have any plan to fix this?

Comment 46

[Al Tsai [:atsai]]

I thought the bug is verified by Mozilla side and set as verified.
Please check with the newest build you got and verify it.
If it's not fixed, file a new bug for fixing. Thanks.

Comment 47

[sync-1]

 (In reply to comment #44)
 > Comment from Mozilla:I thought the bug is verified by Mozilla side and set as
 > verified.
 > Please check with the newest build you got and verify it.
 > If it's not fixed, file a new bug for fixing. Thanks.
 > 
 Version:
 AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.094
 Firefox os  v1.0.1
 Mozilla build ID:20130502070201
 
 I test on this version,but there do not occur expected behaviour.
 NOK1,This is not friendly to the end user. Could we still display such
 information to end user, just don't permit him to edit them?  Otherwise, The
 end user will never know the TIME zone info at all.
 NOK2, Please keep the current time zone(got from NITZ), and display it to end
 user.
 
 NOK1&NOK2 are all  not occur expected behaviour.
 
 Could you continue to focus on this bug?

Comment 48

[Joe Cheng [:jcheng] (please needinfo)]

for further suggestions, please open another bug for tracking. Thanks