Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes: >In message <[EMAIL PROTECTED]>, Steve Allen writes: >>On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: > >>At the beginning of 1984 and at the beginning of 2003 the branches of >>the IERS responsible for UT1 followed new IAU recommendations and >>changed the rules by which UT1 is calculated. The current version >>of UT1 has a notably different flavor and long-term purpose than >>the version of UT1 which was in place when UTC with leap seconds >>was originally defined by the CCIR. > doesn't v >But that matter, because ITU-R (successor of CCIR) defined Leap(time) >in terms of UT1 without specifying how UT1 was arrived at. oops... -- 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: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message <[EMAIL PROTECTED]>, Steve Allen writes: >On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: >> UTC >> UTC(time) = TAI(time) + Leap(time) >> >> Owned by ITU. >> IERS evaluates Leap(time) according ITU definition > >Not quite. The endorsement for the usage of UTC comes from CGPM, >and that is predicated on the existence of leap seconds. This is irrelevant. The CGPM may endorse which timescale they think should go into legal time, but if they change their mind UTC will still exist until ITU does something about that. A secondary issue is that even if CGPM decided to say "Use FOO instead" nobody would take much notice until ITU and a lot of other people agreed and did their respective paperwork. >But in the original agreement, UTC and TAI were defined solely by the >BIH according to the rules of the CCIR. Both the BIH and the CCIR are >defunct. TAI was transferred from BIH to the BIPM. Determination of >the UTC offset was transferred from BIH to IERS. But IERS is not >a single entity, it is an ensemble of entities. Lets waste a lot of time splitting red tape, why don't we ? >At the beginning of 1984 and at the beginning of 2003 the branches of >the IERS responsible for UT1 followed new IAU recommendations and >changed the rules by which UT1 is calculated. The current version >of UT1 has a notably different flavor and long-term purpose than >the version of UT1 which was in place when UTC with leap seconds >was originally defined by the CCIR. But that matter, because ITU-R (successor of CCIR) defined Leap(time) in terms of UT1 without specifying how UT1 was arrived at. -- 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: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message <[EMAIL PROTECTED]>, William Thompson writes: >Poul-Henning Kamp wrote: > >> Universal Time = confusing term which comes handy when trying to >> manipulate discussions about leap second futures. > >I have to take issue with this one. My point was that when you just say "Universal Time", how will we know if you mean UTC, UT0, UT1 or UT2 ? >It's obvious from the current definition >and terminology used with Coordinated Universal Time that the original intent >was that UTC would be more-or-less synchronous with UT0, UT1, UT2. The current >debate is whether we should move away from that original intent. Correct: we are talking about what the Leap(time) function should do. -- 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: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: > TAI > Owned by BIPM / Metre Convention This is indisputably agreed to be true since the demise of the BIH. I know of no endorsement for the use of TAI outside of metrological circumstances. > UTC > UTC(time) = TAI(time) + Leap(time) > > Owned by ITU. > IERS evaluates Leap(time) according ITU definition Not quite. The endorsement for the usage of UTC comes from CGPM, and that is predicated on the existence of leap seconds. But in the original agreement, UTC and TAI were defined solely by the BIH according to the rules of the CCIR. Both the BIH and the CCIR are defunct. TAI was transferred from BIH to the BIPM. Determination of the UTC offset was transferred from BIH to IERS. But IERS is not a single entity, it is an ensemble of entities. The branch of the IERS responsible for the UTC offset currently asserts that it is still following the UTC rules from the CCIR before there was an IERS. At the beginning of 1984 and at the beginning of 2003 the branches of the IERS responsible for UT1 followed new IAU recommendations and changed the rules by which UT1 is calculated. The current version of UT1 has a notably different flavor and long-term purpose than the version of UT1 which was in place when UTC with leap seconds was originally defined by the CCIR. The whole scheme works now because there is still consensus about the way in which the original agreements are to be interpreted. It remains to be seen whether the gentleman's agreements which hold this whole scheme together will tolerate a non-consensual arrangement. > Now tell me why you think Leap seconds are so important again. In a word, I offer psychology. -- 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: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
Poul-Henning Kamp wrote: Universal Time = confusing term which comes handy when trying to manipulate discussions about leap second futures. I have to take issue with this one. It's obvious from the current definition and terminology used with Coordinated Universal Time that the original intent was that UTC would be more-or-less synchronous with UT0, UT1, UT2. The current debate is whether we should move away from that original intent. -- William Thompson NASA Goddard Space Flight Center Code 612.1 Greenbelt, MD 20771 USA 301-286-2040 [EMAIL PROTECTED]
Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >Perhaps what we need is simply to define our terms. A lot of the >friction on LEAPSECS undoubtedly comes from conflicting meanings. Good point. >Civil Time = the common basis for diverse time usage worldwide No. Civil Time is a legal term, and you have no power to redefine it. Civil Time = Legal Time = what the applicable law says the clock should show. >Solar Time ~ Mean Solar Time ~ Universal Time ~ GMT ~ UTC ~ UT1 = >various approximations to the baseline of Earth orientation No, No, No. Solar Time ~ Mean Solar Time ~ UT1 = various astronomical/geophysical concepts. GMT = Legal time in the UK, defined by parliament. UTC = Standard defined by ITU-T, based on SI seconds. Universal Time = confusing term which comes handy when trying to manipulate discussions about leap second futures. >Standard Time ~ Local Mean Time ~ Local Apparent Time ~ Sidereal >Time ~ Daylight Saving Time, etc = not pertinent to our discussion (Partially) Wrong again. Daylight Saving Time is a component of Legal time and very relevant to our discussion. So lets try again, and let us focus on only the bits we need to look at: TAI TAI(n) = TAI(n - 1) + 1 SI second Owned by BIPM / Metre Convention UTC UTC(time) = TAI(time) + Leap(time) Owned by ITU. IERS evaluates Leap(time) according ITU definition Civil Time(country) Civil Time(time) = UTC(time) + TimeZoneOffset(country, subdivision, time) + SeasonalOffset(country, subdivision, time) Owned by government of country. Some politically backwards countries like Denmark have not after a century managed to get their laws aligned with reality, but that is merely a matter of political unexpediency. At this level we don't need to look at UT1 or any of the other timescales. 99.999% of the Earths population only see those manifested as hidden variables in the Leap(time) function. So what we are discussing here is only the Leap(time) function. You will notice that this function has one argument only: time. As surprising as this may seem, that is actually the way it is. Leap(time) is a function that is defined as evaluating to an integer number of SI seconds as a function of time and it is defined piecemal with a horizon of 6 to 12 months from the present. Once IERS have made up their mind, the function doesn't change again, even if we find out that Earth Orientation was different from what they thought it was. Behind the scenes, IERS uses UT1 to decide how Leap(time) develops because that is how ITU defined the function, but that is a hidden process because nobody can evaluate it definitively apart from IERS. If you look at the functions TimeZoneOffset(country, subdivision, time) and SeasonalOffset(country, subdivision, time) You will find that with a margin of a couple of hours to both sides their values tend to make the statement "sun highest in the sky at 12:00" true. This trend is of course not accidental. You will also appreciate that should the relevant governments feel the desire, they can redefine both functions without consulting anybody but the citizens of the country in question. If in a hypothetical scenario, the citizens of country N notices that because of continental drift, stupid politicians or the way the UTC timescale is defined, the sun doesn't tend to be highest in the sky around noon, they are perfectly free to elect some politicians who with what goes for sufficient warning in that country can redefine the two functions to make it more so. Now tell me why you think Leap seconds are so important again. -- 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.
Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
I said (and continue to assert): civil time (as we know it) IS mean solar time John Cowan demurs: Why do you persist in claiming that "all parties must certainly agree" on something that is precisely the point most in dispute? No communication with you is possible until you accept that there *is* a controversy over this. There is a controversy. It is not over the identification of civil time with solar time. The controversy is over how close a tolerance is required between the two and how frequently they must be resynchronized. ...or else, what have we been talking about all this time? Poul-Henning Kamp also takes exception: Civil time is at best local solar time +/- up to several hours in either direction depending who you are and where you are. The one thing Civil Time is NOT is Local Apparent Solar Time. Perhaps what we need is simply to define our terms. A lot of the friction on LEAPSECS undoubtedly comes from conflicting meanings. Civil Time = the common basis for diverse time usage worldwide Civil Time is not what real clocks read - it is the idealized master clock. Solar Time ~ Mean Solar Time ~ Universal Time ~ GMT ~ UTC ~ UT1 = various approximations to the baseline of Earth orientation For our purposes, we are interested in Mother Earth's bottom line - the long term trend - not in her daily or seasonal or annual wiggles. Standard Time ~ Local Mean Time ~ Local Apparent Time ~ Sidereal Time ~ Daylight Saving Time, etc = not pertinent to our discussion For instance, Daylight Saving Time is a trivial seasonal offset to Standard Time. Standard Time in one time zone is as good as in another time zone. Offsets from Standard Time to Local Mean Time are simple functions of longitude. The equation of time is a straightforward reflection of the shape of the Earth's orbit and of the Earth's inclination to that orbit. These are all irrelevant (if interesting) details. During all this, Civil Time continues to click steadily away in synchronization with our home planet. The question is how steadily - and how far it is permitted to drift before action is taken - and what kind of action is appropriate - and who gets to make these decisions. Rob Seaman National Optical Astronomy Observatory
Re: Longer leap second notice
Clive D.W. Feather scripsit: > John Cowan said: > > Barry gules and argent of seven and six,John Cowan > > on a canton azure fifty molets of the second. [EMAIL PROTECTED] > > --blazoning the U.S. flag http://www.ccil.org/~cowan > > You don't get odd numbers of barry. It's "Gules, six bars argent". I have received comments to this effect, but also to the opposite effect. In any case, the Great Seal of the United States is blazoned in the enabling legislation "[p]aleways of thirteen pieces, argent and gules", which is certainly relevant precedent, since the even-only theory of "barry" is also usually applied to "paly". Infinite are the arguments of mages. -- One Word to write them all, John Cowan <[EMAIL PROTECTED]> One Access to find them, http://www.reutershealth.com One Excel to count them all,http://www.ccil.org/~cowan And thus to Windows bind them.--Mike Champion
Re: Longer leap second notice
John Cowan said: > Barry gules and argent of seven and six,John Cowan > on a canton azure fifty molets of the second. [EMAIL PROTECTED] > --blazoning the U.S. flag http://www.ccil.org/~cowan You don't get odd numbers of barry. It's "Gules, six bars argent". -- 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: Longer leap second notice
Ed Davies scripsit: > The main requirements for local civil time for the bulk of its > users are that: Agreed. > 1. local civil time matches apparent solar time roughly (e.g., the > sun is pretty high in the sky at 12:00 and it's dark at 00:00). I think the last is the important point, or more specifically that the bulk of the population not begin work on one day and end on another (astronomers excepted, of course). This would be a bookkeeping nightmare. -- Barry gules and argent of seven and six,John Cowan on a canton azure fifty molets of the second. [EMAIL PROTECTED] --blazoning the U.S. flag http://www.ccil.org/~cowan
Re: Longer leap second notice
Rob Seaman wrote: Little support - and again, to a certain level of precision (easily better than a second per day), all parties must certainly agree that civil time (as we know it) IS mean solar time. We've got a bunch of time scales here: - apparent solar time. - mean solar time. - local civil time. - international civil time. The main requirements for local civil time for the bulk of its users are that: 1. local civil time matches apparent solar time roughly (e.g., the sun is pretty high in the sky at 12:00 and it's dark at 00:00). 2. the relationship between local civil time and apparent solar time is constant enough in any one place (e.g., if it's sometimes noon at 10:45 local somewhere in eastern China then it should be noon around 10:45 every day there, +/- half an hour or so). 3. the rate of local civil time is constant at least to the precision of most clocks and watches. 4. the relationship between local civil time and international civil time should be predicatable and easy to calculate with (e.g., round numbers of hours or, if somebody insists, minutes). Points 1 and 2 are similar but not quite the same. If, for example, the whole world used GMT then 2 would be true everywhere but 1 would only be true around the prime meridian. Mean solar time isn't really of much interest to anybody, except indirectly. It acts as a more or less constant rate approximation to apparent solar time (requirements 2 and 3). If we lived on a planet with an equation of time which gave much wider swings in the difference between apparent and mean solar time we might have clocks with variable rates - like they had for the stage coaches in Britain before GMT except you'd use the different rates in spring and autumn or whenever, not when you're going east or west. We'd do that if we thought requirements 1 and 2 trumped 3. In summary - it is convenient to have a civil timescale which is both constant rate and a reasonable approximation of apparent solar time. Mean solar time fits that bill if you don't look too closely at the constant rate aspects but saying that it "IS" civil time is probably a bit strong. Ed.
25 o'clock, we'll be together 'til the end of time (was Re: [LEAPSECS] Longer leap second notice)
(Extra credit for those who recognize the quote.) Tom Van Baak wrote: 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. Apt indeed. Leap seconds are scheduled at least six months in advance. That's about one part in 15 million. A thousand year horizon for scheduling leap days is one part in 365,250. So we're already doing 50 times better than Julius Caesar and Gregory XIII. I'm glad someone else came to this conclusion too. But be careful, though, that this line of thought isn't used to justify leap hours over leap seconds. One leap hour predicted for a fixed date of, say, the year 2600 is about one part in 5 million; still 15x better than the Gregorian calendar. One of the more disquieting aspects of the leap hour "proposal" (really a "notional position") is the tolerance for slop in our clocks. If you don't give a rat's ass for enforcing any kind of limit on the amplitude of the excursion that is more precise than "an hour", you can indeed schedule a leap hour for any particular decade or century that you care to name. This is especially true if you don't even bother to discuss *how* the leap hour will be implemented other than by loose analogy with daylight saving time. On the other hand, if an explicit leap hour trigger condition were specified (i.e., "issue a leap hour on the next December 31 after | DUT1| exceeds 31 minutes"), it would be at least as difficult to predictively schedule leap hours as leap seconds. One expects there would be strong pressure to issue the leap hour (singular and unique because I'm convinced one would be more than enough for civilization to bear) - strong pressure, that is, to issue the leap hour at some round dut1 boundary - 30, 40, 50 minutes. (I think some have been thinking, "count up to 60:00 and subtract it off again".) In point of fact, one might expect that the prospect of undergoing a leap hour during a particular lifetime would be so daunting that the leap hour would be delayed as long a possible. (That's the whole driving motivation, after all.) This is directly counter to the evident policy for issuing leap seconds that has historically resulted in each leap second occurring as soon as practical (presumably to allow "slack" the next time). Also, a leap second is not implemented using the same method as daylight saving time. A leap second is not a "fall back" second, but rather a "do it twice" second - precisely to preserve the historical flow of time. This would be a much more critical issue for leap hours. There appears to be an assumption that a leap hour would be implemented as an extra "fall back" hour inserted into the stream of daylight saving. Let's ignore the fact that many localities do not currently observer daylight saving and have no infrastructure for implementing such. Let's also ignore the question of whether anybody at all will observe daylight saving centuries hence. Rather let's focus on how to maintain the historical flow of time across this factor of 3600X higher temporal cliff. The reason daylight saving can ignore this issue is precisely that all localities observe an underlying standard time for which no discontinuity occurs. A contract, for instance, can be specified with respect to standard time and the implications of that contract are coherently understandable to all parties even *during* a "spring forward" or "fall back" jump. But a leap hour is an adjustment of the underlying standard time. Again, let's ignore the very real question of how all localities might be convinced to implement a leap hour simultaneously. Without a stable underlying reference clock, a standard time zone undergoing a "fall back" leap hour would experience a colossal crack in time. I assert that our mutated, gill-breathing, Christmas-hating great- great-...-great-grandchildren would clearly not choose to implement a leap hour as a "fall back" hour. Rather, they would adopt the "do it twice" algorithm currently used for leap seconds. One speculates that the day in question would simply be declared to be 25 hours long. This would preserve the "historical record". (GalaxyQuest anyone?) Note however, how much more prominent a leap hour becomes. Nobody has surely expected it to be something that virtually all of civilization can ignore - like, say - a leap second. But unlike the naive notion of simply "falling back" twice one year, this becomes not just a big deal on the day in question - not just a big deal during the year in question - not just a big deal during the century in question - but would be a unique occurrence in all of recorded human history. It would henceforth be the "25 Hour Day". More than four centuries later, historians still have to keep track of the calendar change. The English speaking world conflated the trouble by delaying implementation for 170 years. How much more confusing should some locales delay - perhaps guided by lo
Re: Longer leap second notice
> > 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. > > Apt indeed. Leap seconds are scheduled at least six months in > advance. That's about one part in 15 million. A thousand year > horizon for scheduling leap days is one part in 365,250. So we're > already doing 50 times better than Julius Caesar and Gregory XIII. I'm glad someone else came to this conclusion too. But be careful, though, that this line of thought isn't used to justify leap hours over leap seconds. One leap hour predicted for a fixed date of, say, the year 2600 is about one part in 5 million; still 15x better than the Gregorian calendar. /tvb
Re: Longer leap second notice
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >Hi Warner, > >> 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. > >Apt indeed. Leap seconds are scheduled at least six months in >advance. That's about one part in 15 million. A thousand year >horizon for scheduling leap days is one part in 365,250. So we're >already doing 50 times better than Julius Caesar and Gregory XIII. This comparison is utter rubbish, and you know it. >Little support - and again, to a certain level of precision (easily >better than a second per day), all parties must certainly agree that >civil time (as we know it) IS mean solar time. Since you keep repeating this "Nixon cannot have won, nobody I know voted for him" falsehood let me express myself in very simple terms: No, I do *NOT* agree that civil time is mean solar time. Got it ? Civil time is at best local solar time +/- up to several hours in either direction depending who you are and where you are. Seveal geographical/political regions have actively chosen to increase the distance between mean solar time and local time during various stretches of time, often in periodic fasion and sometimes with far too little thought before the decision. We keep hearing "use an appropriate timescale" and in the same emails we hear "UTC is a convenient approximation of UT1". Sounds to me like that argument should be backfired: If you need UT1, then use an appropriate timescale: UT1, don't force the majority of UTC users to suffer because you use the wrong timescale. >Can't argue with that - although ultimately a single well tied knot >is stronger than a tangle of slip knots and Grannies. We're not talking about knots here, this is not cryptography, we are talking about byzantine decision scenarios (I have three references, one say leap second, one says no leap second and one says nothing, what should I do ?) -- 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: Longer leap second notice
Rob Seaman scripsit: > Little support - and again, to a certain level of precision (easily > better than a second per day), all parties must certainly agree that > civil time (as we know it) Why do you persist in claiming that "all parties must certainly agree" on something that is precisely the point most in dispute? No communication with you is possible until you accept that there *is* a controversy over this. -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! -- Joyce, Ulysses, "Oxen of the Sun" [EMAIL PROTECTED]
Re: Longer leap second notice
Hi Warner, 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. Apt indeed. Leap seconds are scheduled at least six months in advance. That's about one part in 15 million. A thousand year horizon for scheduling leap days is one part in 365,250. So we're already doing 50 times better than Julius Caesar and Gregory XIII. 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. As the solar day lengthens, of course, it will influence calendrical issues as well. As has been asserted in the past, changing UTC to eliminate leap seconds also changes the definition of the "day". Daylight savings time is something else entirely. It is a political decision that sunlight is better used in the evening than the morning. These effects are all connected in the generation of a civil date and time at any given moment in any given location on (or "near") the Earth's surface. 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. Look at Steve Allen's plots (http://www.ucolick.org/~sla/leapsecs/ dutc.html). The scatter is implicit in the geophysics. The real world is inconvenient for some purposes, but that's what makes science fun. 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... Little support - and again, to a certain level of precision (easily better than a second per day), all parties must certainly agree that civil time (as we know it) IS mean solar time. I think we're all willing to entertain off-the-wall suggestions - but that's what they are - entertainment. That said, the geophysicists have done a remarkable job improving their predictions - look at a plot of the residuals between predicted and observed UT1: http://iraf.noao.edu/~seaman/leap/images/ BminusA.gif. Would be delighted if that improvement were reflected in better policies for UTC and civil time handling. 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. Can't argue with that - although ultimately a single well tied knot is stronger than a tangle of slip knots and Grannies. And even a well built system - a supremely constructed knot - is subject to the Alexander factor. His sword violated the assumptions made by Midas' father Gordius in tying the knot. 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. Seems reasonable for a wide range of applications. As I've said in the past, I'm not driven by a love of leap seconds, per se, but by the identification of civil time with solar time. The issue of triggering on a particular scheduled event is actually quite familiar from other projects. One that I'm working on at the moment is a mechanism for conveying sky transient alerts (http://ivoa.net/twiki/ bin/view/IVOA/VoeventWorkshop2). Another was a way to trigger an even sun centered cadence of CCD exposures attached to a spectrograph. This consisted of taking >10,000 individual spectra of a particular star (Procyon) on an even temporal grid extending over several months. The gimmick was that the clock had to be adjusted for the changing light travel time across the Earth's orbit. I won't belabor the point (much), but it certainly is easier to build trust in the correctness of such a trigger if the cadence is rapid, rather than glacially slow. Rob Seaman National Optical Astronomy Observatory
Re: Longer leap second notice
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 t
Fwd: [LEAPSECS] Longer leap second notice
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. 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. 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 know you aren't pursuaded by such arguements. I'm prepared to be persuaded by complete, coherent proposals based on real world (and real economic) concerns. 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"? 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. It must be obvious that my intent was to come out swinging after the leap second - just as the obvious intent of the folks pushing the proposal is to use any reports of systems failing to appropriately handle the leap second as fodder for renewing their efforts. That said, if there are such reports, let's hear them and get to work together (for once). (Some might consider me a software professional as well - am not particularly annoyed if you do not.) Would be delighted to hear more about your leap second infrastructure. Rob Seaman National Optical Astronomy Observatory
Re: Longer leap second notice, was: Where the responsibility lies
> I continue to find the focus on general purpose computing > infrastructure to be unpersuasive. If we can convince hardware and > software vendors to pay enough attention to timing requirements to > implement such a strategy, we can convince them to implement a more > complete time handling infrastructure. This seems like the real goal > - one worthy of a concerted effort. Instead of trying to escape from > the entanglements of this particular system requirement, why don't we > focus on satisfying it in a forthright fashion? 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. I had one system that worked over the leap second correctly, even though the code to parse the data from this specific brand of GPS receiver hadn't been written yet. It worked because it knew about the leap second in a table that we'd included on our flash as a fallback when we didn't know anything else. 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 :-). I know you aren't pursuaded by such arguements. 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 :-( Warner
Re: Longer leap second notice, was: Where the responsibility lies
On Jan 3, 2006, at 4:22 PM, Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Ed Davies writes: Poul-Henning Kamp wrote: If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need to update the factory installed table of leapseconds. PHK can reply for himself here but, for the record, I think RS's reading of what he said is different from mine. My assumption is that PHK is discussing the idea that leaps should be scheduled many years in advance. They should continue to be single second leaps - just many more would be in the schedule pipeline at any given point. Obviously, the leap seconds would be scheduled on the best available estimates but as we don't know the future rotation of the Earth this would necessarily increase the tolerance. In theory DUT1 would be unbounded (as it sort of is already) but PHK is assuming that there'd be some practical likely upper bound such as 10 seconds. Am I right in this reading? yes. I'm willing to entertain any suggestion that preserves mean solar time as the basis of civil time. One could view this notion as a specific scheduling algorithm for leap seconds. My own ancient proposal (http://iraf.noao.edu/~seaman/leap) was for a tweak to the current algorithm that would minimize the excursions between UTC and UT1. This suggestion is more than a tweak, of course, since it would require increasing the 0.9s limit. One could imagine variations, however, with sliding predictive windows to balance the maximum excursion against the look ahead time. One is skeptical of any advantage to be realized over the current simple leap second policy. I continue to find the focus on general purpose computing infrastructure to be unpersuasive. If we can convince hardware and software vendors to pay enough attention to timing requirements to implement such a strategy, we can convince them to implement a more complete time handling infrastructure. This seems like the real goal - one worthy of a concerted effort. Instead of trying to escape from the entanglements of this particular system requirement, why don't we focus on satisfying it in a forthright fashion? There is also the - slight - issue that we aren't only worried about "computers". There is a heck of a lot of interesting infrastructure that should be included in the decision making envelope. In general, the strategy you describe could also be addressed as an elaboration on the waveform we are attempting to model with our clocks. Not a constant cadence like tick-tick-tick-tick, that is, but tick-tick-tock-tick. I do think there might be some interesting hay to be made by generalizing our definition of a clock to include quasi-periodic phenomena more complicated than a once-per-second delta function. Would give us some reason to explore the Fourier domain if nothing else. Rob Seaman National Optical Astronomy Observatory
Re: Longer leap second notice, was: Where the responsibility lies
In message <[EMAIL PROTECTED]>, Ed Davies writes: >Poul-Henning Kamp wrote: >>> If we can increase the tolerance to 10sec, IERS can give us the >>> leapseconds with 20 years notice and only the minority of computers >>> that survive longer than that would need to update the factory >>> installed table of leapseconds. > >PHK can reply for himself here but, for the record, I think RS's >reading of what he said is different from mine. My assumption is >that PHK is discussing the idea that leaps should be scheduled many >years in advance. They should continue to be single second leaps - >just many more would be in the schedule pipeline at any given >point. > >Obviously, the leap seconds would be scheduled on the best available >estimates but as we don't know the future rotation of the Earth this >would necessarily increase the tolerance. In theory DUT1 would be >unbounded (as it sort of is already) but PHK is assuming that there'd >be some practical likely upper bound such as 10 seconds. > >Am I right in this reading? yes. -- 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: Longer leap second notice, was: Where the responsibility lies
Poul-Henning Kamp wrote: If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need to update the factory installed table of leapseconds. Rob Seaman replied: No. Rather all computers that exist during such an event are obligated to deal with it. The number of deployed systems follows some increasing trend similar to Moore's law. By delaying the adjustments, you guarantee that more systems will be affected when they do occur. And, unless you can guarantee that a particular deployed system (and systems derived through various upgrade pathways) will be retired prior to the adopted horizon, prudent policy would require remediation in any event. Would like to see a proposed architecture a little more detailed than a "factory installed table". PHK can reply for himself here but, for the record, I think RS's reading of what he said is different from mine. My assumption is that PHK is discussing the idea that leaps should be scheduled many years in advance. They should continue to be single second leaps - just many more would be in the schedule pipeline at any given point. Obviously, the leap seconds would be scheduled on the best available estimates but as we don't know the future rotation of the Earth this would necessarily increase the tolerance. In theory DUT1 would be unbounded (as it sort of is already) but PHK is assuming that there'd be some practical likely upper bound such as 10 seconds. Am I right in this reading? Ed.
