Re: The opportunity of leap seconds
On Sat, 7 Jan 2006, Poul-Henning Kamp wrote: > > What Astronomers use UTC for, in your own many times repeated words, > is "a convenient approximation of UT1", and consequently it follows > that if instead of an approximation astronomers used the Real Thing, > leap seconds could harmlessly be removed from UTC. > Too simple; many old telescopes, with equatorial mounts, such as the historic telescopes at the Institute of Astronomy where I work, do indeed use UTC as a UT1 approximation. The time error involved in this is a small offset in one axis which you calibrate out on a "clock star". Research-quality telescopes, in particular all the ones built in the last few decades on alt-azimuth mounts, do of course use UT1; a 0.9s error would be a complex ~10 arcsec error in both axes and give a quite useless pointing performance. However, UTC is often used as a UT1 delivery system; because it's an international standard, and is widely available, and DUT1 is guarenteed to be less than 0.9s, it's a natural choice for supplier of time. Interestingly, because control algorithms tend to be rigorous, a large DUT1 probably would be ok in itself (there would be a cost involved in checking that this would be so) but certainly in the case of a couple of telescope control systems of which I have the required knowledge, the DUT1 input method does a 0.9 second range check. Peter.
Re: The opportunity of leap seconds
In message <[EMAIL PROTECTED]>, Peter Bunclark writes: >On Sat, 7 Jan 2006, Poul-Henning Kamp wrote: >Research-quality telescopes, in particular all the ones built in the last >few decades on alt-azimuth mounts, do of course use UT1; a 0.9s error >would be a complex ~10 arcsec error in both axes and give a quite useless >pointing performance. However, UTC is often used as a UT1 delivery >system; It sounds to me like BIPM ought to make an Internet service available which will deliver UT1 to astronomers in a timely fashion ? Something as simple as finger [EMAIL PROTECTED] Or even just a more stringent formatting of the bulletins on the ftp site could do it as well. -- 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: The real problem with leap seconds
Wow, things have got really stirred up around here. Lots of interesting points but I'll just concentrate on one... Poul-Henning Kamp wrote: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can see where he is coming from on that one. Since the usual response of the pro-leap second lobby to people who want a uniform timescale is "use TAI" this is significant. Do you have any information or references on why the BIPM director said this? Ed.
Re: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Ed Davies writes: >Wow, things have got really stirred up around here. Lots of interesting >points but I'll just concentrate on one... > >Poul-Henning Kamp wrote: >> Well, the BIPM doesn't really want anybody to use TAI, their director >> said as much last year, and I can see where he is coming from on that >> one. > >Since the usual response of the pro-leap second lobby to people >who want a uniform timescale is "use TAI" this is significant. >Do you have any information or references on why the BIPM director >said this? As I understood it, it was mainly that TAI is a post-factum "postal" timescale. -- 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: The opportunity of leap seconds
On Sun 2006-01-08T12:41:21 +0100, Poul-Henning Kamp hath writ: > It sounds to me like BIPM ought to make an Internet service available > which will deliver UT1 to astronomers in a timely fashion ? That would have to be the IERS. > Something as simple as > > finger [EMAIL PROTECTED] > > Or even just a more stringent formatting of the bulletins on the ftp > site could do it as well. I do not believe that any of the IERS bureaus have internet connections and servers which are anywhere near robust and redundant enough to make that a reliable service. There is a lot that could and should be done. The USNO branch of the IERS issues two files with predictions about earth orientation every Thursday. It is not widely known that last July on the Thursday following the Daniel Gambis announcement one of those files acknowledged the leap second we just experienced, and the other did not. This was fixed with a new release which happened by Friday. (Despite some NTP servers which reportedly still have not acknowledged the leap second, I think the overall indications are that the NTP network did better than 50 %.) The existing IERS system is dysfunctional. -- 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: The opportunity of leap seconds
On Sun, 8 Jan 2006, Poul-Henning Kamp wrote: > finger [EMAIL PROTECTED] You mean [EMAIL PROTECTED] That would be quiet useful. Otherwise let's not bother with NTP protocol, just [EMAIL PROTECTED] Pete.
Re: The real problem with leap seconds
Poul-Henning Kamp wrote: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can see where he is coming from on that one. Ed Davies asked: Since the usual response of the pro-leap second lobby to people who want a uniform timescale is "use TAI" this is significant. Do you have any information or references on why the BIPM director said this? Poul-Henning Kamp replied: As I understood it, it was mainly that TAI is a post-factum "postal" timescale. Well, yes, at well below the one microsecond level (10s of nanoseconds I think). The same would apply to UTC, of course, given that it's defined by an offset from TAI and I doubt he meant the world should stop using UTC. Of course, in the real world people don't directly use UTC anyway - they use UTC(NIST) or UTC(NPL) or whatever local approximation is good enough for their purposes. This would be true for any timescale. Ed.
Re: predicting leap seconds
On Jan 7, 2006, at 11:01 PM, M. Warner Losh wrote: This would phase in the predictive timeline for leap second insertions, and would also give the IERS control to end the experiment if the time horizons exceeded their ability to predict with confidence. it would also be completely within the current UTC specification and practices. The various bulletins are required to be released with a minimum look-ahead schedule. No particular reason they might not issue a bulletin every six months including both scheduled leap seconds and unscheduled predictions in a sliding window extending forward a decade or more.
Re: The real problem with leap seconds
On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: > Well, the BIPM doesn't really want anybody to use TAI, their director > said as much last year The Italian contribution to the November 2005 WP7A meeting could be interpreted a suggestion that the international agencies in charge of time scales need to get their heads together, pick one time scale with no discontinuities, and abolish all others. Klepczynski had implied that more clearly on pages 322 and 323 of http://tycho.usno.navy.mil/ptti/ptti2004/panel.pdf where he discusses getting all the satellite navigation systems to use a single time scale. (And to see that psychology is not just relevant to astronomers, read Matsakis on page 336.) -- 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: The opportunity of leap seconds
On Jan 8, 2006, at 4:41 AM, Poul-Henning Kamp wrote: It sounds to me like BIPM ought to make an Internet service available which will deliver UT1 to astronomers in a timely fashion ? Not sure BIPM is necessarily the appropriate agent, but otherwise agree 100%. Perhaps we should seek other areas of agreement rather than continually focusing on issues in hot debate. Both this and the extended leap second scheduling represent improvements to infrastructure that would also support market-based decision making about civil time issues in general. The current timekeeping landscape is simply too sparse to create significant emergent behavior.
Re: The real problem with leap seconds
On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote: As I understood it, it was mainly that TAI is a post-factum "postal" timescale. One is left pondering the fact that UTC is now (and would remain under any changes I've heard suggested) a time scale based on TAI. What magic makes one acceptable and the other not?
Re: The opportunity of leap seconds
In message <[EMAIL PROTECTED]>, Steve Allen writes: >> Something as simple as >> >> finger [EMAIL PROTECTED] >> >> Or even just a more stringent formatting of the bulletins on the ftp >> site could do it as well. > >I do not believe that any of the IERS bureaus have internet >connections and servers which are anywhere near robust and redundant >enough to make that a reliable service. > >There is a lot that could and should be done. I'm certainly starting to get the impression that a modernization project to move the "time-lords" a few decades forward would not be out of order. >(Despite some NTP servers which reportedly still have not acknowledged >the leap second, I think the overall indications are that the NTP >network did better than 50 %.) My estimate is 50-70% of the pool.ntp.org servers did something close enough to the right thing. -- 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: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Steve Allen writes: >On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: >> Well, the BIPM doesn't really want anybody to use TAI, their director >> said as much last year > >The Italian contribution to the November 2005 WP7A meeting could be >interpreted a suggestion that the international agencies in charge of >time scales need to get their heads together, pick one time scale with >no discontinuities, and abolish all others. That sounds like the sensible partys platform to me. Doing so would once and for all have to divorce earth orientation from that unified time scale, leaving it to governments to align civil time with daylight as they see fit (just like today). >Klepczynski had implied that more clearly on pages 322 and 323 of >http://tycho.usno.navy.mil/ptti/ptti2004/panel.pdf >where he discusses getting all the satellite navigation systems >to use a single time scale. It is the time scale that is the issue, it's the clock offset between the systems. If you have 2 GPS sats, one GLONASS and one GALILEO, you also need to know the clock offsets between the three systems before you can calculate a position. If everybody gets their act together and hold the clock offsets small, then it would be a wonderful world indeed, but I think the practical, organizational and political problems will prevent that. The other option is for the systems to broadcast their clock offsets relative to the other systems. For that to help rapid first fix it must be a frequent broadcast (ie: non-almanac) otherwise you might as well just wait until you get four birds in one system. >(And to see that psychology is not just relevant to astronomers, >read Matsakis on page 336.) Yes, astronomers have psychology too, but the comments on that page has nothing to do with leap seconds at all. -- 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: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote: > >> As I understood it, it was mainly that TAI is a post-factum >> "postal" timescale. > >One is left pondering the fact that UTC is now (and would remain >under any changes I've heard suggested) a time scale based on TAI. >What magic makes one acceptable and the other not? I didn't say I thought the protest against more widespread use made sense, I merely tried to relay it faithfully. I does sound consistent with previously mentioned old fashionedness. -- 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: The opportunity of leap seconds
In message <[EMAIL PROTECTED]>, Peter Bunclark writes: >On Sun, 8 Jan 2006, Poul-Henning Kamp wrote: >> finger [EMAIL PROTECTED] > >You mean [EMAIL PROTECTED] That would be quiet useful. Otherwise let's not >bother with NTP protocol, just [EMAIL PROTECTED] I don't really care what the service is called, but I agree that it should be simple :-) -- 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.
interoperability
On Jan 8, 2006, at 9:09 AM, Poul-Henning Kamp wrote: Doing so would once and for all have to divorce earth orientation from that unified time scale, leaving it to governments to align civil time with daylight as they see fit (just like today). Without further debating the meaning of "civil time", consider the implications of this two stage system. The first stage conveys TAI or something related to it by a constant offset. The second stage at any location (correct me if I misunderstand you) would be a secondary clock disseminated at the direction of the local authorities. Governments and technical users would subscribe to the first stage clock. Businesses and civilians would subscribe to the second stage clock(s). Correct so far? For the sake of argument, let's discount the risks associated with confusing one stage's clock with the other. One imagines, however, that there won't be fewer safety critical, time dependent systems in the future. We might, in fact, suspect that every party to this conversation would both admit this and use it to argue for their own position :-) Those risks, however, represent only one issue falling under the umbrella of interoperability. It is one thing to say that any random local government can choose their own clock statutes. This is certainly true, but in practice the future international community will work together to reach joint decisions on evolving common clock practices (as you say, "just like today"). I won't belabor the many worldwide systems that must interoperate for the benefit of all. But these systems must interoperate not only between themselves, but with natural phenomena. Forgive me (or don't), but I am skeptical that phenomena of interest in the future will not continue to include the rising and setting of the sun. (And isn't claiming otherwise equivalent to saying that stage two is unnecessary?) The question is: how precisely does this differ from the situation now or in the past? Whether by fiat or not, some common worldwide "stage two" clock must exist. And some mechanism must exist for synchronizing (to some level of tolerance that we can continue to debate) that clock to diurnal cycles. It is this synchronization that is ultimately of interest to us, not leap seconds, per se. I have heard no response to my discussion of techniques for achieving synchronization - of the difference between naive "fall back" hours and 25 hour days. But how in practice is it envisaged that a scheme for migrating time zones versus TAI would work, precisely? Note, for instance, that nothing short of redefining the second can avoid the quadratic acceleration between the stage one and stage two clocks. Time zones (and the prime meridian?) would race more-and-more rapidly around the globe. Perhaps I've misunderstood, but this line of reasoning doesn't appear to resolve anything. Rob Seaman National Optical Astronomy Observatory
Re: The real problem with leap seconds
In message: <[EMAIL PROTECTED]> "Poul-Henning Kamp" <[EMAIL PROTECTED]> writes: : In message <[EMAIL PROTECTED]>, Ed Davies writes: : >Wow, things have got really stirred up around here. Lots of interesting : >points but I'll just concentrate on one... : > : >Poul-Henning Kamp wrote: : >> Well, the BIPM doesn't really want anybody to use TAI, their director : >> said as much last year, and I can see where he is coming from on that : >> one. : > : >Since the usual response of the pro-leap second lobby to people : >who want a uniform timescale is "use TAI" this is significant. : >Do you have any information or references on why the BIPM director : >said this? : : As I understood it, it was mainly that TAI is a post-factum "postal" : timescale. How is it that UTC can be realized in realtime, but TAI isn't. I thought the difference between the two was an integral number of seconds, by definition. Is that understanding flawed? Wanrer
Re: interoperability
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >On Jan 8, 2006, at 9:09 AM, Poul-Henning Kamp wrote: > >> Doing so would once and for all have to divorce earth orientation >> from that unified time scale, leaving it to governments to align >> civil time with daylight as they see fit (just like today). > >Without further debating the meaning of "civil time", consider the >implications of this two stage system. The first stage conveys TAI >or something related to it by a constant offset. Yes, too bad about the offsets (GPS etc) but as long as they don't change with short notice, they can be dealt with. >The second stage at >any location (correct me if I misunderstand you) would be a secondary >clock disseminated at the direction of the local authorities. Yes, just like now. The DCF77 transmitter for instance sends out "German legal time" which means that if you want UTC from it, you need to know the UTC offset for summer/winter in Germany. >Governments and technical users would subscribe to the first stage >clock. Businesses and civilians would subscribe to the second stage >clock(s). Correct so far? Almost. What you overlook here is that computers tend to trancend governmental boundaries. Sensibly designed operating systems keep time in the form of the first stage clock, and at the representation layer, knowing all the worlds governmental decisions about getting from 1st to second stage applies the appropriate conversions. Badly designed operating systems keep time in local time which makes interchange of information a nightmare across timezones. Windows have got it right now I belive, but it used to be that a file created and transmitted from Denmark at the end of the business day would be older than a file created at the start of business day in California, despite a strict ordering of the events. >For the sake of argument, let's discount the risks associated with >confusing one stage's clock with the other. That's actually the good thing about the constant offset, it should make it much easier to see if timestamps mix things that shouldn't be. >I won't belabor the many worldwide systems that must interoperate for >the benefit of all. But these systems must interoperate not only >between themselves, but with natural phenomena. Sure, and you can timestamp then on either timescale, because there is a 1 to 1 translation between the two timescales [1]. You mention sunrise and sunset. Since the introduction of timezones, one of the things which were given up was the concept that sunrise/sunset happened on the same numerical time at any given lattitude. Denmark spans only a few hundred kilometers from east to west (not counting Greenland this time), yet sunrise and sunset varies about 30 minutes from one side to the other. Most people get the sunrise/sunset numbers out of the "Almanac from the Copenhagen Universitys Observatory" [2] which lists sun rise/set times for the observatory in Copenhagen and prints a table of approximate geographical adjustment factors. So already today, sunrise & sunset can only be determined using auxillary tables of correction factors, tables which could trivially absorb the DUT correction in addition to the longtude corrections. >The question is: how precisely does this differ from the situation >now or in the past? Whether by fiat or not, some common worldwide >"stage two" clock must exist. BZZZT wrong. The definition we started out with is: The second stage at any location (correct me if I misunderstand you) would be a secondary clock disseminated at the direction of the local authorities. Conversion from stage two to stage one (and back) is perfect, so if I measure a supernova in Denmark on Danish Civil Time, I can mail you my observations and you can convert it first to stage 1 and then to your local stage 2 to compare with your own observation. Or more likely, convert your own stage 2 to stage 1 and compare in the "scientific time domain". If Denmark or Elbonia decides to use a timezone which is offset from stage one by 1h3m21s, then it still works, (but people travelling abroad will probably vote differently in the next election) >I have heard no response to my discussion of techniques for achieving >synchronization - of the difference between naive "fall back" hours >and 25 hour days. But how in practice is it envisaged that a scheme >for migrating time zones versus TAI would work, precisely? The same way all changes in timezone seems to be carried out: by _not_ adjusting the clock when going to summer or winter time. In a couple of hundred years, the Danish Parliament (or its successor in interest) will simply decide "from -MM-DD HH:00, the Danish Civil time will use offsets -3h and -2h (instead of presently -1h/-2h) and the transition will happen on the switch from summertime to wintertime by _not_ adjusting the clock". That's been done many times throughout the world already. If you look in NPL's decript
Re: The real problem with leap seconds
On Sun 2006-01-08T11:44:04 -0700, M. Warner Losh hath writ: > How is it that UTC can be realized in realtime, but TAI isn't. I > thought the difference between the two was an integral number of > seconds, by definition. Is that understanding flawed? I believe the claim would be that UTC(insert your national time service here) is realized in real time. UTC(USNO) is the official time of the US, and I suspect that there would be loss of face if any agency charged with keeping a national time did not, in some sense, proclaim autonomy. UTC(pick one) is, of course, directly related to TAI(pick one). TAI(anywhere) has no official status anywhere, except in the ex post facto statistical sense that it contributes to TAI (unmodified, the real thing from the BIPM). In an official sense of operational time scales, it is not clear that there really is anything such as UTC (plain old, unmodified) which differs from TAI by an integral number of seconds. As an identifiable entity, UTC (unmodified) may only exist within the text of ITU-R TF.460 -- 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: The real problem with leap seconds
> : As I understood it, it was mainly that TAI is a post-factum "postal" > : timescale. > > How is it that UTC can be realized in realtime, but TAI isn't. I > thought the difference between the two was an integral number of > seconds, by definition. Is that understanding flawed? > > Wanrer Not flawed. But recognize that the words UTC or TAI have more than one meaning. Strictly speaking UTC isn't real-time either. However, individual laboratories produce a real-time realization of UTC, in the form of UTC(k) where k = NIST, USNO, NPL, etc. which is then steered, over time, toward or around the mean. Your own lab or home may have its own realization of UTC, such as Doug's UTC(DWH) or my UTC(TVB). Note there has been strong resistance to the use of the phrase UTC(GPS). True, there exists UTC(USNO) but what a GPS navigation or timing receiver delivers is many layers of uncalibrated phase and frequency offset and uncertainty from UTC(USNO) which it itself just an good estimate of UTC. This is all at the sub-microseconds level. Up at the seconds level the generic terms "UTC time", "TAI time", "GPS time", or, for that matter, "local time", are simply a matter of integer seconds offset; they all nominally follow the same synchronized seconds epoch (1PPS). So when you see "UTC" or "TAI" you have to infer the context. Is the timescale; is it seconds; is it nanoseconds? The danger is mixing the generic use of the acronym (meaning seconds offset) with a more technical use of the word (meaning the realization of the timescale). I can easily set a cesium clock or wristwatch to display in UTC, TAI, GPS, EST, or local time. The ticks occur at the same time. The hands or digits differ. But does this mean my UTC(TVB) clock can produce UTC? or TAI? Yes, it can produce a display that matches TAI to some finite accuracy. No, it does not produce TAI itself. http://www.leapsecond.com/pages/trak6460/ If I had to guess, the resistance to the use of the word TAI by the BIPM or others is that in the past and still today the word TAI represents *first* the notion of a well-organized international ensemble of atomic clocks. Only secondarily does the TAI convey something as mundane as an N second offset on your wristwatch. Mixing the two meanings can lead to trouble. For example, occasionally you hear that Galileo is somehow better than GPS because it uses TAI time instead of GPS time. That's bogus. To the second, any existing WWVB or DCF77 or GPS or Glonass or Galileo receiver can display time as TAI or GPS or UTC, or EST, or sidereal. Clever ones can even handle DST. But at the nanosecond level Galileo can no more deliver TAI than pizza to your receiver. /tvb
Re: The opportunity of leap seconds
> Research-quality telescopes, in particular all the ones built in the last > few decades on alt-azimuth mounts, do of course use UT1; a 0.9s error > would be a complex ~10 arcsec error in both axes and give a quite useless > pointing performance. However, UTC is often used as a UT1 delivery > system; because it's an international standard, and is widely available, > and DUT1 is guarenteed to be less than 0.9s, it's a natural choice for > supplier of time. Interestingly, because control algorithms tend to be > rigorous, a large DUT1 probably would be ok in itself (there would be a > cost involved in checking that this would be so) but certainly in the case > of a couple of telescope control systems of which I have the required > knowledge, the DUT1 input method does a 0.9 second range check. > > Peter. Peter, So where do these modern telescope get UT1? Do you or any other astronomers on the list know if they pick off bits from WWV (or equivalent SW or LF broadcast)? Or is there a nice thumbwheel switch in a control room that someone gets to advance anytime they get an IERS Bulletin by FAX or email? Or is it a software interface to the IERS website? I guess in all the years this list has operated, and with all the detailed anecdotes about leap seconds I've never heard details of how an observatory anywhere actually obtains, and uses, DUT1; and to what level of precision. /tvb
Re: interoperability
On Jan 8, 2006, at 12:48 PM, Poul-Henning Kamp wrote: What you overlook here is that computers tend to trancend governmental boundaries. This only strengthens my arguments. Anything that ties the world together more tightly functions to create a single world "stage two" system. Sensibly designed operating systems keep time in the form of the first stage clock, Perhaps. We have no examples of this. Stage one would be TAI. As we have just been reminded, TAI is "not ready for prime time". Badly designed operating systems keep time in local time which makes interchange of information a nightmare across timezones. You are arguing apples and oranges. These operating systems, in effect, use "stage three" clocks. Current (well designed) operating systems start with stage two (UTC). The question of delivering wall clock time is a trivial elaboration on first delivering common international business time. (I'm trying on different terminology than "civil time" until I hit one that sticks.) That's actually the good thing about the constant offset, it should make it much easier to see if timestamps mix things that shouldn't be. How precisely? I am willing to be convinced but I simply don't see what you mean. The fundamental error was in allowing sexigesimal representation to be used for conflicting purposes. Two planes following parallel tracks in opposite directions better be using the same clock. Sure, and you can timestamp then on either timescale, because there is a 1 to 1 translation between the two timescales [1]. Perhaps I miss your meaning here, too. The event of migrating a time zone is a discontinuity just as with a leap second or leap hour. Denmark spans only a few hundred kilometers from east to west (not counting Greenland this time), yet sunrise and sunset varies about 30 minutes from one side to the other. This is true. It is irrelevant to the underlying international clock. These are simply constant (if position dependent) offsets. Big wup. I think this issue is confusing the discussion. Longitudinal offsets with a time zone are irrelevant; the equation of time is irrelevant; daylight saving time is irrelevant. They may all be interesting effects, but they don't affect the underlying worldwide clock tick in the same fashion as cumulative secular offsets caused by rotational rate changes. What matters is not when sunrise occurs, but rather that every day has one (and only one). Conversion from stage two to stage one (and back) is perfect, Don't believe a detailed enough proposal is on the table to either define the meaning of "perfect" in this context, or determine if the notion being discussed meets the requirements for being so regarded. If Denmark or Elbonia decides to use a timezone which is offset from stage one by 1h3m21s, then it still works, Again, what is "it", precisely? (but people travelling abroad will probably vote differently in the next election) Exactly. The pressures to maintain a common international vision of time will trump local variations. It is the resulting common international time clock that you won't let me refer to as "civil time". All requirements placed on UTC flow backwards from here. You can't just edit UTC (or GMT) out of the debate. stage one is atomic time (e.g., TAI) stage two is international civil time (e.g., UTC) stage three is local legal time (e.g., Mountain Standard Time) One could even regard stage four as daylight saving, but I think this is equivalent to a separate realization of stage three time at a particular location. I suspect you will reject this out of hand, but perhaps you might first ask the nice folks at the Copenhagen observatory for their opinions. In a couple of hundred years, the Danish Parliament (or its successor in interest) will simply decide "from -MM-DD HH:00, the Danish Civil time will use offsets -3h and -2h (instead of presently -1h/-2h) and the transition will happen on the switch from summertime to wintertime by _not_ adjusting the clock". The only way this differs from the leap hour proposal is that you are assuming that different localities can (or would) carry these adjustments out separately. Let's see - how does this work? The Earth is slowing (has slowed), so TAI is progressively "lapping" UTC. (TAI was 32s ahead of UTC, now it is 33s ahead.) One might entertain embargoing leap seconds (or the equivalent time zone operations) until an hour's worth accumulates. (A better choice would be to seesaw a half hour either way around the "natural center", but the same logic applies.) So imagine an hour's worth of "time pressure" has accumulated after a few hundred years. Under the current standard, 3600 small steps would have bled away the pressure. Under the ITU notion, a leap hour would be needed. A leap hour means moving UTC backward one hour (to let TAI pull ahead). As I've said before, under the daylight saving analogy this is only n
Re: interoperability
> Without further debating the meaning of "civil time", consider the > implications of this two stage system. The first stage conveys TAI > or something related to it by a constant offset. The second stage at > any location (correct me if I misunderstand you) would be a secondary > clock disseminated at the direction of the local authorities. > Governments and technical users would subscribe to the first stage > clock. Businesses and civilians would subscribe to the second stage > clock(s). Correct so far? I think this was a fair description of the timekeeping world in the 1960s or even 1970s. But in the last 10 or 20 years, with the explosion in consumers of broadcast time and frequency services such as WWVB, DCF, GPS, and NTP, vast numbers of applications have direct access to the "first stage"; which effectively removes the power of the middle man, the government, the "local authorities". What was your human "technical user" of 1970 is now the infrastructure of the cellular phone system or the hardcoded algorithms of an operating system or home appliance. The technical users of the 60s have coded themselves into products of the 90s. You cannot divide timekeeping, time dissemination, into neat stages. In the 1960s if ten labs were told to offset their phase or frequency it affected only a handful of people or systems. Today when IERS announces a leap second, millions of machines, systems, and people are affected. Thankfully, most of them handle it OK. /tvb
Re: interoperability
On Jan 8, 2006, at 4:04 PM, Tom Van Baak wrote: You cannot divide timekeeping, time dissemination, into neat stages. Again. My point is strengthened. This being the case, a requirement on one "flavor" of time transfers to others. We will not solve the problem of creeping complexity and interface violations by attempting to legislate the physical world out of the equation. Rather, it is the common baseline of mean solar time that will save us from our own follies. Whether it is a "real number" or not, it has the benefit of correspondence (now, and day after day, millennia after millennia) of mattering to humanity. I don't say it matters in critical detail for every purpose under the sun, rather it matters in broad strokes for many a purpose. I've got nothing against TAI and other flavors of interval time, they simply do not match the requirements for a common human oriented baseline. They are preferred for some technical purposes. They are most definitely not preferred in "broad strokes" over long periods of time to the bulk of our "customers". The customer is always right. Rob
Re: interoperability
On 8 Jan 2006 at 15:04, Tom Van Baak wrote: > You cannot divide timekeeping, time dissemination, > into neat stages. In the 1960s if ten labs were told > to offset their phase or frequency it affected only a > handful of people or systems. Today when IERS > announces a leap second, millions of machines, > systems, and people are affected. Thankfully, most > of them handle it OK. Although, even now, the majority of consumer and business equipment is not directly affected in any noticeable way; such machines usually run on a local clock considerably less accurate than an atomic clock, periodically re-synced (perhaps manually, perhaps automatically) to an external time standard. At each such re-syncing, the time may need to be adjusted by a few seconds, or even a few minutes, due to inaccuraccies in the local timepiece, so any leap second that may have occurred since the last syncing will merely result in a 1-second difference in the magnitude of this adjustment, not particularly noticeable to the end users. If some application (e.g., a database) requires a timescale without discontinuities, the application might need to be shut down for a few seconds to perform the time adjustment (whether or not there is a leap second in the mix) in order to prevent data corruption at the moment of the change. -- == 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: interoperability
> > You cannot divide timekeeping, time dissemination, > > into neat stages. In the 1960s if ten labs were told > > to offset their phase or frequency it affected only a > > handful of people or systems. Today when IERS > > announces a leap second, millions of machines, > > systems, and people are affected. Thankfully, most > > of them handle it OK. > > Although, even now, the majority of consumer and business equipment > is not directly affected in any noticeable way; such machines usually > run on a local clock considerably less accurate than an atomic clock, > periodically re-synced (perhaps manually, perhaps automatically) to > an external time standard. At each such re-syncing, the time may > need to be adjusted by a few seconds, or even a few minutes, due to > inaccuraccies in the local timepiece, so any leap second that may > have occurred since the last syncing will merely result in a 1-second > difference in the magnitude of this adjustment, not particularly Correct. This works for timepieces which are less than accurate to the second. And I believe this is why UTC and leap seconds are still today the most practical and accepted way to reconcile the unavoidable difference between astronomical and atomic timescales. The danger, though, is that in the 60s maybe ten systems were affected by leap seconds. In the 80s maybe a thousand. Today, the number of systems affected (or is it infected?) with leap second awareness is in the millions. I worry about this trend in the decades to come. I am a fan of leap seconds as a weird and curious nuisance but am not sure I like the idea that eventually my car, traffic lights, airlines, television, and my thermostat will have to be reliably tied to the IERS in order to function properly. Don't forget the quartz wristwatch is only 40 years old. What if cesium wristwatches show up 10 years from now. What if some killer app 40 years hence requires 100 ms or 1 ms time accuracy. Do we still want UTC leap seconds when it will infect ten billion devices? This is not an argument for change right now. But no matter how you look at it the current scheme does not scale well into the future; either a technological future (way too many devices affected by unscheduled time steps) or an astronomical future (way too many leap seconds a year). > noticeable to the end users. If some application (e.g., a database) > requires a timescale without discontinuities, the application might > need to be shut down for a few seconds to perform the time adjustment > (whether or not there is a leap second in the mix) in order to > prevent data corruption at the moment of the change. I would guess your total shutdown "solution" gets less popular as time goes on. That's one reason why CDMA cell phones, most operating systems, and GPS use a TAI-like continuous timescale instead of UTC for their underlying timescale. /tvb
Re: interoperability
On Jan 8, 2006, at 6:41 PM, Tom Van Baak wrote: am not sure I like the idea that eventually my car, traffic lights, airlines, television, and my thermostat will have to be reliably tied to the IERS in order to function properly. This is a general issue with the increasingly tight coupling between any number of networked systems. Certainly not unique to timekeeping. On the other hand, rarely should any system (certainly not a safety critical application) depend on a clock that must remain tightly slaved to *any* external signal. Consider what evolutionary path technology would have to take such that significant numbers of traffic lights and thermostats would ever require direct contact with the IERS. It's easy to speculate about pathological engineering practices - A requires access to B, immediately and always, perfect and inviable. But real designs result from real requirements. What if some killer app 40 years hence requires 100 ms or 1 ms time accuracy. Don't think "accuracy" is the word you want. The short answer to your question is that all the time wonks would celebrate their newfound employability. Do we still want UTC leap seconds when it will infect ten billion devices? Perhaps you meant "affect"? :-) What we want and what we need are two different things. And as is currently true, those devices aren't required to use UTC unless they need UTC. the current scheme does not scale well into the future; No, it does not - but there are two caveats: 1) the current scheme (also known as an "international standard") is good for several hundred years 2) no other scheme scales better either a technological future (way too many devices affected by unscheduled time steps) or an astronomical future (way too many leap seconds a year). As I pointed out close to five years ago, the ultimate long term remediation will likely involve redefining the length of the second: http://iraf.noao.edu/~seaman/leap Nothing over the years of intervening discussions has given me cause to change my opinion. Rob
Re: interoperability
Rob Seaman scripsit: > The question is: how precisely does this differ from the situation > now or in the past? Whether by fiat or not, some common worldwide > "stage two" clock must exist. Again, no it doesn't need to exist. We need a uniform time scale like TAI. And we need local civil time for all the 400-odd jurisdictions in the world today. If other people need other timescales (and they do), there's no reason that should affect the two requirements above. > But how in practice is it envisaged that a scheme > for migrating time zones versus TAI would work, precisely? Straightforwardly. Each locality decides when and how to adjust both its offset from TAI and its seasonal transition function (if any), just as it does today. What we abandon is a universal time tightly synchronized to Earth rotation in favor of a universal time independent of earth rotation plus 400+ local civil times roughly synchronized to Earth rotation containing various glitches. -- We pledge allegiance to the penguin John Cowan and to the intellectual property regime [EMAIL PROTECTED] for which he stands, one world underhttp://www.ccil.org/~cowan Linux, with free music and open source http://www.reutershealth.com software for all. --Julian Dibbell on Brazil, edited
Re: interoperability
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >> Sensibly designed operating systems keep time in the form of the >> first stage clock, > >Perhaps. We have no examples of this. Stage one would be TAI. As >we have just been reminded, TAI is "not ready for prime time". Stop. You yourself defined stage one as "TAI with some constant offset" yourself, you can't change definition in the middle of the discussion. Stage one is something like GPS time or UTC with no further leap seconds. Today stage one is UTC with leapseconds and all POSIX systems use that but fake the leapseconds. >> Badly designed operating systems keep time in local time which >> makes interchange of information a nightmare across timezones. > >You are arguing apples and oranges. These operating systems, in >effect, use "stage three" clocks. No, you are confused. >Perhaps I miss your meaning here, too. The event of migrating a time >zone is a discontinuity just as with a leap second or leap hour. The discontinuity is not in the stage one timezone, but only in the governmental offset which defines stage two relative to stage one. We already have two of those discontinuitues a year most places and people and computers can live with them. People can live with them because they are big enough that you don't forget about them (for long). Computers can live with them because they use the stage-one timescale for representation. >> Denmark spans only a few hundred kilometers from east to west (not >> counting Greenland this time), yet sunrise and sunset varies about >> 30 minutes from one side to the other. > >This is true. It is irrelevant to the underlying international >clock. These are simply constant (if position dependent) offsets. >Big wup. I think this issue is confusing the discussion. No, they are actually very relevant because they show that you can't use a timescale as a vector component to locate extra terrestial objects without taking your longitude into account. >daylight saving time is irrelevant. No. >What matters is not when sunrise occurs, but rather that every day >has one (and only one). DST is very relevant, as it is a much more feasible mechanism for holding the sun high in the sky on the civil timescale. >> Conversion from stage two to stage one (and back) is perfect, > >Don't believe a detailed enough proposal is on the table to either >define the meaning of "perfect" in this context, or determine if the >notion being discussed meets the requirements for being so regarded. "I don't belive in science" ? For any timestamp on the civil timescale any spot on earth, there exist a mathematical formula which will convert that timestamp to UTC and vice versa. >> If Denmark or Elbonia decides to use a timezone which is offset >> from stage one by 1h3m21s, then it still works, > >Again, what is "it", precisely? Your own proposal. >stage one is atomic time (e.g., TAI) >stage two is international civil time (e.g., UTC) >stage three is local legal time (e.g., Mountain Standard Time) No. Now you try to change definitions under the discussion again. In your first email you defined it thusly: > Without further debating the meaning of "civil time", consider the > implications of this two stage system. The first stage conveys TAI > or something related to it by a constant offset. The second stage at > any location (correct me if I misunderstand you) would be a secondary > clock disseminated at the direction of the local authorities. In other words: (stage_zero is TAI) stage_one is TAI + constant stage_two is stage_one + governmental adjustment. >> In a couple of hundred years, the Danish Parliament (or its >> successor in interest) will simply decide "from -MM-DD HH:00, >> the Danish Civil time will use offsets -3h and -2h (instead of >> presently -1h/-2h) and the transition will happen on the switch >> from summertime to wintertime by _not_ adjusting the clock". > >The only way this differs from the leap hour proposal is that you are >assuming that different localities can (or would) carry these >adjustments out separately. I've never been in favour of the leap-hour proposal as other than a political instrument to be abandonned well before the clock strikes. And yes, I think you are likely to see far more governments fiddle with their respective civil time than scientists fiddle with UTC over the next 500 years, so I'm confortable leaving it to them. >A fall back event means that the clock (local, standard, >international, whatever clock you want) first traverses an hour - and >then traverses it again. No, that's what happens every year when switch from summer time to winter time. When the need to "reset" the civil timescale that event does _not_ happen. >This doesn't work because we're on the >wrong side of the pendulum's arc. The point being that you don't >need to *not* adjust the clock in the Autumn - you n
Re: interoperability
In message <[EMAIL PROTECTED]>, Tom Van Baak writes: >The danger, though, is that in the 60s maybe ten systems >were affected by leap seconds. In the 80s maybe a >thousand. Today, the number of systems affected (or is >it infected?) with leap second awareness is in the millions. > >I worry about this trend in the decades to come. I am >a fan of leap seconds as a weird and curious nuisance >but am not sure I like the idea that eventually my car, >traffic lights, airlines, television, and my thermostat will >have to be reliably tied to the IERS in order to function >properly. > >Don't forget the quartz wristwatch is only 40 years old. >What if cesium wristwatches show up 10 years from >now. What if some killer app 40 years hence requires >100 ms or 1 ms time accuracy. Do we still want UTC >leap seconds when it will infect ten billion devices? You mean like mobile phones and optical tele networks ? We have those today. >This is not an argument for change right now. But no >matter how you look at it the current scheme does not >scale well into the future; either a technological future >(way too many devices affected by unscheduled time >steps) or an astronomical future (way too many leap >seconds a year). Amen. -- 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: interoperability
Rob Seaman scripsit: > >Sure, and you can timestamp then on either timescale, because there > >is a 1 to 1 translation between the two timescales [1]. > > Perhaps I miss your meaning here, too. The event of migrating a time > zone is a discontinuity just as with a leap second or leap hour. Sure. But discontinuities in LCTs are something we already know how to handle. > This is true. It is irrelevant to the underlying international > clock. PHK and I are denying any need for an international clock that tracks Earth rotation. > What matters is not when sunrise occurs, but rather that every day > has one (and only one). This is like the "day is light and night is dark" statement: there is, at any given location, one and only one sunrise per (solar) day, no matter what clocks say. > Exactly. The pressures to maintain a common international vision of > time will trump local variations. It is the resulting common > international time clock that you won't let me refer to as "civil > time". All requirements placed on UTC flow backwards from here. You > can't just edit UTC (or GMT) out of the debate. What common international vision of time? There is no common international LCT. >stage one is atomic time (e.g., TAI) >stage two is international civil time (e.g., UTC) >stage three is local legal time (e.g., Mountain Standard Time) What we are looking for is to redefine stage three directly in terms of stage one without regard to a factitious stage two. > >In a couple of hundred years, the Danish Parliament (or its > >successor in interest) will simply decide "from -MM-DD HH:00, > >the Danish Civil time will use offsets -3h and -2h (instead of > >presently -1h/-2h) and the transition will happen on the switch > >from summertime to wintertime by _not_ adjusting the clock". > > The only way this differs from the leap hour proposal is that you are > assuming that different localities can (or would) carry these > adjustments out separately. Exactly! That is what the principle of subsidiarity demands, and it is a situation we already know how to handle. > A fall back event means that the clock (local, standard, > international, whatever clock you want) first traverses an hour - and > then traverses it again. Under the current three stage system it is > only the most local stage three clocks that are affected. You are, > in effect, promoting this discontinuity to stage two - to the > worldwide business timescale. More to the point, you have said that > stage one can be mapped back-and-forth to stage two. But we've just > shown that this is no longer a one-to-one mapping since the hour is > traversed twice, corresponding to two hours of TAI duration. You've redefined stage two in the course of this discussion. Before it meant LCT, now it means UTC. But be that as it may. Since we (PHK and I) are in favor of abolishing stage two, we are not promoting the discontinuity from stage three to stage two. Rather, we are interested in allowing the various local authorities to introduce changes into their stage three clocks *as they decide* to deal with any perceived problems. The "true leap hour" folks, if any, are actually doing what you say we are doing: creating a large discontinuity in stage two. The "fake leap hour" folks, if any, are actually doing what we want, but are cynically saying there will be a leap hour in stage two while not expecting such a thing to ever happen. > Ah! But you've suggested that the other half of the annual daylight > saving pendulum be used. This doesn't work because we're on the > wrong side of the pendulum's arc. The point being that you don't > need to *not* adjust the clock in the Autumn - you need to not adjust > the clock in the Spring. It is the springtime "gap" in the mapping > (also not a very desirable feature for a time scale) that is omitted > during one of these events - not the harvest-time doubly traversed hour. Fair enough. > (We'll omit discussion of the fact that not all localities observe > daylight saving time in the first place.) By all means. (This is the rhetorical figure of *praeteritio*.) > This is the same point I was trying to make about the 25 hour day. > No historian or lawyer is going to look favorably on a situation that > results in ambiguous timestamps. Perhaps, you say, such timestamps > should all be kept in TAI. But in that case, we are back to the > original question of why a stage two clock is needed at all. By > asserting stage two is needed, all the rest logically follows. And we assert that stage two is *not* needed. In any case, most of the world's population deals with ambiguous timestamps every year. As I've pointed out before, future times in legal documents are defined as LCT for a particular place, since the future mapping between LCT and any other time scale is not known. This turns out not to be a big problem, except for the makers of calendar programs. -- John Cowan ht
Re: interoperability
Poul-Henning Kamp scripsit: > Windows have got it right now I belive, but it used to be that a > file created and transmitted from Denmark at the end of the business > day would be older than a file created at the start of business day > in California, despite a strict ordering of the events. It's still true in the sense that the hardware clock is assumed to run in LCT on Windows, and therefore discovering UTC depends on a correctly set TZ variable. It's false in the sense that Windows now supports TZ correctly. > Sure, and you can timestamp then on either timescale, because there > is a 1 to 1 translation between the two timescales [1]. I think it's confusing to call it "1 to 1", except in the sense that LCT seconds are the same length as UTC/TAI seconds. There are many LCT timestamps that correspond to more than one UTC timestamp. This can be kludged around by adding a bit (the isdst field in a struct time) to say whether a LCT timestamp is the first or the second instance. > The scheme you propose is eminently workable, and more or less exactly > what we advocate. I'm happy that you now see the merits of it. Nope, he still doesn't. -- On the Semantic Web, it's too hard to prove John Cowan[EMAIL PROTECTED] you're not a dog. --Bill de hOra http://www.ccil.org/~cowan
Re: interoperability
In message <[EMAIL PROTECTED]>, Rob Seaman writes:
>As I pointed out close to five years ago, the ultimate long term
>remediation will likely involve redefining the length of the second:
Rob,
I think this shows how little you understand of the entire thing.
Several SI units are defined relative to the second these days and
therefore everybody involved in metrology have had nothing but
contempt for the notion of changing the second length.
To cut this part of the topic out in cardboard for you:
1. The Earths rotation and to a lesser degree its orbital motion
are lousy timekeeping devices, many orders of magnitude worse
than the best atomic frequency normals.
2. In metrology you use the best available method to implement a
fundamental unit.
But there is something else which bugs me.
Throughout all of these interminable discussions it has become
clear to me that you argue backwards from the end ("there must
be a UTC with leapseconds") rather than forward from the
beginning ("SI seconds are constant lengt").
In our most recent little exchange, you started out proposing a two
(or three) timescale solution without leap seconds, and then when
I showed that it worked out just the way we wanted, you started
to redefine the timescales so that one of them had to be UTC with
leapseconds.
You also keep harping about how day and night will switch places
without leapseconds, while at the same time dismissing the
governmentally defined local timezones as "irrelevant", despite the
fact that they do the heavy lifting (four orders of magnitude more
than leapseconds) of holding the sun high in the sky at noon.
In other words, you are not arguing in good fait and behave
more like a religious zealot than anything else.
That is deeply unserious behaviour of a scientist Rob.
Poul-Henning
--
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: interoperability
On Jan 9, 2006, at 12:03 AM, John Cowan wrote: Each locality decides when and how to adjust both its offset from TAI and its seasonal transition function (if any), just as it does today. Not just as today, see intervening messages. What we abandon is a universal time tightly synchronized to Earth rotation in favor of a universal time independent of earth rotation plus 400+ local civil times Perhaps some neutral party would like to officiate? Three questions: 1) Could this ever possibly work? (Please point out where my earlier dissection fails.) 2) For the sake of argument, imagine it could work. Would it be an improvement? 3) It suffers the same quadratic meltdown. Why change?
Re: interoperability
In message: <[EMAIL PROTECTED]> John Cowan <[EMAIL PROTECTED]> writes: : > But how in practice is it envisaged that a scheme : > for migrating time zones versus TAI would work, precisely? : : Straightforwardly. Each locality decides when and how to adjust both : its offset from TAI and its seasonal transition function (if any), : just as it does today. What we abandon is a universal time tightly : synchronized to Earth rotation in favor of a universal time : independent of earth rotation plus 400+ local civil times roughly : synchronized to Earth rotation containing various glitches. No matter what we do with leapseconds, there are still all those time zones. The problem with stopping leap seconds altogether is that the legal definitions of time, although quite varied, are all about the same as UTC as it exists today. They are close enough that most countries have adopted UTC bureaucratically rather than legislatively. The official time for the US, as published by the folks at NIST, is UTC. The US law says mean solar time, as determined by the Secretary of Commerce, who has delegated it to the Time and Frequency division of NIST, who in turn use UTC. NIST could easily use a different schedule for leap second insertion (it could have inserted the leap second in civilian time at the end of any day it wanted to and still maintained the mean solar time legal requirement). However, since UTC is a recognized, international standard, the US went along and did its leap second according to that standard. This is a explicit choice that someone, somewhere had to make, even though it is arguably the best choice to make (wouldn't want to be the odd man out in civil time, think of the impact on business). The combination of UTC approximating the legal time is so man nations, as well as the need for international consensus among lots of parties with divergent views for any changes to the current system is why we'll likely not see significant changes any time soon. The best we can hope for is that something will be done to change their unpredictable nature given that we have good forcasting tools at our disposal. Warner
Re: interoperability
On Sun, 8 Jan 2006, Tom Van Baak wrote: > between astronomical and atomic timescales. Could we rephrase that "between geophysical and atomic timescales" ? Astronomers measure it and have to compensate for it, not cause it. Reminds me bitterly of the widely reported loss of Mars Climate Orbiter being due to a confusion of metric and *english* units, like it was our fault. Pete.
