Re: Mechanism to provide tai-utc.dat locally
On Fri, 29 Dec 2006, Rob Seaman wrote: Folks keep fretting here about retrieving lists of leap seconds autonomously, although no specific use case is proffered about why one needs to use UTC to measure intervals across various and sundry leap second events. You need to do so in order to implement an accurate clock, since the clock produces interval time and you need a way to convert its output to time of day. M. Warner Losh wrote: Daylight savings time and time zones prove that society at large has a very high tolerance for variations between the mean solar time at an arbitrary location, maybe hundreds of miles away, and the local time. This is a static offset. No, it is subject to arbitrary political variations. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SHANNON: SOUTHERLY BECOMING CYCLONIC GALE 8 TO STORM 10, OCCASIONALLY VIOLENT STORM 11. HIGH. RAIN OR SQUALLY SHOWERS. MODERATE, OCCASIONALLY POOR.
Re: Mechanism to provide tai-utc.dat locally
On Fri 2006-12-29T07:43:56 +, Tony Finch hath writ: Astronomers still count Julian years (365.25 days instead of exact years) when dealing with long MJD intervals. Such intervals are almost always expressed in the IAU's time scale of Terrestrial Time (TT) which is taken to be a more uniform measure than any practically available time scale, including TAI. As such it is a simplification for the sake of human cognition that comes close to the notion of year without any intent to match observable or political reality. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: Mechanism to provide tai-utc.dat locally
On Thu 2006-12-28T18:31:43 -0700, M. Warner Losh hath writ: Let's turn the question around. What would the harm be if |DUT1| were 1.1s? 1.5s? 2.0s? Contrast this with the harm and difficulty that the current 6 month scheduling window affords. I have previously indicated that I believe this proposal is workable even with a full decade of lookahead. http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg01351.html I don't think there is much harm. From a technological standpoint I think we can handle it if we are given a decade of advance warning. Because the current form could not accommodate the new magnitude it would demand discontinuation of DUT1 signals in the broadcasts of time, but this is not harm. I believe that there is not one person objecting that the broadcasts of DUT1 are being used by anyone. For our existing telescopes at Lick, no harm. The biggest is literally battleship-era technology -- built by the foundries looking for post-war reasons to keep producing large steel objects, and it steers about as well as a battleship. I do not believe we have any software that would fail with larger values of DUT1. For celestial navigation, no harm other than to require use of one more correction in the almanacs. The projected values of UT1 as published in annual almanacs would almost certainly be as accurate as the DUT1 broadcasts have been. As seen in vol 2 of MNRAS, the Admiralty forced worse changes of procedure on sailors 174 years ago. For the newest telescope now being built at Lick there might be harm, but we can't tell. It's pointing will rely on ingesting the file ftp://maia.usno.navy.mil/ser7/mark3.out using software for which we will not have the source code. This could be an issue for us and for any other agency using that file because nobody can guarantee the formatting rules of the file provided by USNO. If it is being produced by Fortran then it will fill its field widths as soon as UT1 - UTC reaches -10 seconds. This would be a problem for interpreting software which was relying on space separation rather than fixed-width fields. We intend to request that the vendor rely on obtaining the data from a file whose format is formally specified instead of hoping that the USNO can and will continue providing that old format which is not an official IERS data product (it predates the IERS). But I would be uncomfortable with this proposal unless I were to see more definitive changes in the responsibility for UTC. The final words in the summary of the 2003 Torino colloquium were Responsibility for disseminating UT1 information should remain solely with IERS. The time scale(s) in use by most of the world should not be held by an organization which cannot openly publish the characteristics. I think that the ITU should not only get out of the business of distributing UT1, but out of the time scale business altogether. I think that the ITU-R document should restrict itself to naming a time scale whose characteristics are entirely under the control of another agency -- an agency which can openly publish the specifications. Right now the ITU-R document reads UTC is the time scale maintained by the BIPM, with assistance from the IERS which makes for a very fuzzy division of responsibility. I think all responsibility for UTC should be delivered to IERS. I would change ITU-R TF.460 such that it had no annexes at all and basically ended with the words UTC is the time scale maintained by the IERS in conjunction with the BIPM. And with that in place I don't really care whether the ITU-R decides that it is better to broadcast UTC or (TAI - n). If the ITU-R later deems that the external agencies maintaining those time scales are not following rules suitable for broadcasts then they can change the document to name yet another time scale. In one sense this would put a great deal of responsibility onto the IERS, but for practical purposes that is already the case. Maybe it's not workable for the IERS to have full responsibility; it's purely scientific and there's no direct democratic structure. The BIPM is constrained by the resolutions of the CGPM and its international structure. But really, when it comes down to it, people are probably in general agreement that it shouldn't be necessary to rely on either scientists or international diplomacy to tell them when the sun is up. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: Mechanism to provide tai-utc.dat locally
Tony Finch wrote: You need to do so in order to implement an accurate clock, since the clock produces interval time and you need a way to convert its output to time of day. As Steve Allen has pointed out, it is in the nature of a clock to be reset on occasion. What is NTP but a mechanism for managing these resets? What is any clock discipline? What else does it mean to maintain traceability? What is a change in rate, but a reset schedule carried to a limit? (Although Steve might replace reset with maintain a list of offsets.) I don't disagree that maintaining updated access to a master list of resets (leaps) or rate changes provides one avenue to implementing an accurate clock, i.e., synchronizing one clock to another. But even today this often is, can be, will be, managed by resetting one clock as needed, manually if necessary. And even with a detailed long range list of leaps in hand, there is still a responsibility to implement each leap correctly as a 61s or 59s minute. Otherwise this 6 month or 10 year or 600 year lookahead is no better than having Harold Lloyd reset your clocks by hand. One might also point out that the clocks in most PCs are far less even tempered than Madre Tierra. I don't suppose anybody has thought to run the various DUT1 possibilities past the NTP v4 working group? One could do worse than to adopt the NTP clock discipline writ large as a baseline leap second scheduling algorithm. As discussed recently, there is a natural scale to the tempering of DUT1. Working with that, rather than with some arbitrary forget the whole thing strategy, is likelier to converge on consensus. And just to stay on message, let me point out that nothing in the so- called leap hour proposal covers any of these issues. The only way to create a new workable consensus on civil timekeeping is to address the key issues forthrightly. This is a static offset. No, it is subject to arbitrary political variations. Evidently. However, whimsically redefined is not the same as changing in a secular fashion. Rob
Re: Mechanism to provide tai-utc.dat locally
Rob Seaman scripsit: Seems like? Chances are? Pick some other random technical issue - say, automobile airbags, standardized educational testing, the lead content of pigment in children's crayons, and so forth and so on. Would seems like and chances are be phrases you would want to see in a white paper discussing the costs, benefits and risks of these? Diffidently I suggest that if you think cost/benefit analysis has *anything* to do with how international standards are set, you are fairly unfamiliar with the actual process. Those who enjoy law and sausage should not watch them being made. -- I don't know half of you half as well John Cowan as I should like, and I like less than half [EMAIL PROTECTED] of you half as well as you deserve. http://www.ccil.org/~cowan --Bilbo
Re: Mechanism to provide tai-utc.dat locally
On 2006-12-09, Clive D.W. Feather challenged, and I couldn't resist:
For something more challenging, try the 8 Bank Holidays in England:
...
(8) Second weekday after 24th December.
second weekday after 24th December in Gregorian year( Y )
= Gregorian calendar( Y, December, 26 )
+ 2·(floor( D / 5 )) d - (floor( D / 7 )) d
where
D = day of the week number of Gregorian calendar( Y, December, 25 )
(as in ISO 8601 with values in {1..7} and 1 for Monday)
= 1 + ((floor(Y/100) mod 4)·5 + (Y mod 100)·3 - (Y mod 4)·2) mod 7
Sorry for being off-topic.
Michael Deckers
Re: Mechanism to provide tai-utc.dat locally
Poul-Henning Kamp wrote: I seriously don't belive you do equality comparisons at the 1msec level in real world software. Please provide examples. You know you're in trouble when PHK and I agree. One would think a (double precision) floating point epsilon test might be what you want. In those cases that demand some sort of archival query, an ISO 8601 string might be appropriate, but one would typically expect queries to be issued on a window about the desired timestamp, or perhaps given a range specification from 10:03:01.933 to 10:03:02.008 (whether a string, integer or floating point - binary or sexagesimal or BCD for that matter). Rob
Re: Mechanism to provide tai-utc.dat locally
On Wed, 27 Dec 2006, John Cowan wrote: If we confine ourselves to the Gregorian calendar, a time interval can be safely represented as a triple of months, minutes, and seconds. It seems to me that that would put too much complexity at too low a level but still without enough complexity to deal with the whole problem. How does your proposal deal with local time zone changes, e.g. same time tomorrow, or times based on weeks, e.g. last thursday in the month? I don't see much point in having an intermediate stage between day counts and fully broken down dates. Similarly for times, I favour a split between interval time (which the RTC would produce) and broken-down time of day plus day count (with leap seconds and local time handled in the latter layer). Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FISHER GERMAN BIGHT HUMBER: NORTHWEST BACKING SOUTH 4 OR 5, INCREASING 6 OR 7. SLIGHT OR MODERATE, OCCASIONALLY ROUGH LATER. OCCASIONAL RAIN. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
On Thu, 28 Dec 2006, John Cowan wrote: Distinguo. I am talking about time intervals; you are talking about periodic events. Two different things. Still, your minute/month system does not deal with variable-length days. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SHANNON: SOUTH BECOMING CYCLONIC 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10, PERHAPS VIOLENT STORM 11 LATER. VERY ROUGH OCCASIONALLY HIGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
Tony Finch scripsit: Still, your minute/month system does not deal with variable-length days. I assume you mean 23-hour or 25-hour LCT days? True. It does work against UCT days, though, since they are uniformly 1440 minutes long. -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, The Nine Billion Names of God John Cowan [EMAIL PROTECTED]
Re: Mechanism to provide tai-utc.dat locally
John Cowan wrote: I assume you mean 23-hour or 25-hour LCT days? True. It does work against UCT days, though, since they are uniformly 1440 minutes long. Not should leap hours replace leap seconds.
Re: Mechanism to provide tai-utc.dat locally
I am talking about time intervals; you are talking about periodic events. Two different things. Amen!
Re: Mechanism to provide tai-utc.dat locally
M. Warner Losh wrote: And avoiding the ugly 61 or 59 second minutes to define away the problem... It was the time lords who decreed that rubber minutes were prettier than rubber seconds. We're now to skip right over rubber hours to rubber days? Their aesthetic sense seems strangely malleable. Problems that are merely defined away rarely stay away. Rob
Re: Mechanism to provide tai-utc.dat locally
In message [EMAIL PROTECTED], Rob Seaman writes: M. Warner Losh wrote: And avoiding the ugly 61 or 59 second minutes to define away the problem... It was the time lords who decreed that rubber minutes were prettier than rubber seconds. We're now to skip right over rubber hours to rubber days? Their aesthetic sense seems strangely malleable. It is not an æsthetic issue, it is an issue of practical implementation. In days no more than 100 clocks worldwide were precise enough to care about rubber seconds, they were acceptable. In days where no more than 1000 clocks worldwide were seriously affected by leap seconds, they were acceptable. In these days of heavily computerized infrastructure, we need more than half a years warning about discontinuities in the timescale. We can get that only by increasing the DUT tolerance. As Warner, I and others have repeatedly emphasized: It is not the step size that is the problem, it is the 6 month warning. I don't care if you want to implement leap-milliseconds, as long as you tell me 10 years in advance when they happen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Mechanism to provide tai-utc.dat locally
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : We can get that only by increasing the DUT tolerance. Yes. Letting DUT be bounded by +- 10s rather than +- 0.9s is going to affect a tiny number of users. Having leapseconds only known 6 months in advance affects a lot more users... : As Warner, I and others have repeatedly emphasized: It is not the : step size that is the problem, it is the 6 month warning. : : I don't care if you want to implement leap-milliseconds, as long : as you tell me 10 years in advance when they happen. While my preference would be to never see another leap second, I know that's likely not an option. For many practical reasons, scheduling them out 10 years would help ameliorate the costs of leap seconds and allow for better long term planning. Warner
Re: Mechanism to provide tai-utc.dat locally
Poul-Henning Kamp wrote: It is not an æsthetic issue, it is an issue of practical implementation. Well, it's both. The big question is practical implementation of what? In these days of heavily computerized infrastructure, we need more than half a years warning about discontinuities in the timescale. We've had this discussion before. There are no discontinuities in the timescale. Leap seconds are a question of data representation. I'm not trying to minimize the issues by saying that, rather to point out that we can't solve a problem until we state it correctly. We can get that only by increasing the DUT tolerance. We all understand the trade-offs. Presumably the guys who have suggested degrading the tolerance to the point that it will outlive our grandchildren's grandchildren - and simultaneously removed any requirement for the ITU to distribute DUT corrections - understand the trade-offs, too. I don't care if you want to implement leap-milliseconds, as long as you tell me 10 years in advance when they happen. Again - with no intent to minimize the issues - what supports this assertion? Is there any reason to believe that 10 years advance notice would encourage projects and vendors to do anything other than ignore the requirement entirely? A statement that 10 years, or 600 years, notice is all that is needed to resolve all the problems, smooth over all the complications, is entirely too glib. Rather than starting from a bunker mentality of repeatedly fending off an absurd non-solution, perhaps it would be better to design from clearly stated use cases, responsive requirements, coherent risk analyses, a reasonable deployment schedule, a fair-minded budget. We're not going to successfully define the real world out of existence. Rob Seaman NOAO
Re: Mechanism to provide tai-utc.dat locally
Rob Seaman scripsit: I don't care if you want to implement leap-milliseconds, as long as you tell me 10 years in advance when they happen. Again - with no intent to minimize the issues - what supports this assertion? Is there any reason to believe that 10 years advance notice would encourage projects and vendors to do anything other than ignore the requirement entirely? A statement that 10 years, or 600 years, notice is all that is needed to resolve all the problems, smooth over all the complications, is entirely too glib. You are confusing the question of fixity (which is what notice is about) with granularity. It's true that probably no one would bother to implement the ALHP. However, if computer technologists were handed a list of leap seconds from now until 2015, and told Implement these, it wouldn't matter how many or how few leap seconds there were. But since you astronomers insist on a fixed maximum for |DUT1|, no such table can exist. The proposal is this: look at the trends, take your best shot at working out a leap-year schedule for 10 years in the future, and then live with it. -- Newbies always ask: John Cowan Elements or attributes? http://www.ccil.org/~cowan Which will serve me best? [EMAIL PROTECTED] Those who know roar like lions; Wise hackers smile like tigers. --a tanka, or extended haiku
Re: Mechanism to provide tai-utc.dat locally
In message: [EMAIL PROTECTED] John Cowan [EMAIL PROTECTED] writes: : Rob Seaman scripsit: : : I don't care if you want to implement leap-milliseconds, as long : as you tell me 10 years in advance when they happen. : : Again - with no intent to minimize the issues - what supports this : assertion? Is there any reason to believe that 10 years advance notice : would encourage projects and vendors to do anything other than ignore : the requirement entirely? A statement that 10 years, or 600 years, : notice is all that is needed to resolve all the problems, smooth over : all the complications, is entirely too glib. : : You are confusing the question of fixity (which is what notice is : about) with granularity. It's true that probably no one would bother : to implement the ALHP. However, if computer technologists were handed a : list of leap seconds from now until 2015, and told Implement these, it : wouldn't matter how many or how few leap seconds there were. But since : you astronomers insist on a fixed maximum for |DUT1|, no such table : can exist. : : The proposal is this: look at the trends, take your best shot at : working out a leap-year schedule for 10 years in the future, and then : live with it. Let's turn the question around. What would the harm be if |DUT1| were 1.1s? 1.5s? 2.0s? Contrast this with the harm and difficulty that the current 6 month scheduling window affords. Warner
Re: Mechanism to provide tai-utc.dat locally
M. Warner Losh wrote: Let's turn the question around. What would the harm be if |DUT1| were 1.1s? 1.5s? 2.0s? Contrast this with the harm and difficulty that the current 6 month scheduling window affords. Indeed. Go for it. I look forward to reading your report. Who and what interests are adversely affected in each case? How are these effects mitigated as a function of the limit on DUT1? Also, contrast what benefits accrue. One would think that the responsibility for quantifying the implications of a change to a standard would fall on the parties proposing said change. Rob
Re: Mechanism to provide tai-utc.dat locally
Rob Seaman scripsit: Indeed. Go for it. I look forward to reading your report. Who and what interests are adversely affected in each case? How are these effects mitigated as a function of the limit on DUT1? Also, contrast what benefits accrue. One would think that the responsibility for quantifying the implications of a change to a standard would fall on the parties proposing said change. It can't possibly be. Nobody can know what a change is going to cost except those who are going to have to pay for it (or not pay for it). And even their word cannot necessarily be trusted. In this case there are really two questions: how much it would cost to loosen DUT1 but leave it bounded, and how much it would cost if it were only statistically, not absolutely, bounded. -- Don't be so humble. You're not that great. John Cowan --Golda Meir[EMAIL PROTECTED]
Re: Mechanism to provide tai-utc.dat locally
John Cowan wrote: It can't possibly be. Nobody can know what a change is going to cost except those who are going to have to pay for it (or not pay for it). Are you really suggesting that the planning of technical projects is impossible? One might expect some investment of time and money in standard planning activities to be made first, rather than immediately jumping to a narrowly and rather randomly conceived notional position unsupported by even the slimmest of white papers. It is crazily unprofessional to abjure any responsibility for quantifying costs, benefits and risks. And even their word cannot necessarily be trusted. Um. Which edge of the sword are we talking about here? Rob
Re: Mechanism to provide tai-utc.dat locally
In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : Let's turn the question around. What would the harm be if |DUT1| were : 1.1s? 1.5s? 2.0s? Contrast this with the harm and difficulty that : the current 6 month scheduling window affords. : : Indeed. Go for it. I look forward to reading your report. Who and : what interests are adversely affected in each case? How are these : effects mitigated as a function of the limit on DUT1? Also, contrast : what benefits accrue. One would think that the responsibility for : quantifying the implications of a change to a standard would fall on : the parties proposing said change. I know the benefits, but nobody has yet produced a study on why 0.9s was chosen. Some vague rumblings about astronomical software needing to be rewritten, and some vague notions about 'hearty souls' that do celestial navigation with atomic clocks for high accuracy have been offered, but who really would be hurt by this change? Since you are an astronomer, I thought you might be able to give some insight into at least one of these users of time. Daylight savings time and time zones prove that society at large has a very high tolerance for variations between the mean solar time at an arbitrary location, maybe hundreds of miles away, and the local time. Only specialized users of time would be affected. Who are they and how do we find out the cost of change? The world has changed from having maybe a few dozen or tens of dozen atomic clocks when leap seconds started to having GPS with cheap, disciplined oscillators that number in the hundreds of thousands. These little devices have obviated the need, in many cases, for celestial navigation. Given that change, the cost benefit analysis that was done in 1972 likely needs updating. Warner
Re: Mechanism to provide tai-utc.dat locally
M. Warner Losh wrote: vague rumblings about astronomical software needing to be rewritten, Unlike Y2K, there is no solid public proposal for astronomers to cost against, but the cost is likely to dwarf Y2K in our community, since algorithms and deployed services would have to change, not just retrofitting two digit years. Folks keep fretting here about retrieving lists of leap seconds autonomously, although no specific use case is proffered about why one needs to use UTC to measure intervals across various and sundry leap second events. On the other hand, astronomers have quite reasonably coded their systems to take advantage of the original (and current) definition of UTC: GMT may be regarded as the general equivalent of UT. One second of time is 15 seconds of arc on the celestial equator - this is many times greater than the resolution of any O/IR telescope. The proposal really amounts to trading the need to track leap seconds to convert from time-of-day to intervals, for the need to track the equivalent of leap seconds to convert from interval time to time-of-day. Daylight savings time and time zones prove that society at large has a very high tolerance for variations between the mean solar time at an arbitrary location, maybe hundreds of miles away, and the local time. This is a static offset. Leap seconds are one mechanism to address a secular drift - a rate, that is, not a constant. Local time - daylight, standard, mean, apparent - has been raised as an issue innumerable times - it has been irrelevant every one of them. We're not talking about mucking with local time, we're talking about subverting the mother of all solar time. Only specialized users of time would be affected. Who are they and how do we find out the cost of change? If this is true, you can find out by actually seeking them out, rather than hiding a proposal with worldwide implications away in some squirrelly little bureaucratic committee. However, the suggestion has been implicitly made that everybody is a potential victim of leap seconds - that airplanes will drop from the sky, even though they haven't done so through 23 prior opportunities. That suggestion opens the possibility that generalized users, i.e., people might be affected by civil timekeeping issues in subtle ways. The way to find out the cost of change is to spend some time and money characterizing this. For example, I set my workstation's clock forward eleven years (to match Gregorian calendars) for a couple of years prior to Y2K to provide a platform for our Y2K remediation activities. We set clocks forward at the telescopes and some of them started to track the sky backwards. Surely a Y2K-like inventory could be performed for certain key industries to get a sense for what dependencies might lurk? We've long since established that different countries have different legal civil time standards, e.g., GMT versus UTC. What happens should this discrepancy continue as UTC diverges from GMT? The proposal on the supersecret ITU-R table is to discard an international standard that has been in effect for more than a century and that pervades every aspect of our technical, cultural, legal, economic, etc., world. One might expect somebody might have thought to submit a proposal for a few hundred thousand dollars to conduct a proper pilot study before even beginning to speculate about discarding mean solar time as a basis for civil timekeeping. These little devices have obviated the need, in many cases, for celestial navigation. In many cases? That will be comforting to the folks that really need a backup when their GPS goes out. Whatever the solution should be, the one thing it should not be is brittle. Given that change, the cost benefit analysis that was done in 1972 likely needs updating. It sounds like we agree on this point. Seems like a logical leap for leap seconds to follow, if the costs aren't prohibitive. Chances are that one person knows all the users of time that still need DUT1 to be less than 1s. Seems like? Chances are? Pick some other random technical issue - say, automobile airbags, standardized educational testing, the lead content of pigment in children's crayons, and so forth and so on. Would seems like and chances are be phrases you would want to see in a white paper discussing the costs, benefits and risks of these? Oh yeah - that's right. After seven years there is not one single white paper discussing issues related to the decision-making of the ITU-R WP-7A. (And if there were, we presumably would not be able to read it.) There are several thousand professional astronomers in the world and many times this number of amateurs. All of them ultimately care about the subtle concepts underlying the notion of DUT1. It seems bizarre to dismiss their concerns precisely because they might have a more personal interest than some others. It may be naively convenient to assume that the only risks are with poorly
Re: Mechanism to provide tai-utc.dat locally
On Thu 2006-12-28T22:07:08 -0700, M. Warner Losh hath writ: I know the benefits, but nobody has yet produced a study on why 0.9s was chosen. That's pretty easy. In 1969 the CCIR subcommittee was preparing its unilateral decision to switch from rubber seconds and 200 ms steps to leap seconds. They were disregarding the other international scientific organizations who had called for a multi-lateral meeting on how to deal with time and frequency broadcasts. When the CCIR plenipotentiary voted in early 1970 their resolution said the limit was 0.7 seconds. When the IAU met in the middle of that year they had no correspondence from the CCIR, so they could take no action and provide no response to give input before the 1972 deadline. The limit of 0.7 was somebody's idea of how well the astronomers could do on a six month schedule given the observing techniques and telecomm and computational means available in 1970. Unfortunately at that time the earth rotation was almost as slow as it has ever been, so it seemed likely that there would have to be a lot of leap seconds, and whoever was in charge tended to jump the gun on inserting them such that the DUT1 value was often very close to the 0.7 s limit. In 1973 the IAU did have standing to respond to the CCIR and recommended 0.9 s, which the CCIR then implemented despite the fact that the WWV coding for DUT1 could not go past 0.7 s. So the indications are that 0.7, and then 0.9 was as close as anyone believed was possible in the early 1970s on a semi-annual schedule. It was a compromise then, and a few people were very, very upset about the situation, but so far as I know no ships ran aground as a result. The subject of leap seconds causing planes to crash was raised then, too, and that didn't happen either. This story may not be exactly right, but the existing public documents make it seem pretty close to the truth. Who exactly the principals were in these cases is still obscure; some of them have died, and others have not. Maybe the future will have access to existing memoirs of some of the dead folks, and maybe some of those living can be exhorted to leave their views behind. So we don't really need a study of the history of why 0.9 because the record of what happened and who did what when is pretty good and that's all kindof moot for solving the dissatisfaction now. The point of keeping DUT1 small was mainly for consistency with existing navigation practices, and also for ease of broadcasting that difference. I don't think that either of these constraints is relevant anymore. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: Mechanism to provide tai-utc.dat locally
On Thu, 28 Dec 2006, M. Warner Losh wrote: We've accepted a statistical solution for the leap-day problem now for about 500 years. The Julian calendar reform was in 46 BC. Astronomers still count Julian years (365.25 days instead of exact years) when dealing with long MJD intervals. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: SOUTHERLY 7 OR GALE 8, OCCASIONALLY SEVERE GALE 9. ROUGH OR VERY ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE, OCCASIONALLY POOR.
Re: Mechanism to provide tai-utc.dat locally
M. Warner Losh said: time_t is so totally broken, it isn't funny. That's the closest thing to a standardized API there is for time. All others are stuff folks have done here or there, but they aren't universal enough to be considered. Too bad the problems with time_t are well known, well discussed and well enumerated. Or rather I should say too bad POSIX doesn't care enough to change it since the cost of changing time_t is huge... Not so. POSIX in the past deferred to WG14 (the ISO C committee) because that's where time_t came from. WG14 is willing in principle to make changes to time_t, up to and including completely replacing it by something else. *BUT* it needs a complete and consistent proposal and, preferably, experience with it. Any proposal has got to deal with a whole load of issues, many of which haven't been properly documented. For example, it should be possible to add and subtract times and intervals (e.g. what time is 14 months and 87 days from now?). -- Clive D.W. Feather | Work: [EMAIL PROTECTED] | Tel:+44 20 8495 6138 Internet Expert | Home: [EMAIL PROTECTED] | Fax:+44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc||
Re: Mechanism to provide tai-utc.dat locally
On Dec 26, 2006, at 23:02, M. Warner Losh wrote: Of course, needing to know TAI-UTC offsets leads one to interesting situations. What does one do if one has TAI time, but not UTC and a conversion is asked for? If it's a time in the future rather than just the current time, the thread may have to block for years... Probably you'd want a quick function that returns a special don't know value, or throws exception, or returns a special result code (as COM). Then the caller can decide what to do. -- Ashley Yakeley
Re: Mechanism to provide tai-utc.dat locally
On Wed, 27 Dec 2006, Zefram wrote: Your principle is probably correct; I'm just saying that the implementation you're thinking of doesn't actually satisfy the criterion. When you quoted me you snipped the bit where I said its implementation is far from ideal. This is not just because of the update problem: the whole library is built around time_t and the traditional time API both of which are hopeless. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ NORTH UTSIRE SOUTH UTSIRE: WEST OR NORTHWEST 3 OR 4, OCCASIONALLY 5. SLIGHT. FAIR. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
In message [EMAIL PROTECTED], Zefram writes: Ashley Yakeley wrote: In the Haskell time library, I represent UTC time by what seemed to me the simplest possible correct type. This is a record containing an integer to represent day number (as MJD), and a fixed-point decimal (picosecond resolution) to represent seconds since midnight. The allowed range for this is 0 to 86400.. That's a pretty good format. That's a pretty bad format. Computers are binary and having pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec and picoseconds in Haskell is both inefficient and stupid. The fractional part should be a binary field, so that the width can be adjusted to whatever precision and wordsize is relevant. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Mechanism to provide tai-utc.dat locally
Clive D.W. Feather writes:
WG14 is willing in principle to make changes to time_t, up to and
including
completely replacing it by something else. *BUT* it needs a
complete and
consistent proposal and, preferably, experience with it.
This is at the heart of my distaste for the so-called leap hour
proposal. There is no coherent proposal, no implementation plan, no
discussion of adverse effects, no budget, no collection of pertinent
use cases, no exploration of requirements - no technical design
discussion at all.
Meanwhile, the astronomical community (like other prudent
communities, presumably) has instituted long range planning efforts
like the U.S. Decadal Surveys. Major (and minor) telescope and
instrumentation projects involve multi-year design commitments with
significant budgets of their own simply to develop coherent and
complete proposals to submit to the funding agencies. The U.S.
national centers have recently been subject to an NSF Senior Review
process that is likely to have a major affect on all our operating
budgets to free up funding for new initiatives. No pain, no gain.
On the other hand, we have a proposal to change the fundamental
underpinnings of world-wide civil timekeeping. A (publicly
unavailable) proposal that can't even be bothered to suggest how DUT1
will be conveyed in a future in which this quantity would assume
vastly greater importance. It's an embarrassment.
Any proposal has got to deal with a whole load of issues, many of
which
haven't been properly documented. For example, it should be
possible to add
and subtract times and intervals (e.g. what time is 14 months and
87 days
from now?).
Poul-Henning Kamp wrote:
... which is exactly the kind of thing you can not do with any
{origin+offset} format, due to leap seconds.
Leap seconds are an effect, not a cause. The intrinsic difficulty is
with mapping interval time to Earth orientation (mean solar time).
Whatever mechanism is used to synchronize civil time to the sun -
including embargoing leap seconds as leap hours - there will always
be this complication.
Consider an ISO 8601 compliant date/time representation, e.g.:
% date -u +%FT%TZ
2006-12-27T16:47:27Z
The first part is the (Gregorian) calendar date - the second clearly
represents a fraction of a day. From my point of view, this is the
beginning and end of the argument establishing an identity between
civil time and mean solar time. Others are willing to permit a slow
secular drift - in the calendar, too, of course, not just in the
clock. Mucking with leap seconds is equivalent to redefining the
concept of a day.
The point is that over a long enough period, a broad enough temporal
horizon, we all agree that civil time must be synchronized to solar
time. The emergence of the absurd leap hour proposal from among
folks who loathe leaps of any sort demonstrates that. They weren't
eager to center their notional position around leap hours - rather,
they felt obligated. In short, there is no escaping the need to
grapple with the fundamental distinction between Earth orientation
and atomic interval counts. Just as, as one enlarges ones spatial
horizon one cannot fail to run into relativistic effects.
Timekeeping is a subtle business. Others on this list surely
understand that better than I.
Rob Seaman
NOAO
Re: Mechanism to provide tai-utc.dat locally
Zefram scripsit: In the general case: to determine or use an interval of N calendar FOOs, it is convenient to represent the time as a linear count of calendar FOOs plus details of the exact position within the current FOO. FOO may be minute, hour, day, week, month, or year. I think there should be record formats for all of these cases (the native UTC format is one of these with FOO = day), with conversion functions between them and also a linear count of seconds. That's overkill. If we confine ourselves to the Gregorian calendar, a time interval can be safely represented as a triple of months, minutes, and seconds. All time units longer than a month contain a fixed and integral number of months, and all time units larger than a minute and smaller than a month contain a fixed and integral number of minutes. (If we don't care about leap seconds, shock horror, we can just use months and seconds.) -- The man that wanders far[EMAIL PROTECTED] from the walking tree http://www.ccil.org/~cowan --first line of a non-existent poem by: John Cowan
Re: Mechanism to provide tai-utc.dat locally
On Dec 27, 2006, at 06:29, Poul-Henning Kamp wrote: That's a pretty bad format. Computers are binary and having pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec and picoseconds in Haskell is both inefficient and stupid. The fractional part should be a binary field, so that the width can be adjusted to whatever precision and wordsize is relevant. It's impossible to accurately represent a millisecond using binary fractions. That would be unacceptable for most sub-second use. A better idea might have been to use Haskell's Rational type for the seconds offset, which is stored as two integers (for numerator and denominator). Instead I used a fixed-point type (internally just an integer from 0 to 86400). It does not separate integer and decimal part. -- Ashley Yakeley
Re: Mechanism to provide tai-utc.dat locally
On Dec 27, 2006, at 14:32, Poul-Henning Kamp wrote: It's impossible to accurately represent a millisecond using binary fractions. That would be unacceptable for most sub-second use. Reality check: with a 32bit fraction, the error would be 69 ps. ...which accumulates in arithmetic and causes equality comparisons to fail. This should hold: 1000 * 1ms == 1s It won't if you use a binary fraction. A better idea might have been to use Haskell's Rational type for the seconds offset, which is stored as two integers (for numerator and denominator). Instead I used a fixed-point type (internally just an integer from 0 to 86400). It does not separate integer and decimal part. Yes, let us make it as expensive as possible to operate on timestamps, so that everybody will have to invent their own faster type. NOT! I'm not seeing the problem here: you can represent an integer in the range 0 to 86400 with a 64-bit type. There's nothing faster than integer arithmetic. -- Ashley Yakeley
Re: Mechanism to provide tai-utc.dat locally
Rob Seaman scripsit: Mucking with leap seconds is equivalent to redefining the concept of a day. Very true. And adopting the Egyptian-Roman calendar redefined the concept of a month. Somehow civilization survived. -- John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan I must confess that I have very little notion of what [s. 4 of the British Trade Marks Act, 1938] is intended to convey, and particularly the sentence of 253 words, as I make them, which constitutes sub-section 1. I doubt if the entire statute book could be successfully searched for a sentence of equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940
Re: Mechanism to provide tai-utc.dat locally
On 27 Dec 2006 at 20:57, John Cowan wrote: Very true. And adopting the Egyptian-Roman calendar redefined the concept of a month. Somehow civilization survived. Keeping months in sync with phases of the moon apparently turned out to be insufficiently important to civilization to require it as a feature of the calendar. I'm doubtful that keeping clocks in approximate sync with the rising and setting of the sun is likely to be judged equally unimportant, however. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/
Re: Mechanism to provide tai-utc.dat locally
M. Warner Losh wrote: Actually, the real answer is domain specific. There are many things that don't really care (when do I need to make the next 20 house payments, off by one second just doesn't matter at all since transcations are batched on a daily basis a few days early). In that case you don't really want a TAI-UTC conversion. You want an estimate of TAI-UT1. Possibly you'd prefer an exact TAI-UTC conversion but want to fall back on the planetary rotation estimate in the event that UTC isn't defined that far yet. The point is that you're asking a different question from the one that elicits I don't know. Writing a library that copes with both types of users can be problematical at best... I think a different library is required. One is about atomic timekeeping, the other is about astronomy. -zefram
Re: Mechanism to provide tai-utc.dat locally
On Mon, 25 Dec 2006, Keith Winstein wrote: Even if a program is able to calculate TAI-UTC for arbitrary points in the past and near future, what should a library do when a program asks to convert between UTC and TAI for some instant further than six months in the future? You should treat this kind of conversion in the same way that you treat local time zone conversions, which are also unpredictable. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ SOLE: SOUTHEASTERLY 5 TO 7, OCCASIONALLY GALE 8, VEERING SOUTHWESTERLY 3 OR 4. MODERATE OR ROUGH. RAIN. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
On Tue 2006-12-26T17:10:34 +, Tony Finch hath writ: You should treat this kind of conversion in the same way that you treat local time zone conversions, which are also unpredictable. This past year was fun in the state of Indiana as daylight time happened for the first time ever in many counties. I hope someone is writing a book about that. This next year will be fun across the US as devices which have no idea what congress did to the daylight time dates start giving incorrect readings from their clocks. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: Mechanism to provide tai-utc.dat locally
Tony Finch wrote: You should treat this kind of conversion in the same way that you treat local time zone conversions, which are also unpredictable. I wish timezone data would come with a guaranteed validity period, so that the library could say I don't know in the right places. Unfortunately timezones are much less predictable than leap seconds. Not only do legislatures change the rules from year to year, sometimes they change their minds with only weeks of notice. See http://catless.ncl.ac.uk/Risks/22.33.html#subj4 for a rather sudden extension of DST in Brazil in 2002. I think to avoid ever giving inaccurate timezone data we'd have to refuse conversions that are any more than a day in the future. Even if some governments were to set timezone rules well in advance with guaranteed validity periods, others wouldn't bother and so the timezone situation would remain generally a mess. It's fundamentally much less controlled than the precision timescales that are defined by international organisations with subject-specific expertise. In addition, the changes that are made to timezones are of much larger magnitude than we must deal with in UTC. Under current practices, future timezones can be approximated by longitude, with an uncertainty of about three hours in each direction. For locations in the Pacific there's the additional uncertainty of which side of the international date line they'll be on. So I'm not convinced that leap second uncertainty and timezone uncertainty should be treated the same way. The nature of the uncertainty is very different. The uncertainty of future UTC can be managed, but for timezones the only sane path is to eschew their use entirely. -zefram
Re: Mechanism to provide tai-utc.dat locally
On Wed, 27 Dec 2006, Zefram wrote: So I'm not convinced that leap second uncertainty and timezone uncertainty should be treated the same way. I was thinking partly from the point of view of infrastructure: if you have a mechanism that can keep the system's timezone database up-to-date, then it is adequate for keeping the leap second table up-to-date. This is an approach to answering Ashley's initial question, and the one taken by Linux's use of the Olson database (though its implementation is far from ideal). The nature of the uncertainty is very different. The uncertainty of future UTC can be managed, but for timezones the only sane path is to eschew their use entirely. That isn't possible for applications like appointment books and job schedulers. As Warner suggests, you need to calculate future times provisionally, and in a way that insulates you from discontinuities. For example, same time tomorrow instead of in 86400 seconds. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FAIR ISLE FAEROES SOUTHEAST ICELAND: SOUTH OR SOUTHWEST 4 OR 5, DECREASING 3 IN FAIR ISLE. MODERATE. FAIR. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
Good discussion. On Mon 2006-12-25T15:42:12 -0500, Keith Winstein hath writ: Even if a program is able to calculate TAI-UTC for arbitrary points in the past and near future, what should a library do when a program asks to convert between UTC and TAI for some instant further than six months in the future? One might start by compiling some use cases. Who is asking and why do they need this information? The one thing we should be able to get out of the disagreements on this list over the years is that different people need timelike quantities for different purposes. There is no one size fits all answer. On Dec 25, 2006, at 3:08 PM, Steve Allen wrote: This is something missing from most systems purporting to have clocks that was there on almost all 19th century ships. The navigator has a chronometer, and the navigator's log has an estimate of the offset and rate of the chronometer. Nevertheless, until the ship next sails into a port near an observatory, there's no way to be sure what time it actually is. When the ship gets to port the navigator can go back and correct the navigational measurements after the fact, and thus establish better coordinates for the islands and reefs. Right, although under good conditions they were also able to conduct lunar observations and observations of Jupiter's satellites from shipboard that could be used to correct the chronometers in transit. Obviously a stationary and stable observatory on land is preferred, but the innumerable interlocking cycles of the solar system provide a unique check on any clock. Rob Seaman NOAO
Re: Mechanism to provide tai-utc.dat locally
In message: [EMAIL PROTECTED] Zefram [EMAIL PROTECTED] writes: : Keith Winstein wrote: : what should a library do when a program asks to : convert between UTC and TAI for some instant further than six months in : the future? : : Refuse, of course. The correct answer is I don't know. You might : know if asked later. Actually, the real answer is domain specific. There are many things that don't really care (when do I need to make the next 20 house payments, off by one second just doesn't matter at all since transcations are batched on a daily basis a few days early). There are other things that do care (when do I fire the lasers at the target). For those things, however, it is rare to be computing time into the future that far. Writing a library that copes with both types of users can be problematical at best... Warner
Re: Mechanism to provide tai-utc.dat locally
In message: [EMAIL PROTECTED] Zefram [EMAIL PROTECTED] writes: : Steve Allen wrote: : and if I continue that practice : I can later give you an estimate of how wrong I was when I told you. : : This is something that's missing from current chronological APIs. : It needs to be formalised. time_t is so totally broken, it isn't funny. That's the closest thing to a standardized API there is for time. All others are stuff folks have done here or there, but they aren't universal enough to be considered. Too bad the problems with time_t are well known, well discussed and well enumerated. Or rather I should say too bad POSIX doesn't care enough to change it since the cost of changing time_t is huge... Also, things in TAI time don't care either. 1 day, 1 year, 100 years don't matter to TAI. Periodic things that happen at a given time of day (UTC) are the only things that do care. Warner
Mechanism to provide tai-utc.dat locally
Hello, I just joined the leap seconds list. I wrote the time package for the Haskell programming language. http://semantic.org/TimeLib/ I include code for making conversions between TAI and UTC, given a leap-second table. I also include code for parsing a tai-utc.dat file into a leap-second table. I do not, however, simply include a leap- second table as any program compiled with one would be out of date after six months. This has led me to consider run-time methods of obtaining leap-second information, and how that might be standardised for use by software authors. For instance, I imagine a software package that established a well-known place in the directory hierarchy to find tai-utc.dat and perhaps other earth data files, and was responsible for keeping them up to date. Other software could then make use of the package without each having to implement their own mechanism. Does this strike people as worthwhile? Does anyone know of an existing effort along these lines? Thanks, -- Ashley Yakeley Seattle WA
Re: Mechanism to provide tai-utc.dat locally
In message: [EMAIL PROTECTED] Ashley Yakeley [EMAIL PROTECTED] writes: : Hello, I just joined the leap seconds list. I wrote the time : package for the Haskell programming language. : http://semantic.org/TimeLib/ : : I include code for making conversions between TAI and UTC, given a : leap-second table. I also include code for parsing a tai-utc.dat file : into a leap-second table. I do not, however, simply include a leap- : second table as any program compiled with one would be out of date : after six months. : : This has led me to consider run-time methods of obtaining leap-second : information, and how that might be standardised for use by software : authors. For instance, I imagine a software package that established : a well-known place in the directory hierarchy to find tai-utc.dat and : perhaps other earth data files, and was responsible for keeping : them up to date. Other software could then make use of the package : without each having to implement their own mechanism. : : Does this strike people as worthwhile? Does anyone know of an : existing effort along these lines? One can find the leap data from NIST that's up to date: ftp://time.nist.org/leap-seconds.list I believe that there are other places for this information as well. The problem is that often times one has systems that aren't guarnateed to be connected to the internet, but are connected to GPS so that this number can be obtained. Other problems arise from systems that are intermittently operational (like in sparing situations) that may be off over many leap seconds... Warner
