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_sau...@systemeyescomputerstore.com)
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
