Design - a Tufte decision
On Dec 27, 2006, at 12:02 AM, M. Warner Losh wrote: Calculating time intervals for times 6+ months in the future can be the least of one's worries when one tries to code up a library to deal gracefully with these different failure modes. The trivial case where one has perfect knowledge of TAI-UTC and one can keep that knowledge current is very simple in comparison. Dealing with this case is very simple, and is the way most people think about leap seconds. But dealing with the edge cases can be difficult because there are so many, and so many that people forget to test or conceive of until the call from the field comes in with a failure... A lot of these edge cases are really firmly centered in issues of real-time programming. Few versions of Unix are equipped to deal with real-time issues in even a rudimentary fashion. In any event, these cases have very little to do with leap seconds or any other aspects of the representation of time quantities. That said, I've found the current discussion immensely refreshing. If there is to be any common ground found between the different factions on this list (including the lurkers who actually have a vote on ITU matters), it will be located by focusing on the actual technical design process, not some quick fix gimmick. 1) Who are the stakeholders for civil timekeeping? (A discerning eye might note that all this time we have NOT been arguing about TT, etc.) 2) What minimal inventory of timescales will satisfy all stakeholders? 3) What economic, legal, historical, cultural, scientific, etc., requirements are placed on the delivery of said timescale(s)? 4) What technical solution(s) satisfy the requirements? 5) If change is deemed to be warranted, how best should it be accomplished? (Funded, scheduled, designed, implemented, deployed, maintained, supported, etc?) My initial position for #2 is that there must be at least two timescales, representing interval time and time-of-day, but in the extreme one could even imagine a coherent position stating that NO common international civil timescale is needed at all. (Whether one holds this point of view may say more about ones view of civil society than it does about civil timekeeping :–) In the latter case, let UTC continue as it is, complete with leap seconds. Let facilities derived from ITU deliberations start distributing, for example, a refinement of GPS time. And let some new consortium adopt the distribution of UTC, perhaps with many of the improvements folks have suggested. (This would provide a chance to do over - wouldn't that be lovely?) And then let the market decide. In the U.S., one would expect funding proposals for a new-and- improved UTC to result. Those of us who aren't Co-I's would likely be referees... Whatever the solution, implementing it is unlikely to prove a panacea. In the seven years this list has been in existence, we've only scratched the surface of the complexities inherent in civil timekeeping. In short: 6) Where should the lines of elegant design and rational compromise be drawn? Rob Seaman NOAO
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: Design - a Tufte decision
In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : On Dec 27, 2006, at 12:02 AM, M. Warner Losh wrote: : : Calculating time intervals for times 6+ months in the future can be : the least of one's worries when one tries to code up a library to deal : gracefully with these different failure modes. The trivial case where : one has perfect knowledge of TAI-UTC and one can keep that knowledge : current is very simple in comparison. Dealing with this case is very : simple, and is the way most people think about leap seconds. But : dealing with the edge cases can be difficult because there are so : many, and so many that people forget to test or conceive of until the : call from the field comes in with a failure... : : A lot of these edge cases are really firmly centered in issues of : real-time programming. Few versions of Unix are equipped to deal : with real-time issues in even a rudimentary fashion. In any event, : these cases have very little to do with leap seconds or any other : aspects of the representation of time quantities. Actually, they can have a great deal to do with it. The absolute need to deal properly with these edge cases can, at times, lead to design decisions that aren't the 'simplest'. I also disagree that Unix is ill-equipted to deal with real-time issues. While one does need to take care, I have successfully deployed over a dozen different types of timing systems over the past 7 years on FreeBSD. My familiarity with these edge cases, the customers that expect them to work and the different sources of time has been learned through these experiences. The nature of these customers also means that they are less well connected to networks than one would like, which also complicates matters. The salient point from my ramblings is that different time scales may become available at different points in time because data about them is available at different points in time to the application/os. If there's only one time scale, then once you know the time, you are done. If there's more than one, then you need to either discover both times, or you need to discover one time and the transforms to that time to know the others. Warner
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.
