925687 - [Buri][Shira][Settings]Wrong date when "Set Automatically" is ON.

Status: RESOLVED INCOMPLETE

(Firefox OS Graveyard :: Vendcom, defect, P1)

Description

[sync-1]

DEFECT DESCRIPTION:
 Wrong date when "Set Automatically" is ON
 
  REPRODUCING PROCEDURES:
 Even if during start up of the device, the device finds the correct settings w.r.t. Country, City, Date and Time, after the start up is finished, the date is wrong.
 This has as a result not to be able to access Marketplace, or to set up an e-mail account.
 This has been also verified by the following test case:
 Settings - Date & Time - disable "Set Automatically" - enter manually the correct settings - go back to screen lock - verify the date and time are correct - enter settings - Date & Time - enable "Set Automatically" - go back to screen lock -> You will see that date is wrong
 
 Customer Impact Statement: 
 Customer will not be able to know that even if during start up the date & time settings were correct, the device got the wrong time and date.
 He will not be able to access Marketplace and E-mail, without knowing the reason why.
 
  EXPECTED BEHAVIOUR:
 When date and time is set to Automatic, the device has to get the correct time and date info.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:High
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Clone from brother

Comment 2

[sync-1]

Attachment: log

Comment 3

[Jack Liu]

Hi, 

Feedback from customer, the time is right but date is several weeks(131.97 days) from real date. Please find 'delay' value in the log attached.

Comment 4

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

this is a partner certification blocker. leo+
could be POVB but let's first have a look at this

Comment 5

[Andreas Gal :gal]

What is the expected time? What is the time that is set? On what network was this? What kind of SIM card exactly? Can we please get additional info from vendor?

Comment 6

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

Looked at the log, pretty sure this is POVB.   

Jack, please create an SR so we can support.  Please let me know the #, and if possible include answers to the questions in comment 5 as that'll really help debug quicker.

Comment 7

[Andreas Gal :gal]

10-11 11:08:21.779 I/Gecko   (  138): -*- QCContentHelper_QC_B2G: Applying NITZ: 13/10/11,07:33:05+12,01 delay=-11402646891

Comment 8

[Sarah Parsons]

Unable to reproduce this issue on the latest 1.1 Buri Build ID:20131011041214 using an AT&T SIM. 

Gaia   680f3b86b1e4ff1411ece6ba397b8b0e56b4b31c
SourceStamp cb2a1a27a94c
BuildID 20131011041214
Version 18.0

We're currently testing in Seattle, Washington. The time here is 9:45. The FTU will show display New York but will automatically switch to PST when FTU is completed. 

While going through FTU the New York time is shown (12:45pm) The date is correct and region is also correct (10/11/2013, America) 

After FTU is completed, and user is taken to the home screen. The time in the notification bar is switched to the current time (9:45am) because Set Automatically is automatically enabled. Which can be confirmed by going to Settings - Date and Time. 

When the user disables Set Automatically, the time is switched back to 12:45 (the same as the FTU)

Comment 9

[Tony Chung [:tchung]]

(In reply to Sarah Parsons from comment #8)
> Unable to reproduce this issue on the latest 1.1 Buri Build
> ID:20131011041214 using an AT&T SIM. 
> 
> Gaia   680f3b86b1e4ff1411ece6ba397b8b0e56b4b31c
> SourceStamp cb2a1a27a94c
> BuildID 20131011041214
> Version 18.0
> 
> We're currently testing in Seattle, Washington. The time here is 9:45. The
> FTU will show display New York but will automatically switch to PST when FTU
> is completed. 
> 
> While going through FTU the New York time is shown (12:45pm) The date is
> correct and region is also correct (10/11/2013, America) 
> 
> After FTU is completed, and user is taken to the home screen. The time in
> the notification bar is switched to the current time (9:45am) because Set
> Automatically is automatically enabled. Which can be confirmed by going to
> Settings - Date and Time. 
> 
> When the user disables Set Automatically, the time is switched back to 12:45
> (the same as the FTU)

Thanks for the thorough steps, Sarah.   This is looking more and more like NITZ related.  adding [POVB] whiteboard.

Comment 10

[Sarah Parsons]

This issue also does not reproduce on the most recent partner Build ID: 20130930155636

Gaia   f85fffbb33a3c88cb993d2b4abd3f29b88bb527d
SourceStamp
BuildID 20130930155636
Version 18.0
Firmware US_20130930

Comment 11

[Sarah Parsons]

We've continued to investigate this issue and have been able to reproduce this issue on the Com Ril.

When the user is taken to the home screen after completing the FTU, the time on the notification bar does not change to the current time even though Set Automatically is enabled. 


Device: Buri 1.1 Com Ril
Build ID: 20131011041214
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/cb2a1a27a94c
Gaia: 680f3b86b1e4ff1411ece6ba397b8b0e56b4b31c
Platform Version: 18.1

Comment 12

[Sarah Parsons]

To clarify, This issue was NOT reproducing on today's Buri 1.1 Build ID:20131011041214 on the Moz Ril. 

This issue only reproduces on the Buri 1.1 Com Ril:

Device: Buri 1.1 Com Ril
Build ID: 20131011041214
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/cb2a1a27a94c
Gaia: 680f3b86b1e4ff1411ece6ba397b8b0e56b4b31c
Platform Version: 18.1
RIL Version: 01.01.00.019.251

Comment 13

[buri.blff]

when the rill receive nitz, the rill set the "time.timezone" with format ""UTC+10:30""

but the gaia set the  "time.timezone" with format "Africa/Abidjan"

the two format is not consitence, it that right??

Comment 14

[Jack Liu]

Dear Michael,

Because Qualcomm case system is undering maintenance, we can't file PR now, will file it later.

This issues reproduced in T-Mobile Greece network.

Hi Sarah,

Would you please upload your reproducing logs here?

Thanks.

Comment 15

[buri.blff]

(In reply to Andreas Gal :gal from comment #5)
> What is the expected time? What is the time that is set? On what network was
> this? What kind of SIM card exactly? Can we please get additional info from
> vendor?

this pr is not about the time, it's about the date;

In the log we can see that:year/month/date is 13/10/11, this is right.  but after the delay=-11402646891 modify, the date is wrong;

the point is why the delay is so large(130 days);

Comment 16

[buri.blff]

there is two different problem:

1 time wrong:  as i said in commit 13, we find the timezone format is inconsistence, so the time zone in nitz can't be recognized  in gaia; this make the time wrong not date;

2 date wrong:  this is cause for : when we receive nitz(which is right) from modem, the nitz is modifyed with too large delay(130 days)(= Date.now() - this.nitzOffsetMs) to wrong;

i think:
this pr is about 2(date wrong);
the commit 8 is about 1(time wrong);

Comment 17

[Andreas Gal :gal]

Thanks for the additional details.

Comment 18

[Jack Liu]

Dears, 

Qualcomm SR ID 01324252

Comment 19

[buri.blff]

(In reply to buri.blff from comment #16)
> there is two different problem:
> 
> 1 time wrong:  as i said in commit 13, we find the timezone format is
> inconsistence, so the time zone in nitz can't be recognized  in gaia; this
> make the time wrong not date;
> 
> 2 date wrong:  this is cause for : when we receive nitz(which is right) from
> modem, the nitz is modifyed with too large delay(130 days)(= Date.now() -
> this.nitzOffsetMs) to wrong;
> 
> i think:
> this pr is about 2(date wrong);
> the commit 8 is about 1(time wrong);

the time wrong pr: 925687;

Comment 20

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

(In reply to buri.blff from comment #16)
> there is two different problem:
> 
> 1 time wrong:  as i said in commit 13, we find the timezone format is
> inconsistence, so the time zone in nitz can't be recognized  in gaia; this
> make the time wrong not date;
> 
> 2 date wrong:  this is cause for : when we receive nitz(which is right) from
> modem, the nitz is modifyed with too large delay(130 days)(= Date.now() -
> this.nitzOffsetMs) to wrong;
> 
> i think:
> this pr is about 2(date wrong);
> the commit 8 is about 1(time wrong);

I dont think there is any problem with comment 8 though. things seem to work fine in comment 8 so I think we should focus on your #2 point here

Comment 21

[buri.blff]

(In reply to Joe Cheng [:jcheng] from comment #20)
> (In reply to buri.blff from comment #16)
> > there is two different problem:
> > 
> > 1 time wrong:  as i said in commit 13, we find the timezone format is
> > inconsistence, so the time zone in nitz can't be recognized  in gaia; this
> > make the time wrong not date;
> > 
> > 2 date wrong:  this is cause for : when we receive nitz(which is right) from
> > modem, the nitz is modifyed with too large delay(130 days)(= Date.now() -
> > this.nitzOffsetMs) to wrong;
> > 
> > i think:
> > this pr is about 2(date wrong);
> > the commit 8 is about 1(time wrong);
> 
> I dont think there is any problem with comment 8 though. things seem to work
> fine in comment 8 so I think we should focus on your #2 point here

in the commit 8, we find in ftu the time zone info is wrong according to nitz;

Comment 22

[buri.blff]

we find the setting app set "time.timezone" as:"Europe/Madrid";
but the rill set "time.timezone" as:"UTC+1:00";

Is the difference in format right?
I can't find the transform code between the two format;
Maybe it is transform in some linux funtion??

Comment 23

[buri.blff]

this may make the setting app can't recognize the timezone info in nitz, is that right??

Comment 24

[Alex Keybl [:akeybl]]

This remains a commercial RIL bug as far as we're aware. Assigning accordingly.