[ntp:questions] Re: Re: NTP4 has 3 different time formats!Namly(32, 64, 128) bits wide

David J Taylor david-taylor at blueyonder.co.not-this-bit.nor-this-part.uk
Sun Jul 16 05:27:07 UTC 2006


Danny Mayer wrote:
> David J Taylor wrote:
>> Danny Mayer wrote:
>>> Richard B. Gilbert wrote:
>>>> NTP could do worse than to adopt the VMS 64 bit time format.  IIRC
>>>> it was a count of 100 nanosecond "ticks" since some date in (I
>>>> think) November 1857.
>>> 18 November, 1857 to be exact! See, I still remember!
>>
>> I often wondered why that base was chosen - something to do with the
>> Smithsonian?
>>
>
> Oops, I'm off by a year, it's 1858. From this URL if you want all of
> the details:
> http://vms.tuwien.ac.at/info/humour/vms-base-time-origin.txt
>
> "So why 1858? The Julian Day 2,400,000 just happens to be November 17,
> 1858.
> [...]
>
> The Modified Julian Day was adopted by the Smithsonian Astrophysical
> Observatory (SAO) in 1957 for satellite tracking. SAO started tracking
> satellites with an 8K (non-virtual) 36-bit IBM 704 computer in 1957,
> when Sputnik was launched. The Julian day was 2,435,839 on January 1,
> 1957. This is 11,225,377 in octal notation, which was too big to fit
> into an 18-bit field (half of its standard 36-bit word). And, with
> only 8K of memory, no one wanted to waste the 14 bits left over by
> keeping the Julian Day in its own 36-bit word. However, they also
> needed to track hours and minutes, for which 18 bits gave enough
> accuracy. So, they decided to keep the number of days in the left 18
> bits and the hours and minutes in the right 18 bits of a word."
>
> Danny

Thanks, Danny.  The reference also states:

  "The year 1858 preceded the oldest star catalog in use at SAO, which 
also avoided having to use negative time in any of the satellite tracking 
calculations."

which explains why that particular year was chosen as the new base for 
Modified Julian Date.  It then goes on to say:

  "This base time of Nov. 17, 1858 has since been used by TOPS-10, 
TOPS-20, and VAX/VMS.  Given this base date, the 100 nanosecond 
granularity implemented within VAX/VMS, and the 63-bit absolute time 
representation (the sign bit must be clear), VMS should have no trouble 
with time until:

   31-JUL-31086 02:48:05.47

  "At this time, all clocks and time-keeping operations within VMS will 
suddenly stop, as system time values go negative.

  "Note that all time display and manipulation routines within VMS allow 
for only 4 digits within the 'YEAR' field.  We [Digital] expect this to be 
corrected in a future release of VAX/VMS sometime prior to 31-DEC-9999."

<G>

David 





More information about the questions mailing list