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_sau...@systemeyescomputerstore.com) -- PGP fingerprint = E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs