1147308 - [Date&Time] Automatically update to error date&time when wifi is connected.

Status: VERIFIED FIXED

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

Description

[sync-1]

DEFECT DESCRIPTION:
 Connect WiFi and open automatically update date&time; but it's update to error time and date
 
  REPRODUCING PROCEDURES:
 1.Open and connect wifi
 2.Randomly set the date and time
 3.Enter settings->Date&Time, Open "Set automatically"
 4.Wait to update the date and time
 
  EXPECTED BEHAVIOUR:
 update to the current date and time
 
  ASSOCIATE SPECIFICATION:
 update to error time and date

Comment 1

[sync-1]

Attachment: MTK log part2

Comment 2

[sync-1]

Attachment: MTK log part1

Comment 3

[sync-1]

Attachment: Log for sw7H1S+MJ

Comment 4

[sync-1]

Attachment: video

Comment 5

[xiaokang.chen]

Dear Developer,
As the vedio shows, the bug is truely exist but not easy to reproduce.

It is a little tricky but I think it's important for us to fix it. Is there anyone in charge of NTP TIME SYNC? 

Thanks a lot!

Comment 6

[Josh Cheng [:josh]]

Hi Shawn,
I remember you checked similar issues? Could you please help to check the problem? Thanks!

Comment 7

[shawn ku [:sku]]

Hi there:
 After checking three attached log, there is no any NITZ/SNTP information contained.
Please try get the log from boot-up, or provide STR for us to check again!!

Thanks!!
Shawn

Comment 8

[shawn ku [:sku]]

(In reply to shawn ku [:sku] from comment #7)
> Hi there:
>  After checking three attached log, there is no any NITZ/SNTP information
> contained.
> Please try get the log from boot-up, or provide STR for us to check again!!
> 
> Thanks!!
> Shawn

You can also modify the code below to see which case (NITZ/SNTP or rest of case) to change the time?

https://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js?from=RadioInterfaceLayer.js&case=true#2540

Comment 9

[sync-1]

(In reply to comment #4)
 > Comment from Mozilla:Hi there:
 >  After checking three attached log, there is no any NITZ/SNTP information
 > contained.
 > Please try get the log from boot-up, or provide STR for us to check again!!
 > 
 > Thanks!!
 > Shawn
 > 
 
 This bug is difficult to reproduce;
 1.If the cuurent time is 22:30(Not a standard time)
 1.Randomly set the date and time,such as 10:15
 2.Enter settings->Date&Time, Open "Set automatically"
 Then it very quickly update the time to 22:30; It's seems like there is a flash memory to storage the time,and when we open "Set automatically",Device not get the time from NITZ/SNTP,actually get the time from flash memory.

Comment 10

[Wesly Huang (EPM)]

1. Please follow suggestion in comment#8 to confirm the flow when this problem appear.

2. Please also let us know the reproduce rate. and it will be good to have a solid STR.

Thanks.

Comment 11

[xiaokang.chen]

Dear Shawn,
Our val found a easy way to reproduce this pr:
1 connect wifi, enable update, the time update correctly;
2 disable update, set a time like 12/3/2036;
3 enable update again, then we found the time update error time.

Comment 12

[land]

(In reply to xiaokang.chen from comment #11)
> Dear Shawn,
> Our val found a easy way to reproduce this pr:
> 1 connect wifi, enable update, the time update correctly;
> 2 disable update, set a time like 12/3/2036;
> 3 enable update again, then we found the time update error time.

Dear Shawn,
On base version(no tcl code), this problem also appear.

I analysed the log:
\906748\mtklog\netlog\NTLog_2022_0920_225229\tcpdump_NTLog_2022_0920_225229_start.cap
And found the following log:
43	229356339.171811	202.112.29.82	10.92.249.152	NTP	92	NTP Version 3, server
The log include:
Origin Timestamp: Dec 27, 2029 04:58:13.830999000 UTC

This timestamp is not normal, it is a furture timestamp. Maybe it is a clue.

Comment 13

[xiaokang.chen]

[Blocking Requested - why for this release]:It's an pr easy to reproduce and have a bad influence on user as comment #11.

Dear Shawn,
Please help fix it, thanks a lot !

Comment 14

[land]

Dear Shawn,
  From rfc1305, sntp protocol support the max time is nearly 2036.01.01 00:00.

Data Formats
  ......
  Note that since some time in 1968 the most significant bit (bit 0 of the
integer part) has been set and that the 64-bit field will overflow some
time in 2036. Should NTP be in use in 2036, some external means will be
necessary to qualify time relative to 1900 and time relative to 2036
(and other multiples of 136 years). Timestamped data requiring such
qualification will be so precious that appropriate means should be
readily available. There will exist an 200-picosecond interval,
henceforth ignored, every 136 years when the 64-bit field will be zero
and thus considered invalid.

Comment 15

[shawn ku [:sku]]

According to rfc 2030 (see [1]), the time after 2036 can not be handled well by SNTP. There is a question in rfc spec. to mention if 2036 or after are the right date/time to be handled by SNTP.

There is no conclusion yet.

Please hide the year after 2035.


"Should NTP or SNTP be in use in 2036, some external means will be
   necessary to qualify time relative to 1900 and time relative to 2036
   (and other multiples of 136 years)"



[1] - http://www.ietf.org/rfc/rfc2030.txt

Comment 16

[Josh Cheng [:josh]]

[Blocking Requested - why for this release]:
Dear Arthur,

Per comment 15 from Shawn.
Could you help to fix this bug with hiding(disabling) year after 2036? 
Thank you!

Comment 17

[Arthur Chen [:arthurcc][inactive after 6/30]]

FYI the current maximum year limit was set to 2038 based on this comment[1]. I would provide a patch setting it to 2036 per comment 15.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=834157#c5

Comment 18

[GitHub Autolander Bot]

Attachment: [gaia] crh0716:1147308 > mozilla-b2g:master

Comment 19

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8597015 [details] [review]
[gaia] crh0716:1147308 > mozilla-b2g:master

EJ, could you help review this simple patch? Thanks.

Comment 20

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Comment on attachment 8597015 [details] [review]
[gaia] crh0716:1147308 > mozilla-b2g:master

Thanks Arthur, r+.

Comment 21

[Arthur Chen [:arthurcc][inactive after 6/30]]

Thanks, EJ!

Comment 22

[GitHub Autolander Bot]

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/f039afc2db4d6865127d7ea5d9ef851ec688c561

Comment 23

[Cola, OOO till Oct. 8th]

Attachment: Flame_master.3gp

This bug has been verified as pass on latest build of Flame Master & Nexus5 Master by the STR in Comment 0.

Actual results: Update to the current date and time successfully.

See attachment:Flame_master.3gp

Reproduce rate: 0/10

Device: Flame Master build(Pass)
Build ID               20150713160207
Gaia Revision          a4278e41c08fa619edbd6537b6182d46dc475a4e
Gaia Date              2015-07-13 21:58:18
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/c68d02e758f0
Gecko Version          42.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150713.194509
Firmware Date          Mon Jul 13 19:45:22 EDT 2015
Bootloader             L1TC000118D0

Device: Nexus5 Master build(Pass)
Build ID               20150713160207
Gaia Revision          a4278e41c08fa619edbd6537b6182d46dc475a4e
Gaia Date              2015-07-13 21:58:18
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/c68d02e758f0
Gecko Version          42.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150713.211229
Firmware Date          Mon Jul 13 21:12:45 EDT 2015
Bootloader             HHZ12f