1059040 - [tarako][setting:Date&Time] Fail to automatic update Time&Date ,Get a wrong date and time

Status: RESOLVED WONTFIX

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

Description

[ting.yang]

Steps to reproduce:
1.open the wifi or data connection.
2.go to settings/Data&Time.
3.Manually set the date and time to any day.
3.open Set Automatically.
4.update the date error.

Comment 1

[ting.yang]

Hi sku:
   I have ckecked the radioInterfaceLayer.js and sntp.jsm code many times,but failed to find the reason.
Please help me to check this issue,Thank you very much.
   
  Test phenomenon：
  1.I set the date to 2037 manually.
  2.click set automatically
  3.it changes to 1946.
  4.the question is that the earliest date in the select is 1970.

Comment 2

[ting.yang]

Dear Evelyn:
     This is a question of customer and it also exists in the 6821_monkey.I am confused the automatic update mechanism of date and time.

Hope you can help me to check it,give me some advice.thank you very much.

Comment 3

[Marcus Cavanaugh [:mcav]]

The Gaia::Clock component is for the Clock application itself, not the system clock; reassigning to the Gaia::System component.

Comment 4

[ting.yang]

(In reply to Marcus Cavanaugh [:mcav] <[e-mail]> from comment #3)
> The Gaia::Clock component is for the Clock application itself, not the
> system clock; reassigning to the Gaia::System component.
Dear Marcus:
     thank you.The problem may be in the design of SNTP in radioInterfaceLayer.js and sntp.jsm. 

especially when you set the date to 2037 manually,it will update to 1946.

it may be the timestamp field overflow,then it works failed.

Comment 5

[Evelyn Hung]

Hi, I have no idea on tracing code in these two files, but I believe Shawn Ku knows.

Comment 6

[ting.yang]

(In reply to Evelyn Hung [:evelyn] from comment #5)
> Hi, I have no idea on tracing code in these two files, but I believe Shawn
> Ku knows.

Hi Evelyn:
   Thank you very much,I have asked Shawn Ku for help.

Comment 7

[ting.yang]

Dear Shawn Ku: 
     do you have any progress about this issue??I really need your help and it is a customer problems，it need to solve as soon as possible.
    Hope you can give me some advice,
    thanks.

Comment 8

[shawn ku [:sku]]

Hi ting.yang:
 I can not repo. this issue.

Pre-Condition:
Insert a SIM into slot1.

STR:
1. Settings -> Date & Time -> check "Set automatically"
   Shows: 08/28/2014
2. uncheck "Set automatically"
3. set date to 08/28/2037
   Shows: 08/28/2037
4. check "Set automatically"
   Shows: 08/28/2014

Could you please let me know if any steps are wrong, or provide me both radio/device log to check?

Comment 9

[ting.yang]

(In reply to shawn ku [:sku] from comment #8)
> Hi ting.yang:
>  I can not repo. this issue.
> 
> Pre-Condition:
> Insert a SIM into slot1.
> 
> STR:
> 1. Settings -> Date & Time -> check "Set automatically"
>    Shows: 08/28/2014
> 2. uncheck "Set automatically"
> 3. set date to 08/28/2037
>    Shows: 08/28/2037
> 4. check "Set automatically"
>    Shows: 08/28/2014
> 
> Could you please let me know if any steps are wrong, or provide me both
> radio/device log to check?

Hi sku:
   The steps is right.
   The first time update is right,but after you update the date and time serval times,it will update wrong.
   please hold on.I will give you radio/device log.
   thank you very very much.

Comment 10

[ting.yang]

Attachment: dateupdate.log

Hi sku:
   first
   I manurally set the time to 2037,click set automatically,it update to 1946.
   second
   1970.1.1----->1946.8.10

Comment 11

[ting.yang]

Attachment: dateupdate2.txt

Hi sku:
   I reset my phone and take a log again.Here is my test steps.
1. Settings -> Date & Time -> check "Set automatically"
   Shows: 08/28/2014
2. uncheck "Set automatically"
3. set date to 01/01/1970
   Shows: 01/01/1970
4. check "Set automatically"
   Shows: 08/28/2014
it is work well.

second time:

5. uncheck "Set automatically"
6. set date to 31/12/2037
   Shows: 31/12/2037
7. check "Set automatically"
   Shows: 10/08/1946
update wrong.
please help me to check why the second time work failed. 
thanks.

Comment 12

[ting.yang]

Hi sku:
   Do you repo. this issue ?? it seems that in the second time the Date.now()+offset overflow,the offset should be a negative number.but I can not find the crux of the problem,
if there is any thing I can do,please let me know.
thank you very much.

Comment 13

[shawn ku [:sku]]

Hi Ting:
 I am still in other meeting.

It looks like something wrong in ntp.
12-31 13:42:07.731 I/Gecko   (   85): -*- Sntp: yetta inputStream==[xpconnect wrapped (nsISupports, nsIInputStream, nsIAsyncInputStream, nsISeekableStream, nsISearchableInputStream)] offset ==0
12-31 13:42:07.731 I/Gecko   (   85): -*- Sntp: yetta Data available: 48 bytes
12-31 13:42:07.731 I/Gecko   (   85): -*- Sntp: yetta binaryInputStream=={}
12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta originateTimeInMS==-2149116369842
12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta receiveTimeInMS= 1409222545299
12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta transmitTimeInMS==1409222545299
12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta Date.now()=2145850927753
12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp:  yetta Clock offset: 1410855266343
12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta this._cachedOffset==-736628382080 change clockOffset==1410855266343

Comment 14

[ting.yang]

(In reply to shawn ku [:sku] from comment #13)
> Hi Ting:
>  I am still in other meeting.
> 
> It looks like something wrong in ntp.
> 12-31 13:42:07.731 I/Gecko   (   85): -*- Sntp: yetta
> inputStream==[xpconnect wrapped (nsISupports, nsIInputStream,
> nsIAsyncInputStream, nsISeekableStream, nsISearchableInputStream)] offset ==0
> 12-31 13:42:07.731 I/Gecko   (   85): -*- Sntp: yetta Data available: 48
> bytes
> 12-31 13:42:07.731 I/Gecko   (   85): -*- Sntp: yetta binaryInputStream=={}
> 12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta
> originateTimeInMS==-2149116369842
> 12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta receiveTimeInMS=
> 1409222545299
> 12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta
> transmitTimeInMS==1409222545299
> 12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta
> Date.now()=2145850927753
> 12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp:  yetta Clock offset:
> 1410855266343
> 12-31 13:42:07.741 I/Gecko   (   85): -*- Sntp: yetta
> this._cachedOffset==-736628382080 change clockOffset==1410855266343
Dear sku：
     
     The log I take is in sntp.jsm.Here is relative code：

let binaryInputStream = Cc["@mozilla.org/binaryinputstream;1"]
                                    .createInstance(Ci.nsIBinaryInputStream);
          binaryInputStream.setInputStream(inputStream);
          // We don't need first 24 bytes.
          for (let i = 0; i < 6; i++) {
            binaryInputStream.read32();
          }
          // Offset 24: originate time.
          let originateTimeInMS = GetTimeStamp(binaryInputStream);
          // Offset 32: receive time.
          let receiveTimeInMS = GetTimeStamp(binaryInputStream);
          // Offset 40: transmit time.
          let transmitTimeInMS = GetTimeStamp(binaryInputStream);
          let respondTimeInMS = Date.now();
          ....
can you give me more details about this issue??It is hard for me to identify problem in gecko or network communication in the underlying. 
thanks.

Comment 15

[shawn ku [:sku]]

Attachment: 1059040.patch

Comment 16

[shawn ku [:sku]]

Hi Ting:
 Could you please help try the patch via Comment 15?
Thanks!
Shawn

Comment 17

[ting.yang]

(In reply to shawn ku [:sku] from comment #16)
> Hi Ting:
>  Could you please help try the patch via Comment 15?
> Thanks!
> Shawn

Hi Sku:
   I will test it and give you the result as soon as possible.thank you very much.

Comment 18

[ting.yang]

Dear sku:
    I have tested this issue and it worked well. Here is my test date:
1970.1.1 -----2014.9.1
2000.10.1 ----2014.9.1
2036.12.31 ----2014.9.1
2037.12.31 -----2014.9.1
And I taked log for my testing so that you can check it.
Thank you very much,you really help me a lot.
besides, will we put this patch to the master??

Comment 19

[ting.yang]

Attachment: dateupdatepatch.txt

git add patch and take log

Comment 20

[shawn ku [:sku]]

(In reply to ting.yang from comment #18)
> Dear sku:
>     I have tested this issue and it worked well. Here is my test date:
> 1970.1.1 -----2014.9.1
> 2000.10.1 ----2014.9.1
> 2036.12.31 ----2014.9.1
> 2037.12.31 -----2014.9.1
> And I taked log for my testing so that you can check it.
> Thank you very much,you really help me a lot.
> besides, will we put this patch to the master??

Yes, will request review, and put patch to master then, uplift to other branches depend on request.

Comment 21

[ting.yang]

(In reply to shawn ku [:sku] from comment #20)
> (In reply to ting.yang from comment #18)
> > Dear sku:
> >     I have tested this issue and it worked well. Here is my test date:
> > 1970.1.1 -----2014.9.1
> > 2000.10.1 ----2014.9.1
> > 2036.12.31 ----2014.9.1
> > 2037.12.31 -----2014.9.1
> > And I taked log for my testing so that you can check it.
> > Thank you very much,you really help me a lot.
> > besides, will we put this patch to the master??
> 
> Yes, will request review, and put patch to master then, uplift to other
> branches depend on request.

Dear sku:

     I find another problem when solving this problem.

1. when we use wifi to get the data,it can show set automaticcally also.but when you click  set automatically,it does not work and keep the date as you set manually.

2.The Flame V1.3 will not show set automatically when use wifi.

3.should we hide this checkbox when use wifi??

Comment 22

[shawn ku [:sku]]

(In reply to ting.yang from comment #21)
> (In reply to shawn ku [:sku] from comment #20)
> > (In reply to ting.yang from comment #18)
> > > Dear sku:
> > >     I have tested this issue and it worked well. Here is my test date:
> > > 1970.1.1 -----2014.9.1
> > > 2000.10.1 ----2014.9.1
> > > 2036.12.31 ----2014.9.1
> > > 2037.12.31 -----2014.9.1
> > > And I taked log for my testing so that you can check it.
> > > Thank you very much,you really help me a lot.
> > > besides, will we put this patch to the master??
> > 
> > Yes, will request review, and put patch to master then, uplift to other
> > branches depend on request.
> 
> Dear sku:
> 
>      I find another problem when solving this problem.
> 
> 1. when we use wifi to get the data,it can show set automaticcally also.but
> when you click  set automatically,it does not work and keep the date as you
> set manually.
> 
> 2.The Flame V1.3 will not show set automatically when use wifi.
> 
> 3.should we hide this checkbox when use wifi??

Hi Ting:
 It is not always success by requesting SNTP. Besides, once we got NITZ or SNTP result, auto option is there for user.
Finally, we should focus on the overflow issue on 1059040.
Thanks!!

Comment 23

[ting.yang]

(In reply to shawn ku [:sku] from comment #22)
> (In reply to ting.yang from comment #21)
> > (In reply to shawn ku [:sku] from comment #20)
> > > (In reply to ting.yang from comment #18)
> > > > Dear sku:
> > > >     I have tested this issue and it worked well. Here is my test date:
> > > > 1970.1.1 -----2014.9.1
> > > > 2000.10.1 ----2014.9.1
> > > > 2036.12.31 ----2014.9.1
> > > > 2037.12.31 -----2014.9.1
> > > > And I taked log for my testing so that you can check it.
> > > > Thank you very much,you really help me a lot.
> > > > besides, will we put this patch to the master??
> > > 
> > > Yes, will request review, and put patch to master then, uplift to other
> > > branches depend on request.
> > 
> > Dear sku:
> > 
> >      I find another problem when solving this problem.
> > 
> > 1. when we use wifi to get the data,it can show set automaticcally also.but
> > when you click  set automatically,it does not work and keep the date as you
> > set manually.
> > 
> > 2.The Flame V1.3 will not show set automatically when use wifi.
> > 
> > 3.should we hide this checkbox when use wifi??
> 
> Hi Ting:
>  It is not always success by requesting SNTP. Besides, once we got NITZ or
> SNTP result, auto option is there for user.
> Finally, we should focus on the overflow issue on 1059040.
> Thanks!!

Dear sku：
     I got it.thank you very much.because this issue should solved as soon as possible,I have maked a sprd patch.If you have put patch to master please let me know,I wii remove the sprd patch.thanks.

Comment 24

[ting.yang]

Dear sku:
     I am sorry to trouble you again,I have made a sprd patch and it merged  On September 3，you can down the version  after w14.36.3.

     The tester test this issue,it worked not very well,when you set the time on 2036,it need a long time to update the date.

     I take some log,it because the network do not send the data back.

     can you help to check this issue ??? thank you very much,

Comment 25

[shawn ku [:sku]]

Hi Ken:
 Could you please find a member to check if we can have this fix officially?

Thanks!!
Shawn

Comment 26

[Ken Chang[:kenkai]]

Hi Chuck, please help this bug. Thanks.

Comment 27

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

The issue of multiple request while multi-sim and no request while wifi connected should be resolved by bug 931699, you can uplift/curry pick it instead of adding 
We can't control if server sends response or not, you can optimize the retry and timeout parameter in preference[1].
So I think the necessary part of the current patch is support date after 2036/02/07 06:28:16.

For the long run, I think we could consider to move the SNTP/NITZ part from radio interface layer to time manager.

[1] http://dxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js?from=b2g.js&case=true#882

Comment 28

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to Chuck Lee [:chucklee] from comment #27)
> The issue of multiple request while multi-sim and no request while wifi
> connected should be resolved by bug 931699, you can uplift/curry pick it
> instead of adding 

Lost few words: instead of adding new protection.

Comment 29

[ting.yang]

(In reply to Chuck Lee [:chucklee] from comment #27)
> The issue of multiple request while multi-sim and no request while wifi
> connected should be resolved by bug 931699, you can uplift/curry pick it
> instead of adding 
> We can't control if server sends response or not, you can optimize the retry
> and timeout parameter in preference[1].
> So I think the necessary part of the current patch is support date after
> 2036/02/07 06:28:16.
> 
> For the long run, I think we could consider to move the SNTP/NITZ part from
> radio interface layer to time manager.
> 
> [1]
> http://dxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js?from=b2g.
> js&case=true#882

Dear chuck：
     Thank you for your advice,the problem is that you set the date after 2036/02/07 06:28:16 manually it will not work,it need serval hours to update the date,

     if you set other date,it can work well.From the log I take,I find the code just go to 
     onOutputStreamReady: function(stream) {
     .....
     debug ("yetta SNTP: sent " + bytes_write + " bytes");
     ......}
 then it stoped.

Under normal circumstances，it should go to 
onDataAvailable: function onDataAvailable(request, context, inputStream,offset, count) {...}

so I guess this case the date after 2036/02/07 06:28:16 has something wrong ??? I am sorry to trouble you again,please help me and give me some advice. thank you.

PS: I add the current patch and some log in the sntp.jsm and radiointerfacelayer,js,Hope you can give me a hand.

Comment 30

[ting.yang]

Attachment: Sntp.jsm with patch and log

Comment 31

[ting.yang]

Attachment: RadioInterfaceLayer.js with patch and log

Comment 32

[ting.yang]

Dear Chuck：
     Do you repo. this issue ?? When you set the date to 2036 manually, check "Set automatically",It does not work.

    The log shows this case it just goes to debug ("yetta SNTP: sent " + bytes_write + " bytes");then it stoped. if you just let it go,after a long time(1 hour),it can update normally.

why this case need a long time to update the date ??? can you give me more details about this issue?? It is hard for me to identify problem in gecko or network communication in the underlying. 

if there is any thing I can do,please let me know.

thank you very much.

Comment 33

[shawn ku [:sku]]

Hi Chunk:
 There are two issues we have now on this one.
1. SNTP time overflow case, the SNTP only use 32-bit to identify the current time, And 1970 is used as base. That means "6h 28m 16s UTC on 7 February 2036" will be the upper bound of SNTP time.

2. Duplicated request for SNTP due to multi-SIM support.

IMHO, we need to fix above cases to make sure SNTP works properly on FxOS.

Comment 34

[shawn ku [:sku]]

(In reply to shawn ku [:sku]  (OOO 9/15 ~ 9/19) from comment #33)
> Hi Chunk:
>  There are two issues we have now on this one.
> 1. SNTP time overflow case, the SNTP only use 32-bit to identify the current
> time, And 1970 is used as base. That means "6h 28m 16s UTC on 7 February
> 2036" will be the upper bound of SNTP time.
> 
> 2. Duplicated request for SNTP due to multi-SIM support.
> 
> IMHO, we need to fix above cases to make sure SNTP works properly on FxOS.

should be 64-bit, not 32-bit for time stamp.

http://tools.ietf.org/html/rfc4330

Comment 35

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to ting.yang from comment #32)
> Dear Chuck：
>      Do you repo. this issue ?? When you set the date to 2036 manually,
> check "Set automatically",It does not work.
> 
>     The log shows this case it just goes to debug ("yetta SNTP: sent " +
> bytes_write + " bytes");then it stoped. if you just let it go,after a long
> time(1 hour),it can update normally.
> 
> why this case need a long time to update the date ??? can you give me more
> details about this issue?? It is hard for me to identify problem in gecko or
> network communication in the underlying. 
> 
> if there is any thing I can do,please let me know.
> 
> thank you very much.

I do run into connection issue using pure wifi connection, but I found it seems to be caused by the AP/router firewall or something - If I use OPEN AP in office, NTP never succeeds; if I use Encrypted AP, NTP succeeds.
I have sniffered wifi traffic and found NTP client packets do send out from tarako on both AP.
If the packet do sends out, I can't answer why the response doesn't come back until next sync timeout(1 hr).

Comment 36

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

(In reply to shawn ku [:sku]  (OOO 9/15 ~ 9/19) from comment #33)
> Hi Chunk:
>  There are two issues we have now on this one.
> 1. SNTP time overflow case, the SNTP only use 32-bit to identify the current
> time, And 1970 is used as base. That means "6h 28m 16s UTC on 7 February
> 2036" will be the upper bound of SNTP time.

I think this is resolved by shawn's patch to Sntp.jsm, although this is not likely to happen in following twenty years.

> 2. Duplicated request for SNTP due to multi-SIM support.

As I mentioned in comment 27, cherry pick the patch from bug 931699.

Comment 37

[ting.yang]

Dear Chuck：
   I am sorry I have not described this issue clearly,Here is my test steps.
1.flash the telephoe with w14.36.4 and insert a sim card,open data connection.
2. Settings -> Date & Time -> check "Set automatically"
   Shows: 17/09/2014
3. uncheck "Set automatically"
4. set date to 17/12/2036
   Shows: 17/12/2036
5. check "Set automatically"
   Shows: 17/12/2036
it will keep show 17/12/2036 for a long time,
if I close the data connection,then open the data connection
shows:17/09/2014

I have take the radio and main log,please check it.Thank you very much.

shawn's patch has solved the overflow problem,but why after merge this patch,the update do not work.please help to check it.thanks.

Comment 38

[ting.yang]

Attachment: update2036.12.17.txt

Comment 39

[ting.yang]

Dear chuck:

I have tested this issue again,Here is the result:

2000.9.18 >-----check "Set automatically",show:2014.9.18;work well
1970.1.11 >-----check "Set automatically",show:2014.9.18;work well 
2020.12.25 >----check "Set automatically",show:2020.12.25;

close then open data connection,show:2014.9.18;

2036.9.18>-------check "Set automatically",show:2036.9.18

close then open data connection,show:2014.9.18;

the radio and main log please see attachment update3.txt.I am sorry to trouble you again,if there is anything I can help,please let me know.

thank you very much.

Comment 40

[ting.yang]

Attachment: update3.txt

Comment 41

[Vincent Chang[:vchang][changyihsin]]

(In reply to ting.yang from comment #39)
> Dear chuck:
> 
> I have tested this issue again,Here is the result:
> 
> 2000.9.18 >-----check "Set automatically",show:2014.9.18;work well
> 1970.1.11 >-----check "Set automatically",show:2014.9.18;work well 
> 2020.12.25 >----check "Set automatically",show:2020.12.25;
> 
> close then open data connection,show:2014.9.18;
> 
> 2036.9.18>-------check "Set automatically",show:2036.9.18
> 

Do you apply the patch in Bug 931699 before doing the test?

Comment 42

[shawn ku [:sku]]

Since Chunk take this bug, cancel the ni? first.
please ni me if needed.

Comment 43

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (WIP) 0001. Support timestamp format of RFC 2030.

Support SNTP timestamp of RFC 2030 for time later than 2036, originally by Shawn.

Comment 44

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (WIP) 0002. IDL Change - Add sntp request API to network manager.

Comment 45

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (WIP) 0003. Move sntp request from RIL to Network Manager.

To make sure only one SNTP query at a time, move SNTP request from RadioInterfaceLayer into NetworkManager.

Comment 46

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Please test updated patches, checked on flame(moz-central)
Might need deal with some patch conflict on tarako.

Comment 47

[helloarvin]

Attachment: moz1059040_three_patches.patch

Dear Chuck,

I've checked on tarako with the above three patches and the issue still exists. 

First of all, I modify the date to any one like 2034.The checkbox of 'setTimeAutomatically' will be switched back to 'disabled' immediately I click to enable the button. After I click it repeatedly, the button will be disappeared. After a while, the date will be modified to the right one.

Please help check the patch merged locally and confirm(with the logs) whether there's anything wrong or not?

Thanks a lot.

I'll check the issue on dolphin and update the result later.

Comment 48

[helloarvin]

Attachment: log_verify_on_tarako.zip

Verify the issue two times

Comment 49

[helloarvin]

Attachment: check_results_on_dolphin.zip

Dear Chuck,

The test result on dolphin(moz-central without any sprd patches) is almost same as that on tarako.

1st bootup:
Failed to enable the 'setTimeAutomatically' button(it will be switched back to disabled state immediately like on dolphin) and the date had not been modified to the right one during more than 10 minutes[1].

2nd bootup:
I still failed to enable the 'setTimeAutomatically' button but the dateTime could be modified rightly after a while. During the period, I checked the issue several times and there's nearly no difference between those results. Detailed performance:
1> Modify the date manually;
2> Click to enable 'setTimeAutomatically' button;
3> It will switch back to disabled state immediately;
4> Later, the button disappeared and the labels dateMessage and timeMessage will be converted to read-only state;
5> After a while, the dateTime could be modified rightly.

The videos of the two tests and the patch has been attached, please help check why the button cannot be enabled?

Thanks a lot.

Comment 50

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (WIP)(1.3t) 0001. Support timestamp format of RFC 2030.

Comment 51

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (WIP)(1.3t) 0002. IDL Change - Add sntp status API to network manager.

Comment 52

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (WIP)(1.3t) 0003. Move sntp request from RIL to Network Manager.

Comment 53

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (WIP)(1.3t) 0004. Cancel sntp request on disconnect.

Comment 54

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Fix some timing issue only observed on tarako, please test again.

Comment 55

[helloarvin]

Ongoing, the result will be updated later.

Thank you Chuck:)

Comment 56

[helloarvin]

(In reply to helloarvin from comment #55)
> Ongoing, the result will be updated later.
> 
> Thank you Chuck:)

Hi Chuck,

Verify PASS!

The issue cannot be reproduced on tarako with the latest patches and it works very well when we enable the automatic update Time&Date option.

Could you please help land the patches into the every branches including v1.3t?

Thank you very much.

Comment 57

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

The patch for central involves refactory of handling auto time, this will much different from current patch for 1.3t.
It would take more time and the change might be too large for landing on 1.3t, I suggest you get these patches to your own code base.

Comment 58

[Kai-Zhen Li [:seinlin][:kli]]

Hi Chuck, The current patch can uplift to 1.3t without conflict. When it is landed on master, I think we can uplift it to 1.3t. Thanks!

Comment 59

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

The patch is for 1.3t only. It needs to be rebased to merge to central, but I prefer to do the refactory by moving auto time handling into time service on central code.

Comment 60

[helloarvin]

Hi Chuck,

I checked the patch on the two branches v1.3t and v1.4, it seems that there's not much difference between them. So, the difference between the master branch and the above two should be not very large.

I prefer to merge the patch into v1.3t and v1.4 after it's landed on master.

Thanks.

Comment 61

[Kai-Zhen Li [:seinlin][:kli]]

Arvin, I suggest you to have a local patch before there is a formal solution. I noticed that there are some issues in field testing when date/time is not correct and ssl connection is required.

Comment 62

[helloarvin]

Okey.

I'll make the local patch for the issue for all customers and look forward to a formal solution available.

Thanks again Chuck & Kai-Zhen.

Comment 63

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (1.3t, 1.4) 0001. Support timestamp format of RFC 2030.

Comment 64

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (1.3t, 1.4) 0002. IDL Change - Add sntp status API to network manager.

Comment 65

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (1.3t, 1.4) 0003. Move sntp request from RIL to Network Manager.

Comment 66

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Attachment: (1.3t, 1.4) 0004. Cancel sntp request on disconnect.

Comment 67

[Vincent Chang[:vchang][changyihsin]]

Looks like we will more formal patches on m-c, I think I should wait for your new patches.

Comment 68

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 8495840 [details] [diff] [review]
(1.3t, 1.4) 0002. IDL Change - Add sntp status API to network manager.

Review of attachment 8495840 [details] [diff] [review]:
-----------------------------------------------------------------

Drop the review request for now. Please ask for review when you have new patches.

Comment 69

[Doug Turner (:dougt)]

I am the wrong reviewer for this code.

Comment 70

[Vincent Chang[:vchang][changyihsin]]

I am going to take this. Feel free to take it back if you are still working on it.

Comment 71

[Doug Turner (:dougt)]

Comment on attachment 8495839 [details] [diff] [review]
(1.3t, 1.4) 0001. Support timestamp format of RFC 2030.

i am really not the right reviewer.

Comment 72

[BMO Automation]

Firefox OS is not being worked on