Subject: [IDWG] ntpstamp rollover and UTC

From: Paul Sangree <[email-masked]>
Date: Fri, 29 Dec 2000 11:02:36 -0600

Two issues with ntpstamp:

(1) I think we should clarify in the doc that ntpstamp expresses the seconds
elapsed since 1900-01-01/00:00:00 using UTC time, not local time.

(2) NTP will experience a rollover in the year 2036 as the 32-bit seconds count
reaches it's maximum value. The NTP RFC leaves it up to each implementation to
find a way around this problem.  I suggest we add the following text to the DTD
spec.  It is extracted from the SNTP 4.0 RFC (see reference below):  

"The ntpstamp value will experience a rollover to 0x00000000.0x00000000 early
in the year 2036.  In order to maintain continuity beyond this rollover date,
the following compensation method must be used.  If the most significant bit of
the ntpstamp value is set, the UTC time is in the range 1968-2036 and UTC time
is reckoned from 0h 0m 0s UTC on 1  January 1900.  If the most significant bit
is not set, the year is in the range 2036-2104 and UTC time is reckoned from 6h
28m 16s UTC on 7 February 2036.   Dates in years outside the range of 1968-2104
cannot be expressed in ntpstamp.  Note that when calculating the
correspondence, 2000 is not a leap year. Note also that leap seconds are not
counted in the reckoning. "

---------------------------------------------------------

For reference, SNTP 4.0 (RFC2030) states:

"   Note that, since some time in 1968 (second 2,147,483,648) the most
significant bit (bit 0 of the integer part) has been set and that the 64-bit
field will overflow some time in 2036 (second 4,294,967,296).  Should NTP or
SNTP be in use in 2036, some external means will be  necessary to qualify time
relative to 1900 and time relative to 2036  (and other multiples of 136 years).
There will exist a 200-picosecond  interval, henceforth ignored, every 136
years when the 64-bit field  will be 0, which by convention is interpreted as
an invalid or  unavailable timestamp.
   As the NTP timestamp format has been in use for the last 17 years,  it
remains a possibility that it will be in use 40 years from now  when the
seconds field overflows. As it is probably inappropriate  to archive NTP
timestamps before bit 0 was set in 1968, a  convenient way to extend the useful
life of NTP timestamps is the following convention: If bit 0 is set, the UTC
time is in the  range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on
1  January 1900. If bit 0 is not set, the time is in the range 2036-2104 and
UTC time is reckoned from 6h 28m 16s UTC on 7 February 2036. Note that when
calculating the correspondence, 2000 is not a  leap year. Note also that leap
seconds are not counted in the reckoning."

---------------------------------------------------------------
Paul Sangree <mailto:[email-masked]>
Active Audit Engineering
Cisco Systems, Inc.
12515 Research Blvd, AST03/B2-6
Austin, TX, USA 78759
voice: 512-378-1518
fax:    512-378-1250

---

From: Paul Sangree <[email-masked]>
Date: Fri, 29 Dec 2000 17:37:35 -0600

A third problem with ntpstamp is that RFC1305 states that the value
0x0000000.0x0000000 is reserved to mean 'invalid' or 'undefined', and is meant
to be used when a device's clock has not yet initialized.  However, this value
will occur at the instant of the rollover in 2036, causing a momentary
discontinuity.  I think we can handle that by redefining this special value to
mean 2036-02-07T06:28:16Z (i.e. the instant of the rollover), and there is no
'invalid' value.  (Yes, I know, this is nit-picky since it will only occur
once)

Because of all these deviations from RFC1035, it may eliminate ambiguity if we
state that the ntpstamp format is derived from RFC1035, rather than that it
conforms to the RFC.