An 0.5s System Error

[WhymustIhaveaname]

trafficstars

This library only saves seconds will lead to a system error between 0 and 1 second, average 0.5s.

For example, the program synchronizes at 0h0m0 .9s. By the design, it saves time as 0s. After 0.2s, i.e. 0h0m1.1s, I use getFormattedTime(). It should return 0h0m1s, but it will return 0h0m0s. It will not update the time until 0h0m1.9s. As so it will update 2s at 2.9s, 3s at 3.9s. This is a const system error.

The NTP can achieve an accuracy below 10ms. So this about 0.5s error is catastrophic. issue79 and issue23 relate to this.

[WhymustIhaveaname]

I rewrite something and, 1 increase time accuracy to not above 100ms 1.1 complete decimal part of NTP 1.2 use high-freq polling 1.3 add _current_epoc_dec and get_millis() so that ms can be known 2 rewrite update() 2.1 solved overflow problem 2.2 change update()'s return type to byte in order to carry more info 2.3 add a not-request-too-fast feature by adding _last_fail in update() 3 change all unsigned long to uint32_t, int to uint16_t, etc. to make it more stable

If you want to update this repo, I can help.

[Testato]

Please submit a Pull Request so we can review it

[WhymustIhaveaname]

I submit a Pull Request. I have tested my codes in LAN and in WAN. As to the accuracy, it can achieve 10ms in LAN and 100ms in WAN.