Re: [LEAPSECS] My FOSDEM slides
> On Mar 6, 2015, at 9:57 PM, Steve Allen wrote: > > On Fri 2015-03-06T21:37:42 -0700, Warner Losh hath writ: >> So it isn't outside the realm of possibilities that you'd have people making >> measurements >> from the late 60's till 1972 using UTC (and yes, it did exist in a practical >> form >> before 1972, just not in the current form and the common usage often leaves >> some >> ambiguity between the actual, realized form as broadcast by WWV, or the >> proleptic >> form w/o leap seconds). Actual measurements from this time, though, were >> based >> on something approaching the UTC as broadcast by WWV. Not sure how many data >> sets from that time survive until today, and how many need to be converted >> from that >> to UT1 or UT2, but evidentially there's some... > > Yes and yes, but these are specialty applications for specialty datasets > which can only be reduced to a precise modern time scale if the original > observations and equipment were meticulously calibrated. > And then they must be reduced by going back to look at, e.g. > https://plus.google.com/photos/112320138481375234766/albums/6078225731350227361 There are a few observatories around here (being in proximity to Boulder) that have data from this time. They know it is only good to a millisecond or so, but that’s UTC not UT. They don’t have to recreate the calibrations or whatever today because they know the data isn’t much better than that. Still, there is some of it that it matters to. Though maybe by now the old professors are gone and the data is too… My data on this is about 15 years old, and even then it was second hand... > Please don't try to make this part of a General Timestamp API. > > Before 1972, for a general API, there is just UT. Generally yes. I agree. For most data, UT is close enough, since that also required a lot of specialty data that you have to look up in books if you want to covert it to elapsed time. I’d make it be opt-in, but I wouldn’t make it impossible. Warner signature.asc Description: Message signed with OpenPGP using GPGMail ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] My FOSDEM slides
On Fri 2015-03-06T21:37:42 -0700, Warner Losh hath writ: > So it isn't outside the realm of possibilities that you'd have people making > measurements > from the late 60's till 1972 using UTC (and yes, it did exist in a practical > form > before 1972, just not in the current form and the common usage often leaves > some > ambiguity between the actual, realized form as broadcast by WWV, or the > proleptic > form w/o leap seconds). Actual measurements from this time, though, were based > on something approaching the UTC as broadcast by WWV. Not sure how many data > sets from that time survive until today, and how many need to be converted > from that > to UT1 or UT2, but evidentially there's some... Yes and yes, but these are specialty applications for specialty datasets which can only be reduced to a precise modern time scale if the original observations and equipment were meticulously calibrated. And then they must be reduced by going back to look at, e.g. https://plus.google.com/photos/112320138481375234766/albums/6078225731350227361 Please don't try to make this part of a General Timestamp API. Before 1972, for a general API, there is just UT. -- Steve Allen WGS-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] My FOSDEM slides
> On Mar 6, 2015, at 7:57 PM, Steve Allen wrote: > > On Sat 2015-03-07T02:02:12 +, Harlan Stenn hath writ: >> When we get a bit more down the road with NTF's General Timestamp API, >> I'd appreciate your taking a look at what we're doing and helping out in >> any way you are up for. One of the issues that will need more attention >> is pre-1972 stuff. > > Before 1972 is pretty simple. > > Without some means of comparing an event with a particular radio > broadcast time signal or a particular astronomical event, everything > before 1972 is just plain UT or GMT back to 1676, and UT before that. Before 1972 there were radio signals. LORAN C was operated from the early 60’s onward, and many receivers existed to recover timing data from them. WWV dates back to the 30’s, with the current Ft Collins transmitter dating from the 1960’s. It started broadcasting UTC time in December 1968. > Any subsecond deviations from what those represent (including worries > about UT0, UT1, UT2) are only available by painstaking inspection (and > re-interpretation into modern terminology) of the tabulations in BIH > Bulletin Horaire. I’m not entirely sure that’s correct. You can recover time to at least tens of microseconds from WWV or LORAN-C, which is quite a bit better than you need to notice the difference between UTC and UT1. With a good cesium standard, synchronized at NBS, running off battery power for the car ride to the lab, WWV could keep you on frequency as well, and you could get sub-microsecond level of performance. I got to hear many tales of the old days when they did this sort of two-way time exchange before satellites. This allowed the frequency broadcast by WWV to be within a few parts in e11 (day it is 100x better). If you read the histories of WWV, they talk about the close proximity to Boulder enabling this. The reason was that the battery backup would be enough to last the 45 minutes or so it takes to go from Boulder to Fort Collins… WWV followed the frequency offset + phase steps in the rubber leap second era, which was an attempt to keep UT1 and UTC not only synchronized, but also syntonized. I find it curious that the practice of adjusting the frequency of the clocks persisted for 5 years after the SI second was defined. So it isn’t outside the realm of possibilities that you’d have people making measurements from the late 60’s till 1972 using UTC (and yes, it did exist in a practical form before 1972, just not in the current form and the common usage often leaves some ambiguity between the actual, realized form as broadcast by WWV, or the proleptic form w/o leap seconds). Actual measurements from this time, though, were based on something approaching the UTC as broadcast by WWV. Not sure how many data sets from that time survive until today, and how many need to be converted from that to UT1 or UT2, but evidentially there’s some... Warner signature.asc Description: Message signed with OpenPGP using GPGMail ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] My FOSDEM slides
On Sat 2015-03-07T02:02:12 +, Harlan Stenn hath writ: > When we get a bit more down the road with NTF's General Timestamp API, > I'd appreciate your taking a look at what we're doing and helping out in > any way you are up for. One of the issues that will need more attention > is pre-1972 stuff. Before 1972 is pretty simple. Without some means of comparing an event with a particular radio broadcast time signal or a particular astronomical event, everything before 1972 is just plain UT or GMT back to 1676, and UT before that. Any subsecond deviations from what those represent (including worries about UT0, UT1, UT2) are only available by painstaking inspection (and re-interpretation into modern terminology) of the tabulations in BIH Bulletin Horaire. Of course I'm ignoring any timezones. That's a whole 'nother layer of painstaking historical investigation for any given locale. -- Steve Allen WGS-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] My FOSDEM slides
Paul, Paul Hirose writes: > I distribute a Windows astronomical toolbox DLL which includes time > scale conversions. Since astronomy often requires analysis of old > data, the DLL can deal with pre-1972 UTC. I won't get into the dispute > over whether or not that's bona fide UTC! However, the IERS and USNO > recognize it as such, so I assume the user will expect time > conversions to work in that era. (I have never needed that capability > myself.) When we get a bit more down the road with NTF's General Timestamp API, I'd appreciate your taking a look at what we're doing and helping out in any way you are up for. One of the issues that will need more attention is pre-1972 stuff. -- Harlan Stenn http://networktimefoundation.org - be a member! ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] My FOSDEM slides
On 2015-03-06 11:04, Brooks Harris wrote: The "rubber-band era" is just entirely irrelevant. Its historically interesting, and may be required for some special application concerning that period, but for practical "UTC-like" timekeeping its just an historical curiosity. This fact is somewhat more apparent looking at the IERS publication Leap_Second_History.dat, at https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. There we see *no values* before "1 1 1972" - the "rubber-band era" is gone. That's correct - the "rubber band era" no long exists. Since the name of the document is "leap second history", the rate offsets and fractional second step adjustments before 1972 aren't applicable. They can be found elsewhere at the IERS site: http://hpiers.obspm.fr/eop-pc/index.php?index=UTC&lang=en I distribute a Windows astronomical toolbox DLL which includes time scale conversions. Since astronomy often requires analysis of old data, the DLL can deal with pre-1972 UTC. I won't get into the dispute over whether or not that's bona fide UTC! However, the IERS and USNO recognize it as such, so I assume the user will expect time conversions to work in that era. (I have never needed that capability myself.) ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] My FOSDEM slides
Hi Zefram, >> Your focus on epochs is unhealthy. I don't claim to be any more healthy than the many other folks I've had these discussions with, most of whom are *obsessed* with, and *insistent upon*, specifying a known *immovable* epoch. I think I could characterize your focus on using "scalar values" as a bit unhinged. :-) The difference in our thinking seems to be my objective of placing the various timescale epochs at fixed offsets from 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) v.s. yours that allows the epochs to slip with each Leap Second in the manner NTP and POSIX do, which is, as you call it, "scalar". Indeed, I think one of the reasons many people feel the need to use a "TAI-like" timescale is that generally those timescale's epochs are *fixed*, whereas with the NTP and POSIX implementations of "UTC-like" timescales, the epochs *slip*, essentially creating a new timescale with a different epoch offset to 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) with each Leap Second. I've actually tried to answer your earlier emails but each time it's turned to a multi-page essay and I never quite completed it. I'll try to finish that, but here I'll try to quickly answer your comments. On 2015-03-05 01:29 PM, Zefram wrote: Brooks Harris wrote: The first part of that sentence is correct "The PTP epoch is 1 January 1970 00:00:00 TAI". But the second part, "which is 31 December 1969 23:59:51.18 UTC", is not, or, is at least very misleading. It's correct to the microsecond precision given. My only real correctness concern there is that it implies an exact equivalence which there isn't. However, it is somewhat misleading by virtue of failing to explicate that it is using the rubber-seconds UTC which is otherwise irrelevant to PTP. Yes, it is "otherwise irrelevant to PTP". Thats my point. All the discussion about the rubber-band period and use of "the POSIX algoritm" is beside the point for practical implementation, and hence, only a misleading distraction. Table B.1-Relationships between timescales >From | To | Formula NTP Seconds | PTP Seconds | PTP Seconds = NTP Seconds - 2 208 988 800 + currentUtcOffset PTP Seconds | NTP Seconds | NTP Seconds = PTP Seconds + 2 208 988 800 - currentUtcOffset ... These are the values you must use for a practical implementation of PTP, and that is the convention adopted by the PTP community. These values *contradict* the second part of the epoch specification sentence No, there is no contradiction there. The table makes no claim about the correspondence between TAI and UTC at any particular point in time. It does if your objective is to link PTP time to the fixed epoch of 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI), to the NTP prime epoch of era 0, and to the POSIX "the Epoch". It can *also* be interpreted as scalar offsets, as you are interpreting them, yes, if that's how you need to use them. It makes correct claims about the correspondences between various scalar representations of time. The only subtlety is the "currentUtcOffset" term in the PTP<->NTP equations. The currentUtcOffset (meaning (TAI-UTC)/s) is not defined for all points in time, and during the rubber-seconds era of UTC it takes on non-integral values. Not in a practical timescale implementation. The "rubber-band era" is just entirely irrelevant. Its historically interesting, and may be required for some special application concerning that period, but for practical "UTC-like" timekeeping its just an historical curiosity. This fact is somewhat more apparent looking at the IERS publication Leap_Second_History.dat, at https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. There we see *no values* before "1 1 1972" - the "rubber-band era" is gone. That's correct - the "rubber band era" no long exists. [By the way, I think this document is the most well formed information about TAI/UTC. By using MJD there is no mistaking on what day each Leap Second occurs. I haven't found any official information at IERS about the policies of this document's publication but I think this may be the best source of official Leap Second information available. Note it includes the upcoming 2015-07-01 Leap Second.] In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset = 10s. PTP time does not exist before this date-time. Official TAI exists from the origin of 1958-01-01T00:00:00 (TAI). "Integral second UTC" didn't exist before 1972-01-01T00:00:00Z (UTC). Thats where you need a timescale that is an integral second measure proleptic to 1972-01-01T00:00:00Z (UTC), the timescale I keep trying to explain. With that, the PTP epoch is 1970-01-01T00:00:00 (TAI) = 1969-12-31T23:59:50Z (UTC). By the way, I think its unfortunate they didn't specify the epoch as "1970-01-01T00:00:10 (TAI)" (note the 10s) because then it would coincide exactly with POSIX
