Note that NTP could be erroneous too.

1 files changed, 4 insertions, 2 deletions

diff --git a/timebase.c b/timebase.c
index e4c8df82..6a5ca488 100644
--- a/timebase.c
+++ b/timebase.c
@@ -69,7 +69,7 @@ a fixed (and possibly out of date) offset.
 Conclusion: if the system clock isn't accurate enough that we can deduce
 what rollover period we're in, we're utterly hosed. Furthermore, if it's
 not accurate to within a second and only NMEA devices are reporting,
-we don't know what century it is!
+we don't even know what century it is!
 
 Therefore, we must assume the system clock is reliable to within a second.
 
@@ -77,7 +77,9 @@ However, none of these caveats affect the usefulness of PPS, which
 tells us top of second to 50ns accuracy and can be made to condition a
 local NTP instance that does *not* rely on the system clock. The 
 combination of PPS with NTP time should be reliable regardless of
-what the local system clock gets up to.
+what the local system clock gets up to. That is, unless NTP clock
+skew goes over 1 second, but this is unlikely to ever happen - and
+if it does the reasons will have nothing to do with GPS idosyncracies.
 
 This file is Copyright (c) 2010 by the GPSD project
 BSD terms apply: see the file COPYING in the distribution root for details.