Closed Bug 1147308 Opened 6 years ago Closed 6 years ago

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

Categories

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

defect

Tracking

(blocking-b2g:2.5?, b2g-master verified)

VERIFIED FIXED
blocking-b2g 2.5?
Tracking Status
b2g-master --- verified

People

(Reporter: sync-1, Assigned: arthurcc)

References

Details

Attachments

(6 files)

5.04 MB, application/octet-stream
Details
5.72 MB, application/octet-stream
Details
284.74 KB, application/x-rar-compressed
Details
5.26 MB, video/3gpp
Details
46 bytes, text/x-github-pull-request
eragonj
: review+
Details | Review
5.95 MB, video/3gpp
Details
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
Attached file MTK log part2
Attached file MTK log part1
Attached file Log for sw7H1S+MJ
Attached video video
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!
QA Whiteboard: y
QA Whiteboard: y
Hi Shawn,
I remember you checked similar issues? Could you please help to check the problem? Thanks!
Blocks: Woodduck
Flags: needinfo?(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
Flags: needinfo?(sku) → needinfo?(sync-1)
(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
(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.
Flags: needinfo?(chenxk)
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.
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.
Flags: needinfo?(chenxk)
(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.
[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 !
blocking-b2g: --- → 2.0?
Flags: needinfo?(sku)
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.
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
Flags: needinfo?(sku)
[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!
blocking-b2g: 2.0? → 3.0?
Flags: needinfo?(sync-1) → needinfo?(arthur.chen)
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
Assignee: nobody → arthur.chen
Flags: needinfo?(arthur.chen)
Comment on attachment 8597015 [details] [review]
[gaia] crh0716:1147308 > mozilla-b2g:master

EJ, could you help review this simple patch? Thanks.
Attachment #8597015 - Flags: review?(ejchen)
Comment on attachment 8597015 [details] [review]
[gaia] crh0716:1147308 > mozilla-b2g:master

Thanks Arthur, r+.
Attachment #8597015 - Flags: review?(ejchen) → review+
Thanks, EJ!
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Attached video 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
Status: RESOLVED → VERIFIED
QA Whiteboard: [MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.