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

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!

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

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

(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.

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.

(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 !

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

[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!

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 on attachment 8597015 [details] [gaia] crh0716:1147308 > mozilla-b2g:master EJ, could you help review this simple patch? Thanks.

Comment on attachment 8597015 [details] [gaia] crh0716:1147308 > mozilla-b2g:master Thanks Arthur, r+.

Thanks, EJ!

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

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