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:

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.

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.

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.

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

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

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

Rudy, can you help on this?

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 l10n@mozilla.com. Any string changes would delay l10n complete by ~2 weeks.

Redirect to Rudy, he can help. Thanks!!

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.

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.

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.

(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.

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.

(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.

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.

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.

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?

(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.

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.

(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.

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.

Pointer to Github pull-request

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.

(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?

(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.

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

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

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.

(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?

(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 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.

Talked with Evelyn and she is working on it.

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.

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

Pointer to Github pull-request

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 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.

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.

Gaia v1.0.1: c4d75d9cdf96348af73c26698b56f23c72a6dfe4 Gaia v1-train: ffc6ac77647bdbe178fabdf77e6d166ac2526508 Evelyn, Thanks for the review.

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'.

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

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

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.

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

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.

(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?

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