2208988800一个奇怪的数字

2208988800为1900年1月1日00:00:00~1970年1月1日00:00:00的总秒数

以下为相关资料：

Rfc 868

NetworkWorking Group                                   J. Postel - ISI
Request for Comments: 868                           K. Harrenstien -SRI
                                                               May 1983

TimeProtocol

This RFCspecifies a standard for the ARPA Internet community.  Hosts on
the ARPA Internet that choose to implement a Time Protocol are expected
to adopt and implement this standard.

Thisprotocol provides a site-independent, machine readable date and
time.  The Time service sends back to theoriginating source the time in
seconds since midnight on January first 1900.

Onemotivation arises from the fact that not all systems have a
date/time clock, and all are subject to occasional human ormachine
error.  The use of time-servers makes itpossible to quickly confirm or
correct a system's idea of the time, by making a brief poll ofseveral
independent sites on the network.

Thisprotocol may be used either above the Transmission Control Protocol
(TCP) or above the User Datagram Protocol (UDP).

Whenused via TCP the time service works as follows:

S:Listen on port 37 (45 octal).

U:Connect to port 37.

S: Sendthe time as a 32 bit binary number.

U:Receive the time.

U: Closethe connection.

S: Closethe connection.

Theserver listens for a connection on port 37. When the connection
   is established, the server returns a32-bit time value and closes the
   connection.  If the server is unable to determine the timeat its
   site, it should either refuse theconnection or close it without
   sending anything.

Postel                                                         [Page 1]

RFC868                                                        May 1983
Time Protocol                                                          

Whenused via UDP the time service works as follows:

S:Listen on port 37 (45 octal).

U: Sendan empty datagram to port 37.

S:Receive the empty datagram.

S: Senda datagram containing the time as a 32 bit binary number.

U:Receive the time datagram.

Theserver listens for a datagram on port 37. When a datagram
   arrives, the server returns a datagramcontaining the 32-bit time
   value. If the server is unable to determine the time at its site, it
   should discard the arriving datagramand make no reply.

The Time

The timeis the number of seconds since 00:00 (midnight) 1 January 1900
GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this
base will serve until the year 2036.

Forexample:

thetime  2,208,988,800 corresponds to00:00  1 Jan 1970 GMT,

2,398,291,200corresponds to 00:00  1 Jan 1976 GMT,

2,524,521,600corresponds to 00:00  1 Jan 1980 GMT,

2,629,584,000corresponds to 00:00  1 May 1983 GMT,

and-1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.

Postel                                                         [Page 2]

 

 

The NTP Era and Era Numbering

from The Wizard of Oz, L. Frank Baum

Era dynamically aloft

Last update 12-May-201223:56 UTC

Abstract

The NetworkTime Protocol (NTP) specification defines the timescale in terms of timestampsand datestamps. Timestamps define an era spanning 136 years, while datestampsextend over multiple eras spanning the age of the Universe to when the starsgrow dim. This document clarifies the interpretation of timestamps anddatestamps and their relationship with the Coordinated Universal Time (UTC)timescale used in ordinary life.

1. Introduction

As of early 2012 the NetworkTime Protocol (NTP) has been ticking over 30 years and remains the longestrunning, continuously operating application protocol in the Internet. There wassome fear, especially in government and financial institutions, that NTP mightcause an Internet meltdown upon the Millennium epoch, but those fears turnedout to be groundless. However, the concern now is a possible meltdown when theunsigned 64-bit NTP timestamp rolls over in 2036. This document explores thisissue together with the interpretation of the NTP timescale with respect to theGregorian calendar.

It is important to make acareful distinction between the terms timescale, date, epoch, era and timestamp. A timescale is a continuum ofvalues used to denote time in some frame of reference. While those useful forcomputers and networks are continuous, civil timescales may not be. Forinstance, in order to align the civil year with the solar year, Pope Gregorypunched a 10-day hole in the Common Era (CE) in 1582. In modern times weoccasionally insert a leap second to align the civil time to the solar time.

Generally, timescales arecyclic and span an era with designated beginning and span. The timescalecorresponding to the Julian Era began in 4713 BCE and spans 7980 years. A dateis a unique value captured as the timescale progresses and an epoch is a staticdate of some interest, such as the origin of the CE. In general, both dates andepochs are internal system variables with generous proportions, like 128 bits.On the other hand, timestamps are derived from dates but packed in more compactformat, like 64 bits, for efficiency in transport. NTP timestamps areassociated with era numbers that provide an unambiguous mapping to dates.

2. The UTC Timescale

It will be helpful inunderstanding the issues raised here to consider the concept of a universaltimescale. The conventional civil timescale used in most parts of the world isCoordinated Universal Time (UTC), which replaced Greenwich Mean Time (GMT) manyyears ago. UTC is based on International Atomic Time (TAI), which is derivedfrom hundreds of cesium oscillators in the national standards laboratories ofmany countries. Deviations of UTC from TAI are implemented in the form of leapseconds, which occur at intervals from a few months to several years.

For almost every computerapplication today, UTC represents the universal timescale extending into theindefinite past and indefinite future. We know of course that the UTC timescaledid not exist prior to 1972 CE, nor the Gregorian calendar prior to 1582 CE,nor the Roman calendar prior to 54 BCE, nor the Julian Era prior to 4713 BCE,and we cannot predict exactly when the next leap second will occur.Nevertheless, most folks would prefer that, even if we can't get future secondsnumbering right beyond the next leap second, at least we can get the daysnumbering right until the end of reason.

3. The NTP Timescale

The NTP timescale can beimplemented using a binary counter of indefinite width and with the unitseconds bit placed somewhere in the middle. The counter is synchronized to UTCsuch that it runs at the same rate and the units increment coincides with theUTC seconds tick. The NTP timescale is defined by 128 bits of this counter, ofwhich the first 64 bits count the seconds and the last 64 bits interpolates thefraction of the second. The timescale covers well beyond the age of theuniverse with a precision well below the smallest times that can be directlymeasured. An implementation may choose to limit the size of the fraction field,but not less than 32 bits.

An NTP date is a sample ofthe counter interpreted as a twos-complement integer. An NTP epoch is a specialdate distinguished by some event. The origin of the timescale, called the primeepoch (epoch 0) corresponds to 0h, 1 January 1900. Positive values representtimes after the prime epoch; negative values represent times before then.Conversion between any calendar date format and NTP format is done by computingthe seconds and fraction difference between the given date and the NTP primeepoch; the 128-bit signed value is the NTP date.

An NTP timestamp is atruncated NTP date expressed as an unsigned 64-bit integer including the loworder 32 bits of the seconds field concatenated with the high-order 32 bits ofthe fraction field. This format can represent the 136 years from 1900 to 2036with a precision of 232 ps. As will be shown later, ranges beyond these yearsrequire an era number which is the high order 32 bits of the seconds field ofthe associated date.

The most important thing toobserve about the NTP timescale is that it knows nothing about days, years orcenturies, only the seconds and fraction relative to the prime epoch. Table 1illustrates the correspondence between calendar date, Julian day number (JDN),NTP date, NTP era and NTP timestamp. Prior to 15 October 1582 CE, JDN years arereckoned in 365.25 days; after that, JDN years are reckoned in the Gregoriancalendar. Most historians and Julian calculators do this to avoid PopeGregory's ten-day hole.

Calendar Date	JDN	NTP Date	NTP Era	NTP Timestamp
1 Jan 4713 BC	0.5	-208,657,814,400	-49	1,795,583,104
1 Jan 1 CE	1,721,426.5	-59,926,608,000	-14	202,934,144
15 Oct 1582	2,299,161.5	-10,010,304,000	-3	2,874,597,888
1 Jan 1900	2,415,021.5	0	0	0
1 Jan 1970	2,440,588.5	2,208,988,800	0	2,208,988,800
1 Jan 1972	2,441,318.5	2,272,060,800	0	2,272,060,800
7 Feb 2036	2,464,731.5	4,294,944,000	0	4,294,944,000
8 Feb 2036	2,464,732.5	4,295,030,400	1	63,104
1 Jan 3000	2,816,788.5	34,712,668,800	8	352,930,432

Table 1. NTP Dates

The following notes areintended to clarify what may seem to be odd features about Table 1.

• The JDN day numbers include the fraction 0.5 day or 12 h. This is because the JDN day starts at noon, while all other days in the table start at midnight.
• While the Unix timescale is not shown directly in the table, the correspondence between the NTP and Unix timescales is determined only by the constant 2,208,988,800. This is the number of Gregorian seconds from the NTP prime epoch 0h, 1 January 1900 to the Unix prime epoch 0h, 1 January 1970.
• A careful reader might question the numbering system on and near the origin of the Common Era (CE) 0h, 1 January 1 CE. Since there is no year zero or day zero in the Roman calendar, day zero in in this calendar coincides with 0h, 1 January 1 BCE.

Note the correspondencebetween the NTP date on one hand and the NTP era and timestamp on the other.The signed era number provides the base epoch in multiples of 232 s and the unsigned timestamp theoffset in that era. Conversion between date and era-timestamp formats can bedone by simple cut and paste requiring no arithmetic operations.

The NTP timescale is almostnever used directly by system or application programs. The generic Unix kernelkeeps time in seconds and microseconds (timeval) or seconds and nanoseconds(timespec). These provide both time of day and interval timer functions.

Most Unix kernels implementthe timeval and timespec functions using two signed 32-bitintegers, one representing the seconds since Unix life began at 0h, 1 January1970, and the other the microseconds or nanoseconds of the second. In practice,the seconds integer will changes sign in 68-year intervals,, the next of whichwill happen in 2038. How the particular Unix system copes with this epoch is ofconcern, but is beyond the scope of discussion here.

The most probable solutionwhen 2038 comes near is to replace the 32-bit seconds field of the system clockwith a 64-bit field, and some kernels, including Digital Alpha, have alreadydone that. Certainly a 64-bit integer can be used in the NTP software, but thiscannot be used in packet headers exchanged over the network, as the timestampfields contain only 64-bits and cannot be changed without causing awkwardcompatibility issues, especially as some provision would have to be made tooperate with both 32-bit and 64-bit fields.

4. The NTP Era

As required by the NTPspecification, the NTP reference implementation operate with four 64-bit rawtimestamps to calculate both the clock offset and roundtrip delay. . The onlyarithmetic operation permitted on raw timestamps is subtraction, which producessigned 63-bit timestamp differences from 68 years in the past to 68 years inthe future. When computing timestamp differences and the timestamps are in thesame era, the differences can be calculated directly. If not, in all crediblecases the two eras will be adjacent; that is, if one timestamp is in era n, the other will be in either era n orn + 1.

Consider the case in Figure1, where timestamps are represented as years mod 136. Server clock S is set to 2056 (timestamp 20 in era 1),while the client clock C isset to 2006 (timestamp 106 in era 0).

Figure 1.

If S iswithin 68 years of C = 2006, S can be anywhere between1938 (timestamp 38 in era 0) and 2074 (timestamp 38 in era 1). If, as in thefigure, S and C are expressed asdatestamps, the offset S - C = 2056 - 2006 = 50 years.However, if Sand C are expressed as timestamps, as in the whitepaper NTPTimestamp Calculatins, the offset is S +(-C) = 20+ (136 - 106= 50. mod 136 years. Thus, even if the timestamps span adjacenteras, the offset compuation is correct.

To convert system time in anyformat to NTP format requires only that the number of seconds s from the prime epoch to system time bedetermined. The era number is s /232 and the timestamp is s mod 232. To convert from NTP era number and timestamp to system timerequires only the calculation s = 232 * era + timestamp todetermine the number of seconds since the prime epoch.

 

原文网址：https://www.eecis.udel.edu/~mills/y2k.html

 

SDP RFC 4566也提到了该数字

 

Timing ("t=")

t=<start-time><stop-time>

The"t=" lines specify the start and stop times for a session.
   Multiple "t=" lines MAY beused if a session is active at multiple
   irregularly spaced times; eachadditional "t=" line specifies an
   additional period of time for whichthe session will be active. If
   the session is active at regulartimes, an "r=" line (see below)
   should be used in addition to, andfollowing, a "t=" line -- in which
   case the "t=" line specifiesthe start and stop times of the repeat
   sequence.

The first and second sub-fields give the start and stoptimes,
   respectively, for the session.  These values are the decimal
   representation of Network TimeProtocol (NTP) time values in seconds
   since 1900 [13].  To convert these values toUNIX time, subtract
   decimal 2208988800.

NTPtimestamps are elsewhere represented by 64-bit values, which wrap
   sometime in the year 2036.  Since SDP uses an arbitrary length
   decimal representation, this shouldnot cause an issue (SDP
   timestamps MUST continue countingseconds since 1900, NTP will use
   the value modulo the 64-bit limit).

If the<stop-time> is set to zero, then the session is not bounded,
   though it will not become active untilafter the <start-time>.  If
   the <start-time> is also zero,the session is regarded as permanent.

Userinterfaces SHOULD strongly discourage the creation of unbounded
   and permanent sessions as they give noinformation about when the
   session is actually going toterminate, and so make scheduling
   difficult.

Thegeneral assumption may be made, when displaying unbounded
   sessions that have not timed out tothe user, that an unbounded
   session will only be active until halfan hour from the current time

Handley,et al.             Standards Track                    [Page 17]

 

 
RFC 4566                         SDP                          July2006

or thesession start time, whichever is the later. If behaviour
   other than this is required, anend-time SHOULD be given and modified
   as appropriate when new informationbecomes available about when the
   session should really end.

Permanentsessions may be shown to the user as never being active
   unless there are associated repeattimes that state precisely when
   the session will be active.

 

RFC 4566原文： https://tools.ietf.org/html/rfc4566#section-6