[Git][NTPsec/ntpsec][master] Documentation improvements.
Eric S. Raymond
gitlab at mg.gitlab.com
Sun Sep 18 01:22:02 UTC 2016
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
c2c28bef by Eric S. Raymond at 2016-09-17T21:21:52-04:00
- - - - -
2 changed files:
@@ -32,7 +32,13 @@ seconds part - how it's interpreted depends on which member of a union
The comments in libntp/ntp_calendar.c are pretty illuminating about
+calendar representations. A high-level point they don't make is
+that ignoring time cycles in l_fp is exactly how NTP gets around the
+Y2K38 problem. As long as the average clock skew between machines
+is much less than the length of a calendar cycle (which it generally
+will be, by a factor of at least five million) we can map all incoming
+timestamps from whatever cycle into the nearest time im modular
+arithmetic relative to the cycle length.
=== vint64 ===
@@ -4,6 +4,9 @@
* Written by Juergen Perlinger <perlinger at ntp.org> for the NTP project.
* Copyright 2015 by the NTPsec project contributors
* SPDX-License-Identifier: NTP
+ * There is more about these types and calculations in the internals tour
+ * document distributed with the code.
@@ -512,7 +515,7 @@ ntpcal_split_eradays(
* Split off calendar cycles, using floor division in the first
* step. After that first step, simple division does it because
* all operands are positive; alas, we have to be aware of the
- * possibe cycle overflows for 100 years and 1 year, caused by
+ * possible cycle overflows for 100 years and 1 year, caused by
* the additional leap day.
n400 = days / GREGORIAN_CYCLE_DAYS;
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/c2c28bef87cbf016e26d36324da62295cc8baa18
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vc