From 577bb0ce183b7da56f3f60ef4aa5f98bde1d388e Mon Sep 17 00:00:00 2001 From: Martin Fouilleul Date: Sat, 4 Jun 2022 17:11:24 +0200 Subject: [PATCH] Added NTP timestamps and dates in the Date representation section --- selected/time.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/selected/time.md b/selected/time.md index ca6fbdf..f7abca9 100644 --- a/selected/time.md +++ b/selected/time.md @@ -115,6 +115,12 @@ With all these concepts established, the question now is how to actually represe - Somewhat ambiguous for dates before 1972 (because UTC was not established yet) - Trivial computer representation (a single number) - Not human readable +- NTP timestamp + - Fractional seconds since January 1, 1900 UTC (even if UTC didn't exist back then, see above). + - Uses 64 bit fixed point format. The 32 most significant bits denote the number of seconds, the 32 least significant bits denote fractional seconds. The smallest time increment is thus $2^{-32}$ seconds (232 picoseconds). The maximum representable time range is approximately 136 years. +- NTP date + - It uses 128 bits as follows: a 32 bits signed Era number, a 96 fixed point era offset (32 bits for seconds and 64 bits for fractional seconds). + - Covers the whole universe existence with a precision well below any duration that can be directly measured. - RFC 3339 date-time - Unambiguously stores an instant in time - Indicates offset from UTC (but _not_ time zone in the proper sense - no DST) @@ -151,7 +157,7 @@ The protocol selects sources in order to avoid loops and minimize the round-trip ## NTP Architecture -Now let's see the implementation of one node of the network. The following diagram shows the various stages of the pipeline used to collect time information and mitigate errors caused by network delays and clock inaccuracies. I'll explain each one in a short paragraph and give links to dig deeper. +Now let's see the implementation of one node of the network. The following diagram shows the various stages of the pipeline used to collect time information and mitigate errors caused by network delays and clock inaccuracies. I'll explain each one in a short paragraph and give links to the relevant parts of the RFC, and to other references if you want to dig deeper. ![NTP architecture flow graph](./NTP_architecture_summary.svg) @@ -243,6 +249,8 @@ It is worth noting that because it is crucially important to preserve a monotony Links: [RFC5905 - section 12](https://datatracker.ietf.org/doc/html/rfc5905#section-12) +And this concludes our tour of NTP! + # How long things take: durations Computer clocks