In message <[EMAIL PROTECTED]>, Rob Seaman writes: >> Given that the average western citizen under 30 years already today >> can barely add up three items in the supermarket without resorting to >> their mobile phones built in calculator today, I think you can >> safely assume that you can do anything to the timescale 100 years from >> now. > >Shouldn't we work to educate the public, not use their ignorance of >some issue as justification for degrading service?
Absolutely! but if you read your classics (relevant keywords: bread and circus) you would not expect much success. > >Poul-Henning Kamp also wrote: > >> As a computer nerd I can fully appreciate the problems and cost of >> converting existing systems to cope with larger UT1/UTC difference, >> but that cost would be peanuts compared to the costs of implementing >> leap-seconds reliably in future systems that would need it. I think you got the sign of my position wrong here: The cost of conversion has been used to argue _for_ keeping the leap seconds, and I say that the cost of _keeping_ the leapseconds will be much higher in terms of software development and testing. >I have yet to hear of a system that has >trouble handling leap seconds that wasn't poorly engineered in its >handling of time standards. Why should the rest of us pay for some >project's bad requirements discovery, bad design and bad >implementation? Imagine that the underlying time standards are, >indeed, changed. Why should we have any greater expectation that the >same suspect engineers wouldn't make a mess of using the new standards? The concern I have met from computing system owners is not that they worry _if_ their system will handle leapseconds, but that they don't know _how_ it will handle them. The major problem with leapseconds in computer systems is that they do not happen often enough to be testable, and for anything networked, they are untestable unless we set up dedicated "fake time" NTP servers (like Judah did for y2k), have reliable GPS simulators etc etc. I saw one test plan for a major safety-of-life system were they dropped leap second testing because the sheer enormity of doing so, including fake GPS, DCF77 and NTP timesources where simply not possible, some of them even illegal. Their plan: Hope leap-seconds are killed. Ther fall-back plan: Shut down for an hour citing "emergency computer problems" and take the political flack afterwards. You don't even want to know how much money that would cost in lost throughput if leapseconds didn't happen an hour past midnight here. No such relief for the asians. >Attempting to move the entire worldwide civil time system to a >non-Earth based clock is equivalent to attempting to build a clock >designed to run untended for 600 years - in effect, to attempting to >build a millennium clock. No it isn't. This is a rubbish argument and you know it. No matter how reasonable Brahe, Keppler and Newton had been, no matter how well they had worked out their plan, no matter how much they had tuned it to their society, we would never have executed it today according to their design without checking, double checking and reevaluation of their premises. And neither are our great^N-grandchildren going to. We are not designing a new timescale to last 600 years here, we are designing a timescale for the next century at best, and given the statistics we should consider ourselves luck if it holds even half that long before somebody finds something wrong with it. >If you want engineers to build systems that correctly incorporate >handling of some phenomenon, you don't require that this phenomenon >only be handled every half millennium. It's not the frequency of the phenomena that is the problem, it's the magnitude. Nobody puts an entire IT department on call for a one second event, you just can't justify the expense to top management and more importantly, with half a years notice you can't budget for it. But every IT manager would do so for an one hour event. The really smart ones will plan their three hours of maintenance to coincide with the event. >Leap seconds are a perfectly workable mechanism. For who ? For astronomers ? For computer programmers ? For risk managers ? For insurance companies ? Or do you mean because they're so small that most people just ignore them and since we're in the center/western hemishere we mostly get away it ? Ask the asians what they think of having that second in the middle of the day, then come back and call it "workable" once more. >Let's stop pretending that *both* atomic time and >time-of-day are not needed. Instead, let's direct our efforts toward >implementing improved systems for conveying both of these fundamental >timescales to users of both precision and civil time. And most >definitely, let's stop these inane and embarrassing closed door >discussions among biased insiders. > >It ain't your clock - it's *our* clock. I agree, but we have to be realistic and either you are not or you don't know what you need to be realistic about. The systems which need UT1(-like) time are staffed by very smart people. The systems which need civil time are not. Many of them don't know that other parts of the globe have different time, fewer yet know what the difference is. We need to put the complexity where it can be handled. Today my civil time is already up to one and a half hour wrong according to solar time. Scottland is debating making it up to two and a half hour wrong in order to be in the same zone as most of EU, and some of the new EU member states are discussing making it one or two hours wrong in the other direction for the same reason. On average most of USA must be half an hour off center as well. If the civil timescale drifts one hour over the next half millenium, I can guarantee you that none of my decendents would care that the solar clock they inherited from me is not mounted in the exact same direction as I had it. It's actually even worse than that if you look at what people call "mid-day" in various countries: It's not uncommon for building workers to eat their "mid-day" at 10:30 here in Denmark, kids in the school is have it at 11:30. The numbers we attach to civil time have nothing to do with "noon", "mid-day" and such mundane concepts. Nobody today can look at their wristwatch and set their compass after the sun without doing a considerable amount of correction already. Civil time does not have to be linked hard to the sun as long as it doesn't change too fast. On the other hand, astronomers and others that need UT1 will be able to take the global timescale, (TAI, UTC or something else) and apply a delta they pick up from a scientific entitity and use the result. Today most of them already have to pick up a +/- 1second delta anyway, but they are so used to dealing with bigger numbers, I would trust them to do +/- 10000 seconds and get it right in first try. Many of the people who need civil time still have a hard time with leap years and daylight savings time, and since a lot of these people inexplicably are tasked to implement and code life critical systems, you should not task them with an arrythmical phenomena of negiligble magnitude which they can't test. I have met engineers writing train and air traffic control software who didn't even know that leap-seconds existed. The most scary part is that just some years ago the fad-of-the-year in program development was called "prototyping" (I maintain that they simply relabeled "trial and error" :-), and much of that software were responsible for the Y2K issues that were actually found. How much of that code do you think copes with leap-seconds ? Do you think the IT industry is going to magically become better at handling such minute details when they can't even find a way to stop spam-mail ? And when were the last time you heard about a really big computing system being on budget, on time, working as designed ? Where do you think leap seconds end up in such a project ? For every scientist you can come up with who knows what UT1 is, I can find you ten programmers who will not know what a leap second is, and they are programmers who program the air traffic control systems, the heart-rate monitors, the NMR scanners and the mobile phone you might be at the mercy of during the next leapsecond. I agree that the leap-hours thing is a slightly phony way to abolish leap-seconds, but it sounds to me like leap-hours is just the legal maneuvre we need to enable us to put legislation after the decision instead of in front of it. As a Dane that sounds smart because time in Denmark is still not UTC based but based on "mean solar time" because our parliament has not gotten around to fix it in the last 46 years. So my position is clear: Kill leap seconds. Let the people who need UT1 deal with the complexity. If we need to pretend leap-hours to keep the politicians out of it I'm all game. -- 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.