In message: <[EMAIL PROTECTED]> Rob Seaman <[EMAIL PROTECTED]> writes: : On Jan 3, 2006, at 5:46 PM, Warner Losh wrote: : : > As someone who has fought the battles, I can tell you that a simple : > table is 10x or 100x easier to implement than dealing with parsing : > the data from N streams. Sure, it limits the lifetime of the : > device, but a 20 year limit is very reasonable. : : Simpler is indeed better - if it satisfies the requirements. While : we're at it - how about a table to describe worldwide daylight saving : rules? Oh right - we already have that :-) What we don't have is a : mechanism to force the U.S. Congress not to change the rules out from : under us. Retaining the flexibility to easily change the rules is : one of our requirements.
You are comparing two dissimilar things. A more apt comparison would be to the leap year rules that we have. We know the rules going forward a thousand years or so. These too represent the fact that the oribit arount the earth is not exactly 365.25 days. We add leap seconds because the rotation of the earth isn't exactly 86400s. The difference between them is that the earth's rotation around the sun is more stable than its rotation on its axis. Daylight savings time is something else entirely. It is a political decision that sunlight is better used in the evening than the morning. : Twenty years does seem reasonable. Would suggest this might be : marketed as an extended cadence maintenance requirement, rather than : as an expiration date - suspect astronomers aren't the only ones to : rely on 30 year old computers on occasion. I would heartily agree : with the notion that a twenty year horizon is about appropriate for : expecting to reach any decision on the future of UTC. We'd be a lot : further ahead on this if a closed door decision hadn't been rushed : for the imagined benefit of the few. In the mean time, there are : many members of the astronomical software community who would be : happy to contribute to an effort to improve time handling : infrastructure and standards, rather than spending their own precious : time fending off ill conceived political machinations. Twenty years is an example number. Ideally, as predictive science gets better, we can do it for longer periods of time. One would hope to eventually have a schedule that's published 50 or 100 years in advance. Leap years have been published far in advanced for thousands of years now, with only one correction to the rule about 700 years ago as the measurement of the year was refined. As we've refined it further in the last few hundred years, we know, with a very high degree of confidence, that the rule is good for at least a thousand years. The rule isn't perfect, as almost a full day of error can accumulate in 400 years (requiring an extra leap day), but it does bound the error nicely. If we can extend the horizon from 6 months, then that would lead to better predictibilty of leap seconds, and also allow for better testing. Of course, a rule that eliminates them entirely would also fit these needs, but appears to have little support... : > If we could have a table for the next 20 years, there'd be no need : > to even write the code to get from the GPS stream :-) : : And if latitude and longitude were engraved on every street corner, : there would be no need for GPS at all :-) Transport of time signals : to remote locations is the whole point. I think it would have been better if I'd stated my point more directly: Multiple sources of information about leap seconds leads to a more robust system. GPS can tell us about it, ntpd can tell us about it, and having a table of known leap seconds can inform us. These redundant sources of information act as a sanity check. In the development box that did do the leap second correctly, a backup source of infomration allowed it to perform correctly over the leap second despite its development not being complete. : But should any of us be open to persuasion by a "political tool to : make the proposal go through without commiting anybody to anything : for the next couple of hundred of years"? There are a number of politically expedient quick fixes. Foisting it off on future generations is a time honored political solution :-(. : > I find your dismissive attitude towards software professionals that : > have implemented a complete leap second handling infrastructure, : > with pluggable sources for leap second rather annoying :-( : : Indeed, I'm sure I've exhausted my scant store of good will again. My statement was born of frustration. It was a little uncalled for. I regret sending it as it was a cheap shot. : Would be delighted to hear more about your leap second infrastructure. In brief, we have a leap second table. This table can be populated from a number of different sources, usually via a table we've hard coded into our products. As the products run and discover new leap seconds, these are added to the table and the table is updated. Since we parse a number of different data formats to get leap second information (4 different GPS data types, peeking at the leap indicator on ntpd, and recovering it from time signal such as Loran), the system is expandable to allow any source of leap seconds. We've tried to also deal with the 'cold spares' issues by allowing 'gaps' in the knowledge of leap seconds, with the understanding that such 'gaps' can produce incorrect elapsed times when dealing times that fall within such gaps. I say tried, because we've only been able to do a limited amount of testing of all the possible 'cold spares' scenarios. We have a limited ability to update these cold spares once deployed to the field. Warner