[LEAPSECS] Time math libraries, UTC to TAI

Brooks Harris brooks at edlmax.com
Thu Jan 5 06:42:41 EST 2017


On 2017-01-02 03:07 PM, Michael.Deckers. via LEAPSECS wrote:
>   On 2017-01-02 18:55, Brooks Harris wrote about the correspondence
>
>       | Date        | MJD        | NTP | NTP Timestamp | 
> Epoch            |
>       | 4 Oct 1582  | -100,851   | -3  | 2,873,647,488 | Last day 
> Julian  |
>
>
>> Ah, I think the table is correct - that's the infamous reset made by 
>> the Gregorian calendar  to correct accumulated inaccuracies in the 
>> Julian and also, I believe, counted days at midnight, not noon, as 
>> Julian did (does).
>
>    Sure, the Julian date of the day before the day with Gregorian date 
> 1582-10-25
>    is 1582 Oct 04 -- but the epoch given in the table with the MJD 
> value and the
>    NTP timestamp values is obviously 10 days earlier: they all 
> indicate Julian date
>    1582 Sep 24 and Gregorian date 1582-10-04, as I have noted earlier.
I'm not understanding where you think there is an error. I think all the 
"Dates" are intended to be Gregorian and proleptic Gregorian, that the 
NTP timestamp example values are on 86400-second-day midnights, and that 
MJD and "proleptic MJD" are treated as 86400-second-days. The values 
seem correct to me by that reckoning.

It is in contrast to the example in
Julian Date Converter
http://aa.usno.navy.mil/data/docs/JulianDate.php

But there, the YMDhms representations are specifically stated to be 
(Julian) and (Gregorian), so its not the same as the NTP table treatment.

>    The table indicates the (not usual) confusion about "omitted days" 
> where
>    it is unclear which numbers should be decreased (or increased) by ten.
>    I do not want to be sarcastic but my managers would refuse to buy 
> software
>    when the spec (already) contains such blunders.
I'm not seeing there is a blunder. However I think it would have been 
more clear if the "Date" column were titled "Gregorian Date".

Note too that the (Last day 20th Century) entry is also on 
86400-second-day boundaries, that there is no Leap Second value applied. 
This is consistent with NTP's behavior, that the 
"seconds-since-NTP-epoch" has been "pulled up" with repsect to 
1972-01-01T00:00:00 (UTC) by the absence of the 23:59:60 count, and so, 
as David Wells has said "In effect, a new timescale is reestablished 
after each new leap second. Thus, all previous leap seconds, not to 
mention the apparent origin of the timescale itself, lurch backward one 
second as each new timescale is established. "

The NTP Timescale and Leap Seconds
https://www.eecis.udel.edu/~mills/leap.html

>
>    And dates in the Julian calendar are taken to begin at midnight, as 
> in the
>    Gregorian calendar. It is the Julian day numbers used in astronomy 
> that
>    take integral values at noon epochs -- but they have nothing to do 
> with
>    the Julian calendar, except perhaps for the origin of the name.

As far as the "Julian" name and the midnight v.s. noon topics, like 
everything in timekeeping there is long history of terms and 
intersection of disciplines. I learn something new with every 
investigation. (thanks, Stephen Scott, for the reference)

Julian Day Numbers by Peter Meyer
http://mooring.ucsd.edu/software/matlab/mfiles/toolbox/misc/timefun/doc/pm_julian.txt
http://www.hermetic.ch/cal_stud/jdn.htm

Note that ITU Rec ITU-R  TF.457-2 and most other explanations of MJD 
have apparently adopted Herschel's astronomical treatment of Julian Days 
(noon-to-noon), but don't explicitly say so.

RECOMMENDATION  ITU-R  TF.457-2, USE  OF  THE  MODIFIED  JULIAN DATE  
BY  THE  STANDARD-FREQUENCY AND  TIME-SIGNAL  SERVICES
http://www.itu.int/rec/R-REC-TF.457-2-199710-I

Now, one could ask, what is the MJD length-of-day after 
1972-01-01T00:00:00 (UTC)? Rec 457-2, nor any other explanations of MJD 
I've seen, says anything about that. I have to take it to mean MJD days 
are always 86400 seconds.

How should the MJD values in IERS Leap_Second_History.dat file be treated?

https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat

It turns out to be convenient and consistent to treat the MJD values as 
86400-second-days. Thus, to use the (Last day 20th Century) example from 
RFC 5905 Figure 4: Interesting Historic NTP Dates:

    | 31 Dec 1999 | 51,543     | 0   | 3,155,587,200 | Last day 20th    |
    |             |            |     |               | Century          |

MJD 51543 - 41317 = 10226 MJD days-since-UTC1972 * 86400 = 883526400 
seconds + (32 TAI-UTC - 10) = 883526422 seconds-since-UTC1972.

883526422 seconds-since-UTC1972 + 2272060800 
seconds-NTPEra0-to-UTC1972-offset - 22 Leap Seconds = 3155587200 (NTP 
timestamp)

-Brooks

>
>    Michael Deckers.
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20170105/b11a9c88/attachment-0001.html>


More information about the LEAPSECS mailing list