This is not an error! It simply means that the NTP server that is reading from does not consider itself to be accurate.

Explanation

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 192.43.244.18: offset -0.149047 delay 0.059953, next query 323s
reply from 216.55.159.183: offset -0.154235 delay 0.046265, next query 325s
reply from 209.104.4.227: offset -0.177480 delay 0.051301, next query 310s
reply from 208.100.53.12: offset -0.173441 delay 0.032305, next query 307s
reply from 192.43.244.18: offset -0.174818 delay 0.059999, next query 307s
reply from 216.55.159.183: offset -0.179824 delay 0.045815, next query 314s
reply from 209.104.4.227: offset -0.201945 delay 0.050864, next query 324s
reply from 208.100.53.12: 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.