This is not an error! It simply means that the NTP server that is reading from does not consider itself to be accurate.
NTP works by reading time from multiple sources and calculating transimssion times. It's the things it the NTP logs that look like this:
reply from 18.104.22.168: offset -0.149047 delay 0.059953, next query 323s reply from 22.214.171.124: offset -0.154235 delay 0.046265, next query 325s reply from 126.96.36.199: offset -0.177480 delay 0.051301, next query 310s reply from 188.8.131.52: offset -0.173441 delay 0.032305, next query 307s reply from 184.108.40.206: offset -0.174818 delay 0.059999, next query 307s reply from 220.127.116.11: offset -0.179824 delay 0.045815, next query 314s reply from 18.104.22.168: offset -0.201945 delay 0.050864, next query 324s reply from 22.214.171.124: offset -0.197702 delay 0.032267, next query 313s
When first starting NTP the system is not synchronised and must build up to that point. Eventually in the NTP server logs this message will appear and then NTP is OK.
adjusting local clock by -0.020484s clock is now synced
When running a larger network, or if you choose to be nice to the Stratum 1 NTP sources you will run your own NTP server. We'll call it NTP1, then you have hosts connecting to it, say NODE1 and NODE2.
When you first start the service on NTP1 it's time is not in sync and it must build up to that point: clock is now synched
When NODE1 and NODE2 connect to NTP1 during this phase to get the time they will get the report from NTP1 that it's not ready (not synced). After NTP1 is synced, typically in the 30 to 60 minute range, then NODE1 and NODE2 will get proper time.