Re: [LEAPSECS] Civil timekeeping before 1 January 1972
The tabulations of the times of emission of radio broadcasts of UTC were given in units of, and with an accuracy of 0.0001 s; i.e., 100 microseconds. The tabulations of the intercomparisons between the time scales in those laboratories are given with decimals to 0.1 microsecond, or 100 nanoseconds. I don't believe 3 ns is significant for any time stamp from that era. Steve and Paul, To further add perspective to 1960's timescales, read these wonderful papers: Correlating Time from Europe to Asia with Flying Clocks http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1965-04.pdf World-Wide Time Synchronization, 1966 http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1966-08.pdf 'Flying Clock' Comparisons Extended to East Europe, Africa and Australia http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1967-12.pdf The articles should give you a better feel for what timekeeping, clocks, and timescales are. Does your C# code incorporate the notion of error bars? If your users are scientific, perhaps they need to know how uncertain timescale conversions are. Thanks, /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
On Tue 2015-05-05T15:32:30 -0700, Paul Hirose hath writ: The rubber time era can be tricky. I just finished a major rewrite of my UTC implementation in the C# language. The goal was improved accuracy before 1972. Although the old version passed all my tests at 1 microsecond accuracy, it began failing when I tightened the error tolerance to 1 nanosecond. And it should fail, and you should not be concerned. I am looking at the BIH Circular D63 from the end of 1971/beginning of 1972 which tabulated the time from laboratories around the world (that particular issue being the one that saw the transition from rubber seconds to SI seconds). The tabulations of the times of emission of radio broadcasts of UTC were given in units of, and with an accuracy of 0.0001 s; i.e., 100 microseconds. The tabulations of the intercomparisons between the time scales in those laboratories are given with decimals to 0.1 microsecond, or 100 nanoseconds. I don't believe 3 ns is significant for any time stamp from that era. Right. There is no record of the available time scales that can say anything about the time differences at that level. -- Steve Allen s...@ucolick.org WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +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 2015-03-06 18:02, Harlan Stenn wrote: 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. The rubber time era can be tricky. I just finished a major rewrite of my UTC implementation in the C# language. The goal was improved accuracy before 1972. Although the old version passed all my tests at 1 microsecond accuracy, it began failing when I tightened the error tolerance to 1 nanosecond. A couple adjacent lines from the USNO table show the problem: 1966 JAN 1 =JD 2439126.5 TAI-UTC= 4.3131700 S + (MJD - 39126.) X 0.002592 S 1968 FEB 1 =JD 2439887.5 TAI-UTC= 4.2131700 S + (MJD - 39126.) X 0.002592 S The last instant of the first line is 1968 Jan 31 23:59:59.9, since a step adjustment shortens the last minute. The first instant of the second line is 1968 Feb 1 00:00:00. These UTC epochs are equivalent and should convert to the same TAI. But if you do the math, the second line yields a TAI 3 ns after the first line. In other words, there's a 3 ns slice of TAI with no UTC equivalent. The reason is the rate correction, which in both lines is (MJD - 39126.) * 0.002592 s, where MJD is UTC in the form of a modified Julian date. In the first line the expression in parentheses yields a true amount of rubber time since the base epoch MJD 39126. In the second line that's not the case. Due to the step adjustment, subtracting 39126 from UTC yields a value .1 s greater than the actual elapsed time. That's about 1.16e-6 days. Multiply by the .002592 s/day that TAI gains on UTC, and you get the 3 ns discrepancy. I don't believe 3 ns is significant for any time stamp from that era. Anyway, the number of decimal places in the USNO table (4.3131700 etc.) implies accuracy to only 100 ns. However, my implementation is capable of time scale conversions accurate to 1 ns with a comfortable margin. I wanted to realize that potential. The solution was to leave the step adjustments as-is and make subtle adjustments to the rates. This was more difficult than I expected. The user is responsible for loading the USNO text file at run time, so none of the work can be done in advance. Moreover, my implementation is designed to support experimental modifications to the UTC table, even wild stuff like re-introduction of rate offsets. Thus nothing can be assumed. My solution is to make one pass through the USNO file to construct a preliminary table. Then a pass through the table puts in the step adjustments, which are implied by the USNO data but not listed. A final pass makes the rate adjustments. At the user's option the last can be omitted for a literal version of the USNO table. It was a lot a trouble to get there, but I'm now accurate to a nanosecond. You probably won't get that crazy, but testing for discontinuity as you cross from one table entry to the next is still a must. That's especially true pre-72, where it's easy to make a mistake. One of my tests is to compute TAI for two epochs one microsecond either side of the boundary between table entries. For instance, for the lines I included above, I'd begin with UTC epochs 1968 Jan 31 23:59:59.9 - 1 us, and Feb 1 00:00:00 + 1 us. Convert both UTCs to TAI, and verify the TAIs differ by 2 us. (Formally, the correct value isn't exactly 2 us due to the rate difference between TAI and UTC. But that's insignificant over such a short span.) Also, you should convert both TAIs back to UTC and verify accurate round trips. It might seem that you could begin with UTC epochs Jan 31 23:59:59.9 and Feb 1 00:00:00, convert to TAI, and verify zero difference (within a given tolerance). The problem is that both TAIs can map to the same table entry when you round trip them to UTC, and so the other entry doesn't get tested as expected. (In my implementation each entry does both UTC - TAI and the reverse.) Of course an accurate round trip UTC - TAI - UTC doesn't prove TAI is correct. You have to check that separately. I don't take any position on whether or not pre-72 is really UTC. However, both IERS and USNO seem to recognize it as such, so I assume users of my software may expect that as well. Similar decisions will face programmers if leap seconds are discontinued but the time scale keeps the same name. If you subsequently release a software package that converts between UTC and other scales, you'll have to decide whether or not to support the leap second era. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
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
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
Hi Tom, On 2015-03-12 02:57 AM, Tom Van Baak wrote: Brooks, A couple more comments on your questions. 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. I'm not clear why you call that a short-cut. It's just how clocks works. Right, that's how a traditional clock works but that's fundamentally inadequate when the UTC counting methods are in use. What I meant by short-cut is that the UTC metadata (Leap Second announce and table) are generally not provided or accounted for. NTP and POSIX drop the 23:59:60 count. They work like a traditional clock, not like a UTC clock. They tick forward and there is no requirement that they keep a record of time in the past. Right, Thats' the traditional concept of a clock. But we very much need to calculate durations - how long ago did an event happen?, how long was it between event A and event B?, when is event A scheduled to occur? Traditionally, days were 86400 long, so calculating durations was simple. Days are 86400 long in NTP and POSIX, so calculating durations is simple BUT it doesn't match UTC! How many seconds between 1972-06-30T23:59:59Z (UTC) and 1972-01-01T00:00:00Z (UTC)? Two, not one, because in NTP and POSIX 1972-06-30T23:59:60Z (UTC) went missing. Furthermore, any clock keeping UTC has no need for local time metadata. So you should not lump the tz mess into the simplicity of keeping UTC. Right, well, typically the objective is to indicate local civil time. Only those jurisdictions at -00:00 offset from the UTC can use UTC, and even then might observe Daylight. Humans care about local civil time - only the timekeepers care about UTC who use it as the reference timescale from which local civil time is derived. Yes, of course, the whole topic of the tz mess is dragged into the calculation, which is outside of UTC timekeeping discussion proper, but still required for practical purpose of indicating local civil time and coordinating activities by those time representations. The only thing a UTC clock requires is advanced notice of the length of the current minute. In principle the announce could be even faster than that to keep counting forward, but to schedule an event in the future you need either the next upcoming Leap Second or how long in the future *we are sure* there will not be a Leap Second. This is required by no later than second 58 in the minute. Right. But for practical reasons a UTC clock typically gets more notice than that, as you know. The more notice you have, the further in the future you can confidently schedule, or predict. Currently the announcements are essentially done by humans. ITU-R Rec 460 says The IERS should decide upon and announce the introduction of a leap-second, such an announcement to be made at least eight weeks in advance. That gives the humans at IERS time to create and publish Bulletin C and presumably all the timekeeper humans enough time to implement the upcoming Leap Second into their time servers or protocols. IERS has done this at least eight weeks in advance. The most recent Bulletin C was issued nearly six months in advance. Note, however, its not clear *exactly when* it was issued. I became aware of it like on Jan 2, but you'd really like to know *exactly* when it was issued. Of course you'd really like to have this notification *automatically* issued and taken up by all time servers, protocols, and applications everywhere. I've never been able to understand why that practice persists despite the obvious need to be able to fully represent the entire post-1972 UTC timescale. The policy and forms of the announce signals and Leap Seconds table are obvious missing links, and its regrettable no official attempt has been made since 1972 to rectify those inadequacies. I don't know what you mean by represent the entire post-1972 timescale. Or why such a need is obvious. As Warner said in another LEAPSEECS post - 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. You don't have a definition of what your clock means if you don't have a specification of the timescale its representing. For the UTC timescale you need the Leap Second metadata - all of it. A clock does not need to represent the infinite past, present, and future of a timescale. In the case of UTC the near future is unknowable anyway. The present is the requirement. And the past may or may not be a requirement depending on the user. Certainly a stand-alone RTC or time code generator or data logger or cesium clock keeping UTC does not need to know the past. So a historical table is not important. Only the leap second notification is needed. That's why the time codes you
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
On Mar 12, 2015, at 3:57 PM, Tom Van Baak t...@leapsecond.com wrote: Brooks, A couple more comments on your questions. 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. I'm not clear why you call that a short-cut. It's just how clocks works. They tick forward and there is no requirement that they keep a record of time in the past. Furthermore, any clock keeping UTC has no need for local time metadata. So you should not lump the tz mess into the simplicity of keeping UTC. The only thing a UTC clock requires is advanced notice of the length of the current minute. This is required by no later than second 58 in the minute. But for practical reasons a UTC clock typically gets more notice than that, as you know. I've never been able to understand why that practice persists despite the obvious need to be able to fully represent the entire post-1972 UTC timescale. The policy and forms of the announce signals and Leap Seconds table are obvious missing links, and its regrettable no official attempt has been made since 1972 to rectify those inadequacies. I don't know what you mean by represent the entire post-1972 timescale. Or why such a need is obvious. A clock does not need to represent the infinite past, present, and future of a timescale. In the case of UTC the near future is unknowable anyway. The present is the requirement. And the past may or may not be a requirement depending on the user. Certainly a stand-alone RTC or time code generator or data logger or cesium clock keeping UTC does not need to know the past. So a historical table is not important. Only the leap second notification is needed. That's why the time codes you see broadcast, like WWVB or GPS only include a leap second notification and not a full table. By the way, the downside of WWVB's format is that it is not possible to obtain TAI. With GPS, at least, TAI is not only possible but easier and more reliable than UTC. 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. 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] Civil timekeeping before 1 January 1972
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. I didn't think that NTP or POSIX or PTP is what we'd call a timescale. NTP is a UTC synchronization algorithm. UT0 is a measurement. UT1 is a timescale. TAI is a timescale. UTC is a timescale. 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. WWVB is not a timescale. It is a time (and frequency) transfer service for UTC(NIST). GPS is not a timescale. It is a navigation positioning (and time transfer) service based on UTC(USNO). I'm not trying to pick a fight here. Just trying to seek clarification. 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. Put it another way -- Brooks, what information could WWVB or GPS (GNSS) further provide to satisfy your clientele? Must you rely on hardcopy historical journal articles, on-air data, or web-based tables to satisfy your timekeeping requirement? 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
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
Brooks Harris bro...@edlmax.com wrote: On 2015-03-07 03:01 PM, Steve Allen wrote: I would say that the intent NTP and POSIX is to correspond to civil time in contemporary use. Therefore, for dates before 1972-01-01 NTP and POSIX are counting seconds of UT. This paragraph in your email had me scratching my head a little. I think none of the civil timescales are counting in UT - they are measured in SI Seconds, even when prolpetic to 1972. Am I missing something here? POSIX time is defined by a mapping from broken-down civil time labels to a scalar value. Currently civil time is UTC; in the past it was some other variant of UT. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southeast Biscay, Southeast Fitzroy: Variable 4. Rough. Fair. Good. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
On 2015-03-09 08:40 AM, Tony Finch wrote: Brooks Harris bro...@edlmax.com wrote: On 2015-03-07 03:01 PM, Steve Allen wrote: I would say that the intent NTP and POSIX is to correspond to civil time in contemporary use. Therefore, for dates before 1972-01-01 NTP and POSIX are counting seconds of UT. This paragraph in your email had me scratching my head a little. I think none of the civil timescales are counting in UT - they are measured in SI Seconds, even when prolpetic to 1972. Am I missing something here? POSIX time is defined by a mapping from broken-down civil time labels to a scalar value. Currently civil time is UTC; in the past it was some other variant of UT. Hi Tony, So UT here is referring generally to the many variants of historical UT, including today's UTC. I see. Thanks. -Brooks Tony. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
leap59 and leap61 are Leap Second announce signals, set 12 hours prior to the insert. There has been discussion about when the official announcements and expiration should be announced. ITU Rec 460 says ...at least eight weeks in advance. PTP can't do that, a point to keep in mind. You've got to be kidding. Who on earth decided on only 12 hours notice? And 8 weeks is wrong too, for a different reason. You can have 8 weeks of notice (or 6 months or 100 weeks) as long as you are given the actual future date of the leap second, as is done with GPS. You can get away with single warning bits too, as long as they apply to current month only, as is done with WWVB. Both of these are models on how to send out leap second notifications correctly. But allowing 8 weeks without a way to know which month it will occur in is wrong. For bit-only leap second warnings 4 weeks is the limit. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
On 2015-03-09 02:10 PM, Tom Van Baak wrote: leap59 and leap61 are Leap Second announce signals, set 12 hours prior to the insert. There has been discussion about when the official announcements and expiration should be announced. ITU Rec 460 says ...at least eight weeks in advance. PTP can't do that, a point to keep in mind. Hi Tom, You've got to be kidding. Who on earth decided on only 12 hours notice? IEEE 1588, I guess. Remember, 1588/PTP is intended primarily for synchronization via TAI-like PTP Time over LAN networks. It requires special switches supporting the various Profiles to have it work correctly with high resolution. It can carry UTC metadata but it looks all the world to me to have been a secondary consideration in the design. You've seen some of my comments about how I think it's definition of its epoch is flawed or misleading. And 8 weeks is wrong too, for a different reason. That's in the primary document ITU-R Rec 460 we generally base part of our UTC specification knowledge on, and the very document at the heart of the kill Leap Seconds discussion. It says - The IERS should decide upon and announce the introduction of a leap-second, such an announcement to be made at least eight weeks in advance.. This they generally do as far as I know, as Bulletin C. I've never been able to locate any official IERS policy that defines any schedule or rules about when they will in fact issue Bulletin C. You can have 8 weeks of notice (or 6 months or 100 weeks) as long as you are given the actual future date of the leap second, as is done with GPS. You can get away with single warning bits too, as long as they apply to current month only, as is done with WWVB. Both of these are models on how to send out leap second notifications correctly. Ah, well, correctly I guess - they can work, but their promised schedule is not the *same*. But allowing 8 weeks without a way to know which month it will occur in is wrong. For bit-only leap second warnings 4 weeks is the limit. 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. I've never been able to understand why that practice persists despite the obvious need to be able to fully represent the entire post-1972 UTC timescale. The policy and forms of the announce signals and Leap Seconds table are obvious missing links, and its regrettable no official attempt has been made since 1972 to rectify those inadequacies. I think ITU-R will have no choice but to stay with current policies because UTC with Leap Seconds is now too deeply embedded in timekeeping legacy and can't realistically be excised. Their decision would be easier if some credible proposal(s) had emerged, and its too bad the kill Leap Seconds argument has diverted all attention and resources from any effort to fix the situation. But I'd bet its still going to be necessary. -Brooks /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
On Mar 7, 2015, at 4:50 PM, Joseph Gwinn joegw...@comcast.net wrote: On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote: Hi Gerard, On 2015-03-07 12:04 PM, G Ashton wrote: Brooks Harris wrote on Saturday, March 7, 2015 11:50 : . . The challenge I'm trying to solve is to provide a deterministic timekeeping and labeling scheme for date and time *after* 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI). This is essentially the purpose of civil time timekeeping as is typically intendedThe timescale before 1972 is an abstract proleptic Gregorian calendar scale for purposes of calculation convenience. On this scale, like NTP, PTP, and POSIX, any date-time before 1972-01-01T00:00:00Z (UTC) is considered either inaccurate or invalid. Civil timekeeping is concerned with many things, including determining when one date ends and another begins. Thus civil timekeeping is inextricably linked to civil calendars. Although the time of day of past events become less and less important as the decades pass, the date of those events remain important. Since some computer applications routinely attempt, in their clumsy way, to account for timezones, timekeeping is potentially important for the computer representation of timestamps, even when the humans using the computer are only interested in the date. Of course, dates long before 1972 are of interest in civil matters; dates of birth immediately come to mind. I agree. So when Brooks Harris presents his API to his stakeholders, I think a more thorough explanation of why date-time expressions before 1972 will be considered either inaccurate or invalid will be needed. It is typically warned that date and time before 1972 cannot be accurately represented with NTP or POSIX, for examples. These timescale's origins precede 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI) and seek to represent date-time counting *forward*. They give no consideration to date-time accuracy before 1972, but operate on proleptic scales convenient for computation. This is generally true with widely available timekeeping services on OSs, systems, languages, and many typical applications because so many of them implement mechanisms based on the heritage of the POSIX timekeeping mechanisms, complete with its flaws with respect to representing UTC and Leap Seconds. In the discussions I've been involved with many people argued strenuously we don't care about the past, only accurate date-time going forward!. The reason I'm choosing to ignore the subject of accurate date-times before 1972 is not that its not important, but probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS - its just too expansive a topic to tackle in some commonly accepted way. For date-time before 1972 you've got to switch to some other timescale depending on the purpose at hand. I figured it out the difference between GMD and UTC for POSIX. There was an 81 microsecond error, At the time, most UNIX boxes kept time to the nearest second, synchronized to a hairy wrist. There were advanced systems that could do milliseconds, and in the 1980s a few that had microsecond resolution, but we chained them to GPS via NTP, so the error was multiple milliseconds, depending on everything. Keep in mind that time-stamps come from things other than computers. So while this is an interesting footnote, it doesn’t describe the set of all timestamps. For a general purpose API, it has to encompass more than what a computer was capable of in the 70’s. 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] Civil timekeeping before 1 January 1972
On Sun, 08 Mar 2015 12:24:42 -0400, Brooks Harris wrote: On 2015-03-07 06:50 PM, Joseph Gwinn wrote: On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote: In the discussions I've been involved with many people argued strenuously we don't care about the past, only accurate date-time going forward!. The reason I'm choosing to ignore the subject of accurate date-times before 1972 is not that its not important, but probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS - its just too expansive a topic to tackle in some commonly accepted way. For date-time before 1972 you've got to switch to some other timescale depending on the purpose at hand. I figured it out the difference between GMD and UTC for POSIX. There was an 81 microsecond error, At the time, most UNIX boxes kept time to the nearest second, synchronized to a hairy wrist. There were advanced systems that could do milliseconds, and in the 1980s a few that had microsecond resolution, but we chained them to GPS via NTP, so the error was multiple milliseconds, depending on everything. Hi Joe, I see the difficulties with UTC implementations and the questions at ITU-R stemming from the historical and legacy misalignment of the timekeeping mechanisms of the c language and POSIX and the UTC specifications. Perhaps that's obvious. I'm not criticizing anybody anywhere for this, its just the way its come about. I think the only way the industry can eventually converge on reliable civil time representation is to refine the underlying time mechanisms in POSIX in some manner that allows a migration to a more comprehensive UTC implementation. I think if a new new POSIX time specification were to take shape it would add an option to the the conversation at ITU-R - instead of simply to kill Leap Seconds or not they'd also have a viable migration path to comprehensive UTC timekeeping implementation to consider. We understand the folks at POSIX have grappled with this topic in the past and run into all sorts of difficulty. Given the current state of affairs, do you think there's any way IEEE and POSIX could reengage this topic? The biggest problem was that the time folk couldn't stop arguing, and come to a solution that met all of POSIX's technical requirements. Nor should the arguments be held in the POSIX committee, most of which were totally unable to follow the arguments. The committee finally threw the time folk out into the snow and settled for minimal changes. I did get the statement that each day has exactly 86,400 seconds written into the standard, and that although it resembled UTC is was not in fact UTC, to cut off the common misinterpretation that POSIX time was UTC. I published the email threads some time ago. Anyway, if the time folk could come to agreement and present one proposal, there is a chance. Also listed in the email threads were the requirements, and one of the requirements is that POSIX time had to work in a reasonable way even in totally isolated systems, which have no way to know about leap seconds. Joe Gwinn ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
On Mar 8, 2015, at 10:24 AM, Brooks Harris bro...@edlmax.com wrote: I think the only way the industry can eventually converge on reliable civil time representation is to refine the underlying time mechanisms in POSIX in some manner that allows a migration to a more comprehensive UTC implementation. I think if a new new POSIX time specification were to take shape it would add an option to the the conversation at ITU-R - instead of simply to kill Leap Seconds or not they'd also have a viable migration path to comprehensive UTC timekeeping implementation to consider. I think you vastly underestimate the amount of effort this change would entail. We’d trade an off by 1 second every other year problem for an off by 36s problem in many different places. Even if we left time_t as a legacy thing, and defined a whole new set of interfaces that did things pedantically correct, that’s a lot of effort to code and adopt. And there’s almost no economic incentive to drive the change. You’d need to change the “It’s just a second, who cares?” attitude before meaningful progress can be made in getting leap seconds right. 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] Civil timekeeping before 1 January 1972
On 2015-03-08 05:00 PM, Warner Losh wrote: On Mar 8, 2015, at 10:24 AM, Brooks Harris bro...@edlmax.com wrote: I think the only way the industry can eventually converge on reliable civil time representation is to refine the underlying time mechanisms in POSIX in some manner that allows a migration to a more comprehensive UTC implementation. I think if a new new POSIX time specification were to take shape it would add an option to the the conversation at ITU-R - instead of simply to kill Leap Seconds or not they'd also have a viable migration path to comprehensive UTC timekeeping implementation to consider. I think you vastly underestimate the amount of effort this change would entail. Hi Warner, Its a world-wide societal problem. I think it would take at least a decade for a good specification to find its way into all main stream systems and applications, and that's after it was agreed upon. I'd say it can't be done, which I don't think that is underestimating it. But never say never. We'd trade an off by 1 second every other year problem for an off by 36s problem in many different places. Even if we left time_t as a legacy thing, I think you have to to provide reverse compatibility for an extended transition period. I mean an *extended* transition period, like, until all vestiges of the legacy implementations go offline. Even then, there will be boat loads of archival timestamps created by the legacy systems. and defined a whole new set of interfaces that did things pedantically correct, I think that's what's required. that's a lot of effort to code and adopt. Oh, lots and lots and lots :-) And there's almost no economic incentive to drive the change. I'm not sure that's true. The dangers of incorrect time stamps are recognised in many quarters, not the least in financial and high-speed trading. The possible catastrophic system failures are exactly where the whole kill Leap Seconds thing comes from, where Google and others have spent boat loads of energy and money to paper over the risk with Google Smear. It seems to me like any and all players in the computer industry would significantly benefit from real precision timekeeping. All industries, jurisdictions, and citizens everywhere would benefit too. Tons of money was spent on the Y2K problem. The Leap Second problem is more subtle, but similar, and ubiquitous. There is not yet any panicked demand for it, but there is building recognition of the issue. The resources might still be mustered, especially behind a coherent and credible design and plan. You'd need to change the It's just a second, who cares? attitude before meaningful progress can be made in getting leap seconds right. There are an awful lot of people that recognize the problem and do care. Will it coalesce into a movement? Only if a good plan emerges from somewhere. Right now everybody just runs for cover... -Brooks Warner ___ 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
Hi Steve, On 2015-03-07 03:01 PM, Steve Allen wrote: On Sat 2015-03-07T14:14:07 -0500, Brooks Harris hath writ: It is typically warned that date and time before 1972 cannot be accurately represented with NTP or POSIX, for examples. I would say that for PTP * all seconds are always SI seconds * seconds after 1972-01-01 correspond to (TAI - 10) * seconds before 1972-01-01 do not align with civil time * in particular, 1970-01-01 in PTP does not correspond to any event in any time scale which was then in use, but that does not matter For PTP it is the uniformity going forward that is the goal. Keep in mind PTP is for .. Networked Measurement and Control Systems, so its first objective is for things like process control, hence its primary timescale is TAI-like. Civil time, or UTC, is a secondary concideration, but it has mechanisms to communicate UTC (currentUtcOffset, leap59, leap61). It does not specify the UTC rules by which these are set, relying on the UTC background specifications for that. leap59 and leap61 are Leap Second announce signals, set 12 hours prior to the insert. There has been discussion about when the official announcements and expiration should be announced. ITU Rec 460 says ...at least eight weeks in advance. PTP can't do that, a point to keep in mind. I would say that the intent NTP and POSIX is to correspond to civil time in contemporary use. Therefore, for dates before 1972-01-01 NTP and POSIX are counting seconds of UT. First let me compliment you on all your excellent work and research at http://www.ucolick.org/~sla/leapsecs/. This is an invaluable resource and I have learned much from it. Thank you. This paragraph in your email had me scratching my head a little. So, first, off to your time pages to learn more carefully about UT. I think I see what you mean generally. My view is the NTP and POSIX are abstract timescales constructed for convenient civil timekeeping calculation, albeit with their Leap Second flaws. I think I would suggest your statement would be better as .. for dates before 1972-01-01 NTP and POSIX are counting seconds on a proleptic scale that extrapolates the SI Second prior to 1972-01-01.. This seems clear epecially in NTP, where RFC 5905 states It should be noted that strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity, even if all knowledge of historic leap seconds has been lost. It seems to me NTP and POSIX as well as other timescales concerned with civil time, are essentially disconnected from reality, expressing idealized measurement scales. UTC is an idealized scale expressing an approximation of reality derived from UT1, and UT1 will probably always undergo some refinement and the sciences advance. I think none of the civil timescales are counting in UT - they are measured in SI Seconds, even when prolpetic to 1972. Am I missing something here? For dates after 1972-01-01 I would say that NTP and POSIX are both confused You bet about whether they are counting SI seconds or UT days. Can you be more specific about what you mean by this? I think I understand your general meaning, that the confusion, or the mis-match between the NTP and POSIX and UTC, lies with their methods of accounting for LOD. By UT days do you mean 86400 seconds per day? Therein, of course, lies the basis of this LEAPSECS list. Sure. Well, at least, therein lies *one reason* for this LEAPSECS list. :-) I see it as inevitable that the confusion must end, therefore NTP and POSIX will eventually be unambiguous that they are counting SI seconds. That means that, eventually, any general purpose time scale intended to correspond to civil time will be a piecewise continuous time scale. Such general purpose time scales will have a date at which they switch from counting UT days to counting SI seconds. Deciding on that date, and how it will be implemented and understood, is what we hope the ITU-R will accomplish at WRC-15. Can you elaborate on this point as you've stated it? What exactly do you mean switch from counting UT days to counting SI seconds? This doesn't sound quite like what I understand the question(s) at WRC-15 to be. For date-time before 1972 you've got to switch to some other timescale depending on the purpose at hand. Exactly so. Before 1972 civil time was not SI seconds. I understand the proper SI second sprung into existence as of 1972. But it seems to me civil time as kept by NTP and POSIX before 1972 is measured in proleptically exrapolated SI seconds. Of course this scale does not correspond with actual historical date and time or UT1. What am I missing? Thanks, -Brooks -- Steve Allens...@ucolick.org 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
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
On 2015-03-07 06:50 PM, Joseph Gwinn wrote: On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote: In the discussions I've been involved with many people argued strenuously we don't care about the past, only accurate date-time going forward!. The reason I'm choosing to ignore the subject of accurate date-times before 1972 is not that its not important, but probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS - its just too expansive a topic to tackle in some commonly accepted way. For date-time before 1972 you've got to switch to some other timescale depending on the purpose at hand. I figured it out the difference between GMD and UTC for POSIX. There was an 81 microsecond error, At the time, most UNIX boxes kept time to the nearest second, synchronized to a hairy wrist. There were advanced systems that could do milliseconds, and in the 1980s a few that had microsecond resolution, but we chained them to GPS via NTP, so the error was multiple milliseconds, depending on everything. Hi Joe, I see the difficulties with UTC implementations and the questions at ITU-R stemming from the historical and legacy misalignment of the timekeeping mechanisms of the c language and POSIX and the UTC specifications. Perhaps that's obvious. I'm not criticizing anybody anywhere for this, its just the way its come about. I think the only way the industry can eventually converge on reliable civil time representation is to refine the underlying time mechanisms in POSIX in some manner that allows a migration to a more comprehensive UTC implementation. I think if a new new POSIX time specification were to take shape it would add an option to the the conversation at ITU-R - instead of simply to kill Leap Seconds or not they'd also have a viable migration path to comprehensive UTC timekeeping implementation to consider. We understand the folks at POSIX have grappled with this topic in the past and run into all sorts of difficulty. Given the current state of affairs, do you think there's any way IEEE and POSIX could reengage this topic? -Brooks Joe Gwinn ___ 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
Brooks Harris wrote: It seems to me NTP and POSIX as well as other timescales concerned with civil time, are essentially disconnected from reality, expressing idealized measurement scales. That's very much what they're not. TT is idealised, and TAI less so. I think none of the civil timescales are counting in UT - they are measured in SI Seconds, even when prolpetic to 1972. NTP doesn't deal with pre-1972 time at all. (No, the nominal epoch doesn't count.) POSIX time_t notionally can represent pre-1972 times, but in practice no Unix system of that era was synchronised to UTC. Any use of time_t for precise pre-1972 time is heavily retrospective, and the interpretation is more governed by the application than by the POSIX standard. Wild pre-1972 Unix time_t values heavily predate the POSIX standard, and their interpretation has little to do with UTC. They are understood to be vague UT with usually very poor synchronisation (via the operator's wristwatch). Actual civil time, as used in the real world, was rarely precise pre-1972, certainly not much to do with SI seconds. Historically civil time has, over the long term and with large short-term excursions, been synchronised to the solar day, so effectively to UT. I understand the proper SI second sprung into existence as of 1972. You understand incorrectly. As with the existence of TAI (which I discussed in my previous message), the development of the SI second happened in stages. We can start in 1948, with the definition of Ephemeris Time, which is the first time we got a definition for the second that was not derived from the solar day. The ephemeris second is instead defined in terms of the Earth's orbit around the Sun. ET was adopted by the IAU in 1952. In 1958 the caesium second was defined, the definition being chosen to match the value of the ephemeris second. SI was established in 1960, and at that time adopted the ephemeris second as the SI second. In 1967 SI was revised to adopt the caesium second as the SI second, and in 1997 the definition was refined to account for blackbody radiation. So the value of the SI second was established in 1948; the present definition originates in 1958 but its full present form only goes back to 1997; SI (and so the concept of SI second) originated in 1960; and the SI second acquired its present basic definition in 1967. Any of these dates could be taken as the inception of the SI second, but the only one that could really be described as the SI second springing into existence is the establishment of SI in 1960. Nothing relevant happened in 1972. -zefram ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
Hi Gerard, On 2015-03-07 12:04 PM, G Ashton wrote: Brooks Harris wrote on Saturday, March 7, 2015 11:50 : . . The challenge I'm trying to solve is to provide a deterministic timekeeping and labeling scheme for date and time *after* 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI). This is essentially the purpose of civil time timekeeping as is typically intendedThe timescale before 1972 is an abstract proleptic Gregorian calendar scale for purposes of calculation convenience. On this scale, like NTP, PTP, and POSIX, any date-time before 1972-01-01T00:00:00Z (UTC) is considered either inaccurate or invalid. Civil timekeeping is concerned with many things, including determining when one date ends and another begins. Thus civil timekeeping is inextricably linked to civil calendars. Although the time of day of past events become less and less important as the decades pass, the date of those events remain important. Since some computer applications routinely attempt, in their clumsy way, to account for timezones, timekeeping is potentially important for the computer representation of timestamps, even when the humans using the computer are only interested in the date. Of course, dates long before 1972 are of interest in civil matters; dates of birth immediately come to mind. I agree. So when Brooks Harris presents his API to his stakeholders, I think a more thorough explanation of why date-time expressions before 1972 will be considered either inaccurate or invalid will be needed. It is typically warned that date and time before 1972 cannot be accurately represented with NTP or POSIX, for examples. These timescale's origins precede 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI) and seek to represent date-time counting *forward*. They give no consideration to date-time accuracy before 1972, but operate on proleptic scales convenient for computation. This is generally true with widely available timekeeping services on OSs, systems, languages, and many typical applications because so many of them implement mechanisms based on the heritage of the POSIX timekeeping mechanisms, complete with its flaws with respect to representing UTC and Leap Seconds. In the discussions I've been involved with many people argued strenuously we don't care about the past, only accurate date-time going forward!. The reason I'm choosing to ignore the subject of accurate date-times before 1972 is not that its not important, but probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS - its just too expansive a topic to tackle in some commonly accepted way. For date-time before 1972 you've got to switch to some other timescale depending on the purpose at hand. -Brooks Gerard Ashton ___ 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
On Sat 2015-03-07T14:14:07 -0500, Brooks Harris hath writ: It is typically warned that date and time before 1972 cannot be accurately represented with NTP or POSIX, for examples. I would say that for PTP * all seconds are always SI seconds * seconds after 1972-01-01 correspond to (TAI - 10) * seconds before 1972-01-01 do not align with civil time * in particular, 1970-01-01 in PTP does not correspond to any event in any time scale which was then in use, but that does not matter For PTP it is the uniformity going forward that is the goal. I would say that the intent NTP and POSIX is to correspond to civil time in contemporary use. Therefore, for dates before 1972-01-01 NTP and POSIX are counting seconds of UT. For dates after 1972-01-01 I would say that NTP and POSIX are both confused about whether they are counting SI seconds or UT days. Therein, of course, lies the basis of this LEAPSECS list. I see it as inevitable that the confusion must end, therefore NTP and POSIX will eventually be unambiguous that they are counting SI seconds. That means that, eventually, any general purpose time scale intended to correspond to civil time will be a piecewise continuous time scale. Such general purpose time scales will have a date at which they switch from counting UT days to counting SI seconds. Deciding on that date, and how it will be implemented and understood, is what we hope the ITU-R will accomplish at WRC-15. For date-time before 1972 you've got to switch to some other timescale depending on the purpose at hand. Exactly so. Before 1972 civil time was not SI seconds. -- 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
