[LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

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.
 Doing something non-standard just to create a unique time scale
doesn't seem like a good enough reason.

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.
    John Sauter (John_Sauter at systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20160425/bb5ed4bc/attachment.pgp>