Re: [LEAPSECS] Civil timekeeping before 1 January 1972
How fare back before 1972 do you want to go? Before leap seconds, before TT, TDT, TAI. Entangled in the roots of ET and Delta-T... Back in the 70s and 80s there was considerable effort at JPL to improve the models of orbital motion of the Galilean satelltes of Jupiter. The existing theory, dating back to ~1915, was marginal for the pointing needs of the high resolution cameras on Voyager and especially the more demanding needs of the planned Galileo mission. Among the data sources for developing and testing the new orbital models were historical observations of satellite eclipses. Useable records of several thousand historical observations going back as far as the mid 1600's have been recovered. But making use of these posed quite a problem in converting the reported times to a modern form. Depending on the source, the times might be expressed in apparent time, mean time, or sidereal time. Nothing specific to leap seconds here, just a little perspective for thinking about the measurement and representation of time. And for Tom van Baak-- About a month ago you relayed a question about computing the Equation of Time to high accuracy. I mentioned that in the context of precision ephemerides the EoT would be obtainable but usually would not be a quantity of primary interest. Expanding an expression for EoT to higher accuracy generally wasn't done. (of course that's not how I said it but it's what I wanted to get across.) There is a proliferation of small cross terms (not so much a slowness of convergence as I stated), and also below the ~5 second level you start needing to consider the rate of change in eccentricity of the Earth's orbit, apsidal and nodal precession, etc. You need to reevaluate the coefficients of the angular terms, and the angle offsets every decade or so. Well, one of the papers that came out of this work at JPL shows a counterexample! Lieske, Astronomy Astrophysics Supplement Series #63 (1986) pp 143-202 A Collection of Galilean Satellite Eclipse Observations, 1652-1983 Sections 3 4 discuss reduction of observed times to 'UT'. Used EoT, delta-T, and mentions uncertainties in delta-T due to uncertainty in Lunar acceleration. Smart, Textbook on Spherical Astronomy shows how the EoT expansion is developed. Richard NSO/NISP Tucson, AZ On Thu, 12 Mar 2015, Tom Van Baak wrote: ... I do a lot of timekeeping here, old and new. What time_t looked like before 1972 is not a problem. Yes, civil timekeeping (before or after 1972) is an interest to me. But all the older stuff arrives in the form of faded paper, or JPG photos, or TXT files. I would never think of trying to encode that into some 32 or 64 bit binary format. /tvb ___ 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
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
I didn't think that NTP or POSIX or PTP is what we'd call a timescale. NTP is a UTC synchronization algorithm. If we give the subword scale its usual meaning, then NTP is a (also) a timescale: It carefully defines the scale on which it is going to synchronize computer clocks, in particular it defines the measurement unit on this scale to be 2^-32 SI second and the handling of epoch roll-overs (every 2^32 SI seconds). But more importantly, when we get to the point were we are arguing over the meaning of common well known words we might as well stop it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
Hi Tom, On 2015-03-12 09:50 PM, Tom Van Baak wrote: Brooks wrote: Many timekeeping systems seem to be designed for only indicating now counting forward, including NTP, POSIX, and PTP, taking short-cuts to avoid supplying full Leap Second and local-time metadata. Warner wrote: A clock doesn’t need to know its past. But a time scale is more than just how many seconds the current minute will have. It has a history and to compute elapsed time in that time scale, you need to know its history. Ok, thanks. So there's a terminology issue among Brooks' timekeeping system, Tom's clock, and Warner's timescale. Oh yes, there sure are terminology issues all over the place. Its a frustration of mine - expert debate endlessly about details to finally discover they're talking about the same things in different term. Timekeeping is old, there's lots of terms. Keeping thing clear is a challenge. I didn't think that NTP or POSIX or PTP is what we'd call a timescale. I do, I think. I think of a timescale as having - A) Some unit measure of time. Typically seconds, but could be some other convenient division of time. B) Some origin or epoch - a starting point for counting, might be signed or unsigned. C) Some counting method - as simple as uninterrupted incrementing count, or more complex like Gregorian for example Counting method deserves more explanation. I use the term to encompass a couple concepts. A counting method could be a simple integer number counting scheme (0,1,2,3,...) or generate a more complex encoding like 1972-01-01T00:00:00. We've come to use the term time related label - a lable being an 'identifier' assigned to some particular item in a sequence of time-related units. A time related label may be generated by the rules of *pure* Gregorian calendar counting method - 1972-06-30T23:59:59 1972-07-01T00:00:00 Or Gregorian calendar modified by UTC Leap Seconds counting method - 1972-06-30T23:59:59 1972-06-30T23:59:60 1972-07-01T00:00:00 These might be represented as broken down time ie: YY-MM-DD hh:mm:ss values. There may be a corresponding absolute integer value for these seconds, like time_t. Here the counting method is a zero-based uninterrupted incrementing count, and each number is a time related label of each second. Put another way, the counting method is the algorithm by which the time value is encoded as a time related label. NTP is a UTC synchronization algorithm. Hmmm. Well, yes, I suppose. Hadn't thought of it that way. If Leap Seconds are properly applied to it it effectively becomes many independent timescales because the epoch slips with respect to 1972-01-01T00:00:00Z (UTC) with each Leap Second. I think I'd say its an algorithm that synchronizes Gregorian calendar date and time representations with UTC. Of course its obviously flawed where the 23:59:60 count is concerned. UT0 is a measurement. OK. UT1 is a timescale. OK. TAI is a timescale. Yes - a timescale with a simple counting method - an uninterrupted incrementing count of seconds UTC is a timescale. Yes - a timescale with a complex, irregular, and partly unpredictable counting method. There are clock ensemble algorithms. There are time transfer methods. There are time encoding conventions. There are time API's in languages, libraries, or operating systems. Sure, and its important to keep the divisions between what we're talking about clear. WWVB is not a timescale. It is a time (and frequency) transfer service for UTC(NIST). Yes, with a protocol for communicating the current UTC value along the UTC timescale. GPS is not a timescale. It is a navigation positioning (and time transfer) service based on UTC(USNO). Hmm. Right, well, GPS time is a timescale - time measure in seconds, epoch at 1980-01-06T00:00:00Z (UTC), counting method of uninterrupted weeks. While its epoch is referenced to UTC, its (primary) counting method is TAI-like - uninterrupted regular count. It is GPS time on the GPS timescale that is 'transferred', no? I'm not trying to pick a fight here. Just trying to seek clarification. Thanks. I appreciate a productive conversation. The lexicon is always at the root of the misunderstandings. This is critical when gets to standards documents It has to be as clear and commonly understood as possible and agreed on. That's part of the difficulty with UTC, other timescales, and the whole subject of time - the documents are often written is very different terms making understanding and comparisons difficult. I guess I still don't understand what Brooks is trying to sell, or why full historical phase or frequency records are any part of timekeeping, or time transfer. To calculate accurate time intervals (durations) and/or elapsed times. How many seconds between 1972-06-30T23:59:59Z (UTC) and 1972-07-01T00:00:00Z (UTC)? *Two*. But to know that you need to know a positive Leap Second occured at 1972-06-30T23:59:60Z (UTC). Put it another way
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
On Fri 2015-03-13T07:29:40 +, Poul-Henning Kamp hath writ: But more importantly, when we get to the point were we are arguing over the meaning of common well known words we might as well stop it. That's kindof funny because two weeks from now in Geneva at the CPM15-2 meeting for Agenda Item 1.14 there are going to be a whole bunch of delegations arguing over the meaning of calendar day with some insisting that it is related to the rotation of the earth and others denying the validity of the question. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
On Thu, 12 Mar 2015 18:50:56 -0700, Tom Van Baak wrote: I didn't think that NTP or POSIX or PTP is what we'd call a timescale. As discussed in other responses, a timescale requires only three things, a definition of zero time (or a specified time), a definition of the second (or some other time duration unit), and a progression rule. That's it. By this definition, all three (NTP, POSIX, PTP) define private timescales for their own internal use, and translate to and from external timescales as needed. NTP is a UTC synchronization algorithm. NTP is a synchronization algorithm for sure, but NTP is not limited to UTC, even though the RFCs speak of UTC. Lots of people use NTP to distribute GPS System Time, and I bet that there are people now using NTP to distribute TAI. UT0 is a measurement. UT1 is a timescale. TAI is a timescale. UTC is a timescale. UT0 *is* a timescale, one that is tied to a specific astronomical observatory. Multiple UT0 timescales are combined to yield UT1, and UTC is derived from UT1. Joe Gwinn ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
