[LEAPSECS] Leap Seconds schedule prior to 1972

[Brooks Harris]

On 2016-04-25 12:54 AM, John Sauter wrote:
> On Sun, 2016-04-24 at 20:33 -0400, Brooks Harris wrote:
>> Hi John,
>>
>> I like the idea in general, even if its a solution in search of a
>> problem. I think many fields would find it useful if it found
>> agreement and acceptance.
>>
>> Consider this:
>>
>> For your "specification" I'd suggest you define the data type
>> generically so it can be implemented, represented, and transported by
>> various platforms and technologies - c/c++, Java, .NET, XML, REST,
>> SQL, etc, etc.
>>
>> There are two critical data values: the "date" value and the TAI-UTC
>> value. Some *comments* in YMDhms form is probably be helpful (what
>> does date -123456 mean?), but the "date" variable value takes
>> precedence.
>>
>> Define day zero as the first day of the integral UTC era - 1972-01-01
>> 00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC) is the calibration point
>> at which the relationship between atomic time and observed mean solar
>> time was made to converge on exactly 10 integral seconds as
>> determined by the development process of UTC.
>>
>> Use negative 86400 second days as the "date" variable. Thus the last
>> day of your timescale is -1, which is also the last day of the
>> "rubber band UTC era" .
>>
>> With that you've created a timescale of your own with no confusion or
>> controversy with Julian date, MJD, or NTP seconds and with an
>> unambiguous relation to UTC. A statement of how each of these are
>> aligned to your proleptic timescale might be useful or necessary but
>> your timescale is not dependent on the definitions or interpretation
>> of these other timescales.
>>
>> The range is as high as you want - its probably not necessary to
>> point out a signed 64-bit day number value is a very large number of
>> days, something like -25,252,216,391,115,000 years, which should
>> cover it. I'll leave it to your research to decide how many Leap
>> Seconds that might require.  :-)
>>
>> I'd also point out a data type using a 21-bit day number counter and
>> an 11-bit TAI-UTC value variable can support a range of approximately
>> 3000 years in 4 bytes, 32-bits. This is a nice small data type
>> suitable for fast transfer and compact storage in binary
>> implementations.
>>
>> -Brooks
>>
> Hi Brooks,
>
> I agree that the data file should have comments which express the dates
> as year-month-day.  However, I don't understand the benefit of coding
> the date as negative 86,400-second days.  There is already a well-
> understood and widely used coding for days: the Julian Day Number.
Hi John,

"understood and widely used ", yes. Standardized by an international 
standards organization, I'm not sure. Anyone know of one? There's a lot 
of things in timekeeping that are done on a "common practice" or "de 
facto standard" basis. In some cases these are not as commonly 
understood as one might wish.
>   Doing something non-standard just to create a unique time scale
> doesn't seem like a good enough reason.
It can avoid any ambiguity of interpretation if its clearly defined 
especially its alignment to 1972-01-01
00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC).

Julian Day has an epoch of "12 noon 1 JAN -4712 (4713 BC)". Beyond that 
you've got to go to a "proleptic Julian Date" which is not exactly 
"standard". A negative 86400 second day number extends to the 
arbitrarily distant past depending on how many bits you decide to carry.

Julian Day may be OK. But somebody might ask when, exactly, did the 
Chicxulub meteor impact? I know that's beyond your scope but your 
timescale extended further as need arose.

>
> I am happy for programs which read the data file to compress it to suit
> their needs, but TAI-UTC won't fit in 11 bits if you want to go back to
> the year -1000, which has a DTAI over 25,000.

Right. Depends on how far back you want to go. 11-bits TAI-UTC gives you 
2048 Leap Seconds, so, by your table 1, back to year 1000 or there 
abouts. That would be good enough for a lot of historical events. Who 
uses it for what would drive the implementation choices. 32-bits is very 
lightweight. Its just an observation - your target range is bigger.

-Brooks

>      John Sauter (John_Sauter at systemeyescomputerstore.com)
>
>
> _______________________________________________
> 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/20160425/f128de0b/attachment.html>