1000352 - Automatic time getting overridden when settings app first loaded

Status: RESOLVED WONTFIX

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

Description

[pgravel]

Steps to reproduce
1. Flash phone to have clean settings db
2. Boot phone normally, wait to connect to network and receive NITZ
3. Since automatic time is enabled by default, NITZ gets applied and time gets updated as expected (eg: 9:30am, local California/San_Diego time) -- OK
4. Open settings app, go to Date & Time, time suddenly advances by 3 hours (eg 9:30am -> 12:30pm) -- KO

This occurs because in tz_select.js if there is no 'time.timezone.user-selected' settings defined it will try to figure it out by looking up the mcc/mnc values in apn_tz.json. Since an mcc of 310 maps to "America/New_York", both 'time.time' and 'time.timezone.user-selected' will be set to "America/New_York". This causes the time to suddenly move ahead by 3 hours.

This only happens on the very first time "Date & Time" is opened. On future restart since 'time.timezone.user-selected' is already defined, the same logic is not run and the time remains correct.


Short version: NITZ time should not get overridden first time "date & time" settings page is loaded when Automatic Time is enabled.

Comment 1

[Preeti Raghunath(:Preeti)]

Tim,

Please investigate and reassign.

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

This is a very complex bug. First I would like to confirm with you whether or not the "set automatically" switch is shown or hidden, and whether or not the timezone controls is present, preferably a screenshot.

This is only valid bug for NOFTU build. On a build with FTU, tz_select.js will do the (maybe incorrect) work there instead.

I can provide a fix which Settings app will never flicker timezone with mmc/mnc, however the bug will still exist if you somehow got a NITZ update before FTU launches.

Recap, the proposed fix is as follows:

1. Move the mmc/mnc to timezone logic to FTU and have it run and sets 'time.timezone.user-selected' and also the 'time.timezone' when user taps "Next".
2. For Settings app
2.1 Don't touch 'time.timezone' in any way if automatic time update is available and enabled.
2.2 If automatic time update is disabled *and* there isn't a valid 'time.timezone.user-selected' value, try to figure out one based on mmc and mnc (and set it to 'time.timezone').

I think 2.1/2.2 is already there but I am not sure, so I need a screenshot first.

PS Do we really consider NO FTU build breakage as blockers? Setting 1.4? for sure.

Comment 3

[Jason Smith [:jsmith]]

This doesn't affect production builds, so this is not a blocker.

Comment 4

[pgravel]

This indeed only happens in a NOFTU build.(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #2)
> This is a very complex bug. First I would like to confirm with you whether
> or not the "set automatically" switch is shown or hidden, and whether or not
> the timezone controls is present, preferably a screenshot.
"set automatically" switch is shown and toggled ON. Timezone is grayed out, no controls shown.
Will attach picture.

> This is only valid bug for NOFTU build. On a build with FTU, tz_select.js
> will do the (maybe incorrect) work there instead.

Correct, the case I described only happens if NOFTU is enabled.

However it does still somewhat affect the FTU case, albeit a bit differently and in parts worse.

If I were to thumb through the FTU menu, the user selected timezone would be New York (which is more than partially "user error"), which causes time to move up 3 hours. Entering the settings in this case seems to change the time the time back 1 hour (i.e. 5pm from NITZ -> 8pm after FTU -> 7pm when entering data&time settings). I haven't traced this behavior, but I assume the -1 hour has to do with daylight savings.

On reboot when we receive a NITZ again, the time goes back to being correct (5pm), and from this point on entering the date&time settings does not modify the time in any way.

> I can provide a fix which Settings app will never flicker timezone with
> mmc/mnc, however the bug will still exist if you somehow got a NITZ update
> before FTU launches.

NITZ happens pretty quickly usually, easily within the time it takes for the user to get to the timezone screen of the FTU app.

> 
> Recap, the proposed fix is as follows:
> 
> 1. Move the mmc/mnc to timezone logic to FTU and have it run and sets
> 'time.timezone.user-selected' and also the 'time.timezone' when user taps
> "Next".
> 2. For Settings app
> 2.1 Don't touch 'time.timezone' in any way if automatic time update is
> available and enabled.
> 2.2 If automatic time update is disabled *and* there isn't a valid
> 'time.timezone.user-selected' value, try to figure out one based on mmc and
> mnc (and set it to 'time.timezone').
> 
> I think 2.1/2.2 is already there but I am not sure, so I need a screenshot
> first.
> 
> PS Do we really consider NO FTU build breakage as blockers? Setting 1.4? for
> sure.

2.1 - Seems to the be most necessary part of this fix. If "Set Automatically" is enabled, there is no reason for the time to change at all.


Since this occurs even in production builds, I'm re-nominating this for v1.4?

Comment 5

[pgravel]

Attachment: Date&time screen

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to pgravel from comment #4)
> This indeed only happens in a NOFTU build.(In reply to Tim Guan-tin Chien
> [:timdream] (MoCo-TPE) (please ni?) from comment #2)
> > This is a very complex bug. First I would like to confirm with you whether
> > or not the "set automatically" switch is shown or hidden, and whether or not
> > the timezone controls is present, preferably a screenshot.
> "set automatically" switch is shown and toggled ON. Timezone is grayed out,
> no controls shown.
> Will attach picture.
> 
> > This is only valid bug for NOFTU build. On a build with FTU, tz_select.js
> > will do the (maybe incorrect) work there instead.
> 
> Correct, the case I described only happens if NOFTU is enabled.
> 
> However it does still somewhat affect the FTU case, albeit a bit differently
> and in parts worse.
> 
> If I were to thumb through the FTU menu, the user selected timezone would be
> New York (which is more than partially "user error"), which causes time to
> move up 3 hours. Entering the settings in this case seems to change the time
> the time back 1 hour (i.e. 5pm from NITZ -> 8pm after FTU -> 7pm when
> entering data&time settings). I haven't traced this behavior, but I assume
> the -1 hour has to do with daylight savings.
> 
> On reboot when we receive a NITZ again, the time goes back to being correct
> (5pm), and from this point on entering the date&time settings does not
> modify the time in any way.
> 

I cannot fix FTU in a Settings bug. Please file separate bug under FTU and set 1.4? there.

> > I can provide a fix which Settings app will never flicker timezone with
> > mmc/mnc, however the bug will still exist if you somehow got a NITZ update
> > before FTU launches.
> 
> NITZ happens pretty quickly usually, easily within the time it takes for the
> user to get to the timezone screen of the FTU app.
> 
> > 
> > Recap, the proposed fix is as follows:
> > 
> > 1. Move the mmc/mnc to timezone logic to FTU and have it run and sets
> > 'time.timezone.user-selected' and also the 'time.timezone' when user taps
> > "Next".
> > 2. For Settings app
> > 2.1 Don't touch 'time.timezone' in any way if automatic time update is
> > available and enabled.
> > 2.2 If automatic time update is disabled *and* there isn't a valid
> > 'time.timezone.user-selected' value, try to figure out one based on mmc and
> > mnc (and set it to 'time.timezone').
> > 
> > I think 2.1/2.2 is already there but I am not sure, so I need a screenshot
> > first.
> > 
> > PS Do we really consider NO FTU build breakage as blockers? Setting 1.4? for
> > sure.
> 
> 2.1 - Seems to the be most necessary part of this fix. If "Set
> Automatically" is enabled, there is no reason for the time to change at all.
> 
> 
> Since this occurs even in production builds, I'm re-nominating this for v1.4?

I still don't see any definite reproducible step for Settings app production build?
Maybe it is possible to trigger NITZ update from |adb shell| to simulate that?

Comment 7

[bhavana bajaj [:bajaj]]

NI the reporter here to get more information that TIm has requested.

Comment 8

[pgravel]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #6)
> I cannot fix FTU in a Settings bug. Please file separate bug under FTU and
> set 1.4? there.
I'll file a separate bug shortly, I need to play around some more to figure out where the -1 hour is coming from.
 
> I still don't see any definite reproducible step for Settings app production
> build?
> Maybe it is possible to trigger NITZ update from |adb shell| to simulate
> that?
I don't think there's an easy way to fake out a NITZ update via adb shell, but it should be easy to fake out via a small marionette script.
A NITZ message essentially becomes a
  timeService.set(timeInMs);
  settingsService.createLock().set('time.timezone', timezone, null);
where timeService is @mozilla.org/time/timeservice;1

Comment 9

[pgravel]

Quick update on the -1 hour isse: It seems the discrepancy only happens when the automatic timezone is specified using the UTC notation (i.e. "UTC-07:00" instead of "America/Los_Angeles"). I'm investigating that further.

Comment 10

[Preeti Raghunath(:Preeti)]

Based on complexity and lack of seeing it in Production builds we might not fix it for 1.4

Comment 11

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

It's not a regression : 
http://mxr.mozilla.org/gaia/source/shared/js/tz_select.js#32

bug 975815.  Mwu found this out during MWC, when we were noticing when we changed the time, the timezone kept messing up.

Comment 12

[pgravel]

This is safe to put back into backlog, I traced the -1 hour error to a behavior quirk in bionic libc code.
The orignal NOFTU bug still applies, but as it doesn't happen in a production build it is safe to have in the backlog.

Comment 13

[BMO Automation]

Firefox OS is not being worked on