Re: Risks of change to UTC
Clive D.W. Feather scripsit: > Why not? Greek and Latin, to name two, were spoken that long ago and are > recognisable today. Indeed, and they passed through a far tighter bottleneck than anything likely today. Not even the most diligently destructive barbarian can extirpate the written word from a culture wherein the *minimum* edition of most books is fifteen hundred copies. There are simply too many books. --L. Sprague de Camp, _Lest Darkness Fall_ > And the English of 1000 years ago is still an official language of the > Netherlands (under the name "Frisian"). Bread, butter, and green cheese / Is good English and good Friese. Brea, bûter, en griene tsiis / Is goed Ingelsk en goed Frysk. (That û is u-circumflex, in case of encoding problems.) -- Long-short-short, long-short-short / Dactyls in dimeter, Verse form with choriambs / (Masculine rhyme): [EMAIL PROTECTED] One sentence (two stanzas) / Hexasyllabically http://www.reutershealth.com Challenges poets who / Don't have the time. --robison who's at texas dot net
Re: Risks of change to UTC
On Mon 2006-01-23T11:08:29 +, David Malone hath writ: > As far as I can see from my 1992 edition of the Explanatory Supplement > to the Astronomical Almanac, UT1 and GMST were (defined?) > the relationship seems to have been changed to ones documented in > (Capitaine et al., 2000, Capitaine et al., 2003, McCarthy and Petit, > 2004). They say that that "This relationship was developed to > maintain consistency with the previous defining relationship", but > I think this probably means that they were stitched together in a > smooth way, not that they are identical. The explanatory supplment is a place for revealed truth. The underlying process is only evident in the literature and reading between the lines of the reports of the triennial IAU General Assemblies. May I not so humbly suggest looking at http://www.ucolick.org/~sla/leapsecs/timescales.html for a slightly explained version with links to most of the papers and dates of changes. -- 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: Risks of change to UTC
M. Warner Losh said: > 1500 years ago, no one spoke English. Chances are the people that > deal with this problem in 1000 or 2000 years won't speak any language > recognizable to anybody alive today. Why not? Greek and Latin, to name two, were spoken that long ago and are recognisable today. And the English of 1000 years ago is still an official language of the Netherlands (under the name "Frisian"). -- 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: Risks of change to UTC
> Professional and amateur astronomers are not the only ones who need good > estimates of UT1. I've been wondering about this for a bit. Do astronomers and navigators actually want UT1 or do they want GMST? Since UT1 is based on a mean sun, which I guess no one actually observs, it would seem that GMST would be much more useful for figuring out your position or observing something. As far as I can see from my 1992 edition of the Explanatory Supplement to the Astronomical Almanac, UT1 and GMST were (defined?) to be related to one another by a cubic (2.24-1): GMST1 of 0hUT1 = 24110.54841s + 8640184.812877s T + 0.093104s T^2 + 0.062s T^3 What I don't know is: are the coefficients of this equation constant, or periodically updated by the IAU? Do astronomers, navigators and almanacs have to update their calculations when/if the IAU make a change? Why do I think they may change? Well, In older explanatory supplements to the IERS bulletins, such as this one: http://igscb.jpl.nasa.gov/mail/igsmail/1999/msg00077.html they give a reference for the relationship used as a paper by Aoki et al., 1982. However, in this more recent explanatory supplement: http://hpiers.obspm.fr/eoppc/bul/bulb/explanatory.html the relationship seems to have been changed to ones documented in (Capitaine et al., 2000, Capitaine et al., 2003, McCarthy and Petit, 2004). They say that that "This relationship was developed to maintain consistency with the previous defining relationship", but I think this probably means that they were stitched together in a smooth way, not that they are identical. If it is the case that the GMST/UT1 relationship is changed regularly and astronomers/navigators have to keep up with those changes, then leap seconds could be put into this relationship (amounting to moving the mean sun when needed). I'm guessing that this suggestion is only slightly less crazy than strapping rockets onto the Earth to speed up its rotation ;-) David.
Re: Risks of change to UTC
In message: <[EMAIL PROTECTED]> Mark Calabretta <[EMAIL PROTECTED]> writes: : On Sat 2006/01/21 10:11:04 PDT, "M. Warner Losh" wrote : in a message to: LEAPSECS@ROM.USNO.NAVY.MIL : : >You really should read the archives of this list. We've been over : >this in great detail. TAI is specifically contraindicated as a time : : I don't think new contributors (or even old ones) should have to read : the mountain of email, with its many irrelevant diversions, that has : accumulated over the last 6 years - somewhat over 9MB by my count. : : Instead, I (re-)suggest that you (someone) write a position paper, or : at least a FAQ, summarising your points. I agree. I was unreasonable in my demands. You are quite right. Warner
Re: Risks of change to UTC
On Sat 2006/01/21 15:15:32 PDT, "M. Warner Losh" wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL >Somewhere around betwee 45,000-80,000 you'll need more than one leap >second a day. You should recognize this as a reductio ad absurdum argument; at that time there will be 86401 SI seconds per day - the absurdity being in continuing to pretend that there are only 86400. If at that time the number of seconds per day is officially changed to 86401 then the millenia of accumulated quadratic drift will be wiped away at once and the rate of accumulation of leap seconds reset to zero. The next step is to ask - what if we increased the official length of the day before the situation gets so far out of hand, to 86400 plus some fraction of a second? Mark Calabretta ATNF
Re: Risks of change to UTC
On Sat 2006/01/21 10:11:04 PDT, "M. Warner Losh" wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL >You really should read the archives of this list. We've been over >this in great detail. TAI is specifically contraindicated as a time I don't think new contributors (or even old ones) should have to read the mountain of email, with its many irrelevant diversions, that has accumulated over the last 6 years - somewhat over 9MB by my count. Instead, I (re-)suggest that you (someone) write a position paper, or at least a FAQ, summarising your points. Mark Calabretta ATNF
Re: Risks of change to UTC
John Cowan <[EMAIL PROTECTED]> wrote: > Once we have accomplished the former [changing the basis of civil time], > I don't give a hoot about the latter [hobbling UTC]. > Keep UTC if you want. Then what are you doing here? Why don't you go to your elected representatives in whatever country you call yours and lobby them to pass a law changing the basis of civil time in your country from UTC to TAI-33s? I'm equally baffled by those people who keep trying to make ITU hobble UTC. Those people are from the US government, aren't they? Then if they are the US government, the all-powerful government that doesn't give a flying rat's ass about anybody but themselves, why do they bother with ITU, why don't they just pass a law changing the US legal time to TAI-05:00:33 on the East Coast, TAI-06:00:33 Central, etc. Surely the all-powerful government could do this any moment without asking anyone, certainly not the common citizens? MS
Re: Risks of change to UTC
"Daniel R. Tobias" wrote on 2006-01-21 19:30 UTC: > On 21 Jan 2006 at 10:11, M. Warner Losh wrote: > > I maintain that for human activity, there's no need for leap seconds > > at all. In each person's lifetime, the accumulated error is on the > > order of a few minutes. Over generations, the problems with noon > > drifting to 1pm can trivially be solved by moving the timezones that > > civilian time uses. > > What about when that accumulated difference is over 24 hours, so the > offset between solar-based time and atomic time is actually on the > order of days? Well, there is always the "Atomic Calendar" idea as one possible answer. I hope I will not lead this mailing list into an endless loop by pointing to the discussion we had here back in 2003 in an attempt to answer exactly this question, but I believe you may find this old thread particularly interesting: Unifying Atomic Time and the post-Gregorian calendar corrections http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00206.html Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Risks of change to UTC
Rob Seaman scripsit: > It would be the abandonment of leap seconds that would break UTC. > Lobbying to base civil time on some underlying timescale distinct > from UTC would be one thing. Conspiring to emasculate UTC is quite > another. Once we have accomplished the former, I don't give a hoot about the latter. Keep UTC if you want. -- John Cowan [EMAIL PROTECTED] www.reutershealth.com www.ccil.org/~cowan Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer."
Re: Risks of change to UTC
M. Warner Losh scripsit: > 1500 years ago, no one spoke English. Chances are the people that > deal with this problem in 1000 or 2000 years won't speak any language > recognizable to anybody alive today. Well, actually people did speak English in 500, as historical reconstruction makes clear, though we have no specimens of English that old. Certainly not 21st-century English, of course. Still, language drift unlike calendar drift is not inevitable, and nobody knows what effects, if any, the availability of sound recording will have on language change. -- The Imperials are decadent, 300 pound John Cowan <[EMAIL PROTECTED]> free-range chickens (except they have http://www.reutershealth.com teeth, arms instead of wings, and http://www.ccil.org/~cowan dinosaurlike tails).--Elyse Grasso
Re: distribute TAI as well (was Re: [LEAPSECS] Risks of change to UTC )
On Sun, Jan 22, 2006 at 12:13:38AM -0500, Tim Shepard wrote: > > TAI is specifically contraindicated as a time scale. > > and > > > TAI is not currently recommended by its creators as a viable time > > scale. > > I would love to know why. Right. These statements are in direct contradiction to the report of the CCTF in 1999. And as recently as last year, the United States Naval Observatory discussion of the options noted the benefits of using TAI. I've included references and excerpts below. -CCTF- http://www.intec.rug.ac.be/ursi/A_97-99.htm ... 7. THE 14th MEETING OF THE CCTF ( CONSULTATIVE COMMITTEE ON TIME AND FREQUENCY), BIPM, SEVRES, 20-22 APRIL, 1999 --- J. Steele An additional output was a circular letter from the Director, BIPM, emphasising the utility of TAI, as opposed to UTC, for systems requiring uniform time, i.e. free from the discontinuities arising from the application of leap seconds. ... There was no consensus within the CCTF for any proposal to change the definition of UTC. Instead, I was asked as Director of the BIPM to draw your attention and that of agencies developing satellite navigation systems, to the option of using TAI which is, of course an international uniform time scale. I remind you of the ITU Recommendation ITU-R 485-2 (1974-1982-1990) in which it is recommended that "time data should be issued wherever possible either with reference to Coordinated Universal Time (UTC) or to International Atomic Time (TAI)". It is clear that if the leap seconds of UTC cause problems in any particular application, the preferred alternative is TAI. The CCTF recommends, therefore, that in conformity with this ITU Recommendation developers of future satellite navigation systems and electronic communication systems should link their time scales to TAI as the only alternative to UTC and that, insofar as it is feasible, existing systems take steps to align their time scales with TAI. This is in conformity with the CCDS Recommendation S4 (1996) on the "coordination of satellite systems providing timing", in which it was recommended that "the reference times (modulo 1 second) of satellite navigation systems with global coverage by synchronized as closely as possible to UTC. To facilitate the direct use of TAI for satellite navigation systems, the time community is willing to take any steps that are necessary to make TAI easily accessible to users. UTC remains the basis for worldwide timekeeping, but TAI is recommended for those applications requiring uniform time. I urge you to take the necessary steps to inform your constituents of the characteristics of both UTC and TAI so that appropriate use may be made if these international scales. I enclose a few documents that may be of help in this respect. -USNO- UNITED STATES NAVAL OBSERVATORY Circular 179 2005 Oct 20 http://aa.usno.navy.mil/publications/docs/Circular_179.html For scientific instrumentation, the use of TAI which is free of leap seconds has much to recommend it. Its seconds can be easily synchronized to those of UTC (only the labels of the seconds are different). It is straightforward to convert from TAI to any of the other time scales. Use of TAI provides an internationally recognized time standard and avoids the need to establish an instrument-specific time scale when continuity of time tags is a requirement. > ... > I think we should stop arguing about what other people should use for > a time scale and simply distribute both TAI and UT. I believe both > kinds of time scales are needed. Some cases only need one kind, > other cases need only the other kind. So distribute both and be done > with it. Computers getting time over the net should make both kinds > of time available to programs. (Why not?) The issue comes down to what the "Civil" time standard is. If it is changed to a uniform scale like TAI, we will need broad worldwide consensus, and a lot of lead time. But regardless, we need to make TAI available more easily. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
distribute TAI as well (was Re: [LEAPSECS] Risks of change to UTC )
> TAI is specifically contraindicated as a time > scale. and > TAI is not currently recommended by its creators as a viable time > scale. I would love to know why. The only hint of a reason I've heard on this list to explain why would also seem to apply to UTC since UTC is defined in terms of TAI ticks. (IIRC the reason was that TAI is constructed after-the-fact from observations between the atomic clocks which are scattered at a number of different locations around the world, so you can only know what time it is TAI after the fact. Well, if that's the problem, then UTC is not any better.) I think we should stop arguing about what other people should use for a time scale and simply distribute both TAI and UT. I believe both kinds of time scales are needed. Some cases only need one kind, other cases need only the other kind. So distribute both and be done with it. Computers getting time over the net should make both kinds of time available to programs. (Why not?) If someone's best judgement is that one kind of timescale is for their purposes better than the other, then they will be free to exercise that judgement. This also avoids the issue of agreeing when to make "the change". UTC can continue to be distributed as it is. Improvements (e.g. to distribute TAI as well, continuously broadcast a complete table of historic and scheduled leap seconds, distribute a higher-precision DUT1, etc.) can be made incrementally without causing a semantic mess and without breaking any properly implemented existing systems. We could start down this road without delay. My hope is that proceeding down this path could make everyone happy. -Tim Shepard [EMAIL PROTECTED]
Re: Risks of change to UTC
On Jan 21, 2006, at 10:11 AM, M. Warner Losh wrote: Over generations, the problems with noon drifting to 1pm can trivially be solved by moving the timezones that civilian time uses. Neither trivial or a solution - quadratic disaster still looms. Keeping universal time synchronized to an arbitrary meridian is already arbitrary. The prime meridian is "conventional". It is not arbitrary, rather the choice was responsive to any number of political, social, historical, etc. issues. Implementing leap seconds in software is hard to get pedantically right "Pedantically right" is an interesting phrase. A software design is either right or it isn't. Even many ntp servers on the net got the leap second wrong And many got it right. The world did not end. astronomers and celestial navigators are being selfish Pointing out pedantic facts of nature is unremarkable behavior for either scientists or sailors. Whether we're also selfish is immaterial. Rob Seaman NOAO
Re: Risks of change to UTC
On 21 Jan 2006 at 15:15, M. Warner Losh wrote: > For some perspective, we've been using UTC for only ~50 years and the > gregorian calendar for only ~1500 years. I'd anticipate that > something would need to be done about the slowing of the day well > before 4300 years have passed. Actually, that's more like ~400 years for the Gregorian calendar (first instituted in 1582; adopted in different dates in different countries, as late as the 1920s in some). Its predecessor, the Julian calendar, goes back ~2000 years. -- == 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: Risks of change to UTC
On Jan 21, 2006, at 12:03 AM, M. Warner Losh wrote: WWV and most of the world's time stations broadcast DUT1. I should have added in my last message that some change in the signal format would be necessary if the range of DUT1 exceeds 0.9s. Bearing in mind that the ITU proposal would cease the reporting of DUT1. I will note that the profile of high precision time users has changed since 1972 when UTC was invented. [...] Should we continue to tie our time up in knots because of a tiny minority of users? Am fascinated by the failure of the precision timekeeping community to perceive six and a half billion souls as "users". Shouldn't choices related to international/civil/legal/business/historical time be based on their needs? No matter what the profile of high precision time users has become - it is that entire community who comprise a tiny minority. How many celestial navigators are there today? The Apollo astronauts relied on navigation by sextant - celestial indeed. One expects that future solar system explorers will carefully continue to carry such fundamental instrumentation - certainly for emergencies (think Shackleton, not just Magellan), but also perhaps as an agile and reliable primary resource in their toolkits. Am not arguing that this has a direct connection to the matter at hand - but rather that old doesn't mean obsolete. Over the next 50 years, these two watches will be well within the tolerance of most normal watches. This interpretation confuses systematic effects (monotonically diverging timescales) with random errors. Much (one is tempted to say, "all") experimental science depends on abstracting trends from noisy data. No matter how large a tolerance one allows, the diverging meanings of "clock" will eventually exceed it. The approximation of civil time will be less than one minute off during that time A useful approximation captures asymptotic or otherwise limiting behavior. Where there is no limit, there may be an agreement to draw a line in the sand - but there can be no approximation. Einstein isn't right and Newton wrong, rather Newton's laws are correct in the limit - the everyday limit. "High precision time users" may well place stringent requirements on fundamental timescales. But civil time requires a common sense everyday compromise. What this entire "début de siecle" discussion has been about is whether ignoring the whole question for a few hundred years is more common sensical than continuing to issue occasional small corrections. If this is a real issue, the market will take over and produce watches that have 'navigation time' and 'civilian time' at the touch of a button The market has not proven itself creative in meeting highly technical needs. Time and again, the market has converged on significantly less than ideal solutions - Windows, VHS, internal combustion. If the "magic hand of the market" is the first law (conservation of energy) of modern economic theory, the second law (entropy) is the "tragedy of the commons". Timekeeping is pervasive in our society, but often invisible. As with the grand environmental challenges confronting this natal century, market forces threaten to provide - oh so efficiently provide - the wrong answers to timekeeping questions. Of course, purely mechanical watches have other issues when used on a boat. And yet Harrison found a way around these when he invented the first chronometers - for the express purpose of being used on ships. Stating absolutely that UTC is not broken ignores these other users. UTC is not broken. We may agree or disagree on whether it meets various civil or technical timekeeping requirements - but "broken" would imply that it fails to meet its *own* requirements. UTC is eminently capable of continuing unchanged for many centuries - and for millennia more with only slight changes. After that, nothing yet proposed (except for those danged rubber seconds) is any better (see http://iraf.noao.edu/~seaman/leap). It would be the abandonment of leap seconds that would break UTC. Lobbying to base civil time on some underlying timescale distinct from UTC would be one thing. Conspiring to emasculate UTC is quite another. GLASNOS is a backup system to GPS that is not subject to DoD's selective denial of signal. Glasnost was Mikhail Gorbachev's policy of encouraging open public debate, particularly in support of "perestroika" - restructuring - of the Soviet economy. On the other hand, GLONASS is the Russian Global Navigation Satelllite System :-) In any event, one suspects that the Russians (or the FSU, even more so) would object to its being characterized as a GPS backup. Rob Seaman NOAO
Re: Risks of change to UTC
On Jan 20, 2006, at 10:17 PM, M. Warner Losh wrote: Any watch that is smart enough to decode those signals would be smart enough to add this minor correction as well. A viable time scale could be constructed from any periodic (or "near" periodic) waveform - there's nothing magic about the tick, tick, tick of delta functions (or step functions if you prefer to think of it that way). A viable watch could present a different representation - 12 hour/24 hour, sexigesimal/decimal, local/"universal" - every time it is consulted. It wouldn't even have to be monotonic, as long as enough "temporal metadata" is provided for context. That metadata (such as DUT1 and DTAI) could be provided in as circuitous and obscure a fashion as can be imagined - encrypted, proprietary, steganographically. Heck - time signals might even arrive as little blips on shortwave radio - as hard as that might be to believe. There's viable - and then there's viable... The mechanical watch might be a bit of a problem, but DUT1 doesn't change enough to introduce navigation errors similar to what we have today over the course of a year and can easily be looked up like someone would lookup what the weather was going to be like. ...and we're back to the confusion between periodic and secular effects. There seems to be some thought that mean solar time is nothing but a polite (or lately, sometimes impolite) fiction. Greenwich Mean Time is real enough to have built the British Empire. You're also working both sides of the equation. A navigator observes local apparent solar time onboard and compares it to GMT (or mean time on any other known meridian) transported via chronometer. DUT1 is a mechanism to correct mean solar time as reported by the clock. The equation of time, on the other hand, is used to convert shipboard apparent time to local mean time. Subtraction does the rest. Rob Seaman NOAO
Re: Risks of change to UTC
In message: <[EMAIL PROTECTED]> "Daniel R. Tobias" <[EMAIL PROTECTED]> writes: : On 21 Jan 2006 at 10:11, M. Warner Losh wrote: : : > I maintain that for human activity, there's no need for leap seconds : > at all. In each person's lifetime, the accumulated error is on the : > order of a few minutes. Over generations, the problems with noon : > drifting to 1pm can trivially be solved by moving the timezones that : > civilian time uses. : : What about when that accumulated difference is over 24 hours, so the : offset between solar-based time and atomic time is actually on the : order of days? >From http://www.ucolick.org/~sla/leapsecs/dutc.html we know that the rate of change of the day is somewhere between 25.6 s/century^2 and 42 s/century^2. At those rates, it will be the year 6360-7633 when enough time has accumulated for there to be a day difference. Before then, however, we go through a number of events. Somewhere between 2058 and 2211, enter the realm where there's more than 2 leap seconds per year. This will be the first great UTC breakage because many devices today (ntp included) KNOW that leap seconds happen twice yearly. The next break will happen sometime between 2300 and 2600 when we'll need more than 4 leap seconds a year. The current ITU-R TG.460 standard for leap seconds defines only primary and secondary leap second times. It does not define tertiary, so no one knows when the leap seconds will happen if you need more than 4 per year, but the ITU recommendation is that they happen at the end of a month. Somewhere between 3250 and 4200 there will be more than 1 leap second a month needed. At this point the ITU scheme of having the leap second at the end of the month will need to be modified. That's at least 2000 years before 24 hours of delta have accumulated. For some perspective, we've been using UTC for only ~50 years and the gregorian calendar for only ~1500 years. I'd anticipate that something would need to be done about the slowing of the day well before 4300 years have passed. Somewhere around betwee 45,000-80,000 you'll need more than one leap second a day. : Will people be able to deal with a civil time : standard that is based on an offset from a "UTC" that says it's : Monday when all actual points on Earth have the local date at : Saturday or Sunday? Since that's 4k or more years into the future, who alive today will know enough about what the future is like to impose a scheme that is guranteed to work? Clearly some scheme better than leap seconds will need to be invented well in advance of these events. A new scheme will be needed well in advance of the Tuesday is really Wednesday problem. : Many Web sites (including Wikipedia) use UTC as : the standard for date/timestamps; will this be a reasonable thing : when this causes the date of postings to be far off from what is : being used locally? And when, at some future point, the Gregorian : calendar itself needs adjustment to handle the fact that it doesn't : get the length of the year precisely correctly (and the length of the : year in terms of solar days is changing due to the lengthening of the : day, anyway), will this adjustment be done to the UTC standard (why, : when it doesn't follow astronomy anyway?), or as an additional offset : to local times (which could result in different countries having : different dates as in the Julian/Gregorian transition period)? The length of the gregorian calendar is off by 23s per year. In year 5500 or so we'll have accumulated a day of error in it and we'll need to skip a leap year to correct for that problem. This is a good 2000 years before we'll have accumulated a day of DUT. As you can see from the above, leap seconds won't save you. They will run out of steap in about 1500 to 2500 years. At that point the accumulated difference will be only about 2 hours. If leap seconds are totally abolished, time zone transitions could easily continue for about 4000 years. Either way, you have a problem. The length of the SI second is fixed, and the length of the day is getting shorter. 1500 years ago, no one spoke English. Chances are the people that deal with this problem in 1000 or 2000 years won't speak any language recognizable to anybody alive today. Warner
Re: Risks of change to UTC
On 21 Jan 2006 at 10:11, M. Warner Losh wrote: > I maintain that for human activity, there's no need for leap seconds > at all. In each person's lifetime, the accumulated error is on the > order of a few minutes. Over generations, the problems with noon > drifting to 1pm can trivially be solved by moving the timezones that > civilian time uses. What about when that accumulated difference is over 24 hours, so the offset between solar-based time and atomic time is actually on the order of days? Will people be able to deal with a civil time standard that is based on an offset from a "UTC" that says it's Monday when all actual points on Earth have the local date at Saturday or Sunday? Many Web sites (including Wikipedia) use UTC as the standard for date/timestamps; will this be a reasonable thing when this causes the date of postings to be far off from what is being used locally? And when, at some future point, the Gregorian calendar itself needs adjustment to handle the fact that it doesn't get the length of the year precisely correctly (and the length of the year in terms of solar days is changing due to the lengthening of the day, anyway), will this adjustment be done to the UTC standard (why, when it doesn't follow astronomy anyway?), or as an additional offset to local times (which could result in different countries having different dates as in the Julian/Gregorian transition period)? -- == 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: Risks of change to UTC
In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : > UTC works for navigation, but leap seconds pose problems for other : > users of time. Stating absolutely that UTC is not broken ignores : > these other users. : : Those "other uses," for whom leap seconds pose a problem, should be : using a time scale that does not have leap seconds. They would be better : served, for example, by TAI. You really should read the archives of this list. We've been over this in great detail. TAI is specifically contraindicated as a time scale. This also ignores the issues surrounding the proper computation of elapsed time using the UTC time scale when represnted by a number. It ignores the fact that you must have a table of leap seconds to do this effectively. It ignores that one must have a table of leap seconds to get TAI time, because most providers of time provide it in UTC. : For civil use, a calendar that counts days reaonably accurately is : appropriate. The Gregorian (New Style calendar) that the vast : majority of the planetary population uses does this. UTC copes with : the variable length of the mean solar day by inserting leap seconds : as needed. The role of the IERS in decreeing when leap seconds are : needed is similar to that of the Roman College of Pontifices who managed : the old Roman Republican calendar (before Julius Caesar's reform) by : decreeing, as needed, when to shorten the month of February and insert : the intercalary month of Mercurius. I maintain that for human activity, there's no need for leap seconds at all. In each person's lifetime, the accumulated error is on the order of a few minutes. Over generations, the problems with noon drifting to 1pm can trivially be solved by moving the timezones that civilian time uses. Keeping universal time synchronized to an arbitrary meridian is already arbitrary. Adding leap seconds is an arbitrary decision to implement that arbitrary requirement. It is really only important for those uses of time that care what the local solar time is to within a second (as opposed to within an hour which everyone in civil society is used to since the late 19th century and time zones). : If your primary need is for a time scale ithat counts SI seconds, with : no leap seconds to confuse the matter, then don't use UTC. Use a time : scale that counts SI seconds, such as TAI or GPS time. There's no point : to applying the mised radix Gregorian calendar system to such a time : scale, although you can do so if you wish. Count days of 86 400 SI : seconds each, or GPS weeks of 604 800 SI seconds, or just count SI seconds. : : If, on the other hand, you need to count solar days, or mean solar days, : use a calendar and time scale that does so. In order to know which way : the earth is pointing, use UT1, or a compromise scale such as UTC that : is kept reasonably close to UT1. For the vast majority of the : population of the planet, including celestial navigators, UTC is good : enough. If you want to know the direction the earth is pointing with : more precision, apply DUT1 corrections, or use other IERS products such : as Bulletin A. That is one solution to the problem, but it is not the only solution to the problem. Quoting the old, tired saws about using TAI or GPS time scales to count SI seconds doesn't promote good dialog. Instead, it drags this discussion down to the level of Dogma. There are many users that need to both count SI seconds, as well as synchronize their operations to civilian time. Leap seconds cause these users real difficulties. Implementing leap seconds in software is hard to get pedantically right (I have a pile of bugs in code that was written by smart people that get leap seconds wrong, and over 200 hours of time spent in the past few years on implement, testing and debugging leap seconds). Even many ntp servers on the net got the leap second wrong, as did many of the time stations. There's much evidence that this "solution" to the problem has shifted the cost of keeping astronomers, celestial navigators, and others with a real need to the solar time happy to a large number of other users who have no such real need. As such, it seems only fair in today's economy to place the costs of the needs of a community on those communities that have a real need for those goods or services. : There is no need to "fix" the time scale, UTC, that is used by the vast : majority of the planet's population to accommodate the very small : minority of precision time users who desire a time scale that has no : leap seconds. Let that minority use a time scale, such as TAI, that does : not have those messy leap seconds. TAI is not currently recommended by its creators as a viable time scale. In my day job, we do use TAI internally. That doesn't solve the problems of leap seconds. It doesn't solve the problem of products that need to participate in leap seconds (say irig generators or
Re: Risks of change to UTC
M. Warner Losh wrote: UTC works for navigation, but leap seconds pose problems for other users of time. Stating absolutely that UTC is not broken ignores these other users. Those "other uses," for whom leap seconds pose a problem, should be using a time scale that does not have leap seconds. They would be better served, for example, by TAI. UTC, with its leap seconds, evinces the fundamental problem that calendar designers have faced through the ages: trying to devise a compromise system that blends mutually incommensurable units. For civil use, a calendar that counts days reaonably accurately is appropriate. The Gregorian (New Style calendar) that the vast majority of the planetary population uses does this. UTC copes with the variable length of the mean solar day by inserting leap seconds as needed. The role of the IERS in decreeing when leap seconds are needed is similar to that of the Roman College of Pontifices who managed the old Roman Republican calendar (before Julius Caesar's reform) by decreeing, as needed, when to shorten the month of February and insert the intercalary month of Mercurius. Since we human creatures synch our cicadian rhythms and our daily activities to periods of light and darkness, the day is a natural unit of time for use in our calendars. Indeed, I know of no calendric system that does not count days. Unfortunately, the day is ncommensurate with the SI second, and the length of the day is changing. If your primary need is for a time scale ithat counts SI seconds, with no leap seconds to confuse the matter, then don't use UTC. Use a time scale that counts SI seconds, such as TAI or GPS time. There's no point to applying the mised radix Gregorian calendar system to such a time scale, although you can do so if you wish. Count days of 86 400 SI seconds each, or GPS weeks of 604 800 SI seconds, or just count SI seconds. If, on the other hand, you need to count solar days, or mean solar days, use a calendar and time scale that does so. In order to know which way the earth is pointing, use UT1, or a compromise scale such as UTC that is kept reasonably close to UT1. For the vast majority of the population of the planet, including celestial navigators, UTC is good enough. If you want to know the direction the earth is pointing with more precision, apply DUT1 corrections, or use other IERS products such as Bulletin A. There is no need to "fix" the time scale, UTC, that is used by the vast majority of the planet's population to accommodate the very small minority of precision time users who desire a time scale that has no leap seconds. Let that minority use a time scale, such as TAI, that does not have those messy leap seconds. -- James Maynard Salem, Oregon, USA
Re: Risks of change to UTC
In message: <[EMAIL PROTECTED]> "Brian Garrett" <[EMAIL PROTECTED]> writes: : > But the protocol for broadcasting DUT1 in, e.g., WWV, does not provide : > for DUT1 values of more than plus or minus 0.9 s. The value of DUT1 : > could be announced by voice message -- but that would not be : > language-independent. If I travel to asia in my boat, I will not be : > able to benefit from DUT1 announcemnts in Japanese from JJY or in : > Chinese from BPM (or whatever their standard time and frequency station : > is). An longwave broadcasts such as those from WWVB do not have voice : > modulation at all! : > : WWVB broadcasts the DUT1 correction in binary-coded decimal form, and is : capable of representing DUT1 values up to +/- 1.5 seconds with their current : format. I would think other longwave stations do the same, but not knowing : their particular BCD format I couldn't say what DUT1 values they are capable : of representing. Taking a long term view, some changes in the broadcast format or interpratation would be necessary. It is quite possible to multiplex these bits so that successive opportunities to transmit the DUT1 encode additional digits as well. This would mean it would take a while to transmit DUT1, but such operational issues have been deemed acceptable in systems such as GPS which transmit leap second information only a few times an hour. There appears to be about 13 unused bits in the WWV stream http://tf.nist.gov/timefreq/stations/wwvtimecode.htm at second 8, 14, 24, 27, 28, 34, 42, 43, 44, 45, 46, 47, and 48. Granted, some of these are spacer bits between BCD digits, but they could be reclaimed. The WWVB timecode http://tf.nist.gov/timefreq/stations/wwvbtimecode.htm has fewer free bits at 9: 5, 11, 14, 21, 24, 34, 35, 44, and 54. 10 if you count the redundant sign bit. With enough advance notice, these bits could be used to encode larger DUT1 values. If you travel to asia, you will no doubt know what DUT1 is to within a second before you leave the US. The rate of DUT1 change is on the order of 1s per year. This should obviate the need to be told the current DUT1 value every minute. Even the DUT1 values broadcast to the .1s level only change monthly or so (although there are provisions to change them with only 2 weeks notice). I have no delusions that changing the meaning of the bits in the time codes braodcast from WWV and WWVB will happen in less than a decade... Warner
Re: Risks of change to UTC
In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : : > : > If DUT1 is broadcast, then one can set the time keeping device to UT1 : > : > by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s : > : > with a similar accuacy (or better). There's nothing that says a watch : > : > has to display UTC to be set correctly. WWV and most of the world's time stations broadcast DUT1. I should have added in my last message that some change in the signal format would be necessary if the range of DUT1 exceeds 0.9s. Given a sufficently long time horizon, this becomes a non-issue. : You seem to expect celestial navigators to become more sophisticated in : these matters of time scales than is presently the case. It would be far : better, in my option, not to tinker with the definition of UTC and of : civil time at all, but leave civil time zones tied approximately to UT1. Maybe that is a reasonable expectation. Maybe it is not. I will note that the profile of high precision time users has changed since 1972 when UTC was invented. In 1972 celestial navigators were a big part of the users of time. These days, they represent a much smaller portion of that audience. If there are changes to how time is provided, then all users of precision time should be considered. Should we continue to tie our time up in knots because of a tiny minority of users? Maybe the answer that question is yes. Maybe it is no. However, stating absoultely, unquestionably that it is one or the other is what is wrong and what takes this discussion off into the weeds. How many celestial navigators are there today? : "There's nothing that says a watch has to display UTC to be set : correctly." But then the user would have to carry two watches, one set : to an approximation of UT1 (e.g., UTC + DUT1) and another set to civil : time (TI, or local zone time, or whatever). For simpler, it would be, : with far less impact on ordinary users of time, not to let UTC (or its : replacement) differ from UT1 by more than the present +/- 0.9 s. Over the next 50 years, these two watches will be well within the tolerance of most normal watches. The approximation of civil time will be less than one minute off during that time (if most of the projections are to be believed). If this is a real issue, the market will take over and produce watches that have 'navigation time' and 'civilian time' at the touch of a button. If you still desire to use older, purely mechanical watches, then you must take extra steps, like knowing the current offset between civil time and navigation time. Of course, purely mechanical watches have other issues when used on a boat. Electro-mechanical ones don't suffer those problems, but require some power source. The foregoing assumes, for the sake of argument, that DUT1 becomes unbounded. : UTC is not broken. There is no need to "fix" it. UTC works for navigation, but leap seconds pose problems for other users of time. Stating absolutely that UTC is not broken ignores these other users. : > I'd also add that GPS receivers today already do exactly this sort of : > correction when they decode the GPS time, but display the UTC time. : : True. But GPS receivers are electrically powered, and are not a fallback : for the case when a boat's electrical systems fail. Nor are they a : backup system for the case when the the boater is in proximity to a : war zone where the U.S. DoD is jamming or degrading the civil SPS GPS : service. GLASNOS is a backup system to GPS that is not subject to DoD's selective denial of signal. Soon, Galileo will provide additional backup. Also, there's about a dozen time stations worldwide that provide time signals today which can act as backup to GPS during a GPS outage. I pointed out GPS more as an example of a 'clock that gets it times in one timescale, but displays it in another' rather than as a backup time source for your example mariner. Warner
Re: Risks of change to UTC
- Original Message - From: "James Maynard" <[EMAIL PROTECTED]> To: Sent: Friday, January 20, 2006 9:33 PM Subject: Re: [LEAPSECS] Risks of change to UTC > M. Warner Losh wrote: > > In message: <[EMAIL PROTECTED]> > > James Maynard <[EMAIL PROTECTED]> writes: > > : M. Warner Losh wrote: > > : > In message: <[EMAIL PROTECTED]> > > : > James Maynard <[EMAIL PROTECTED]> writes: > > : > : ones position using sight reduction tables. Today a mechanical watch or > > : > : chronometer, or a battery-powered wristwatch, can be set to UTC using > > : > : radio time signals. Then when power fails, the sailor still has a > > : > : reasonably accurate spprodximation to UT1 available. > > : > > > : > If DUT1 is broadcast, then one can set the time keeping device to UT1 > > : > by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s > > : > with a similar accuacy (or better). There's nothing that says a watch > > : > has to display UTC to be set correctly. > > : > > > : > Warner > > : > > > : > . > > : > > > : And how is DUT1 to be broadcast in a language-independent manner? That > > : protocol needs to be established well in advance. > > > > It already is being broadcast in, eg, WWV. > > > > Warner > > > > > > > But the protocol for broadcasting DUT1 in, e.g., WWV, does not provide > for DUT1 values of more than plus or minus 0.9 s. The value of DUT1 > could be announced by voice message -- but that would not be > language-independent. If I travel to asia in my boat, I will not be > able to benefit from DUT1 announcemnts in Japanese from JJY or in > Chinese from BPM (or whatever their standard time and frequency station > is). An longwave broadcasts such as those from WWVB do not have voice > modulation at all! > WWVB broadcasts the DUT1 correction in binary-coded decimal form, and is capable of representing DUT1 values up to +/- 1.5 seconds with their current format. I would think other longwave stations do the same, but not knowing their particular BCD format I couldn't say what DUT1 values they are capable of representing. Brian Garrett
Re: Risks of change to UTC
M. Warner Losh wrote: : > If DUT1 is broadcast, then one can set the time keeping device to UT1 : > by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s : > with a similar accuacy (or better). There's nothing that says a watch : > has to display UTC to be set correctly. You seem to expect celestial navigators to become more sophisticated in these matters of time scales than is presently the case. It would be far better, in my option, not to tinker with the definition of UTC and of civil time at all, but leave civil time zones tied approximately to UT1. "There's nothing that says a watch has to display UTC to be set correctly." But then the user would have to carry two watches, one set to an approximation of UT1 (e.g., UTC + DUT1) and another set to civil time (TI, or local zone time, or whatever). For simpler, it would be, with far less impact on ordinary users of time, not to let UTC (or its replacement) differ from UT1 by more than the present +/- 0.9 s. UTC is not broken. There is no need to "fix" it. I'd also add that GPS receivers today already do exactly this sort of correction when they decode the GPS time, but display the UTC time. True. But GPS receivers are electrically powered, and are not a fallback for the case when a boat's electrical systems fail. Nor are they a backup system for the case when the the boater is in proximity to a war zone where the U.S. DoD is jamming or degrading the civil SPS GPS service. -- James Maynard Salem, Oregon, USA
Re: Risks of change to UTC
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > James Maynard <[EMAIL PROTECTED]> writes: : > : ones position using sight reduction tables. Today a mechanical watch or : > : chronometer, or a battery-powered wristwatch, can be set to UTC using : > : radio time signals. Then when power fails, the sailor still has a : > : reasonably accurate spprodximation to UT1 available. : > : > If DUT1 is broadcast, then one can set the time keeping device to UT1 : > by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s : > with a similar accuacy (or better). There's nothing that says a watch : > has to display UTC to be set correctly. : > : > Warner : > : > . : > : And how is DUT1 to be broadcast in a language-independent manner? That : protocol needs to be established well in advance. It already is being broadcast in, eg, WWV. Warner But the protocol for broadcasting DUT1 in, e.g., WWV, does not provide for DUT1 values of more than plus or minus 0.9 s. The value of DUT1 could be announced by voice message -- but that would not be language-independent. If I travel to asia in my boat, I will not be able to benefit from DUT1 announcemnts in Japanese from JJY or in Chinese from BPM (or whatever their standard time and frequency station is). An longwave broadcasts such as those from WWVB do not have voice modulation at all! -- James Maynard Salem, Oregon, USA
Re: Risks of change to UTC
In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > James Maynard <[EMAIL PROTECTED]> writes: : > : ones position using sight reduction tables. Today a mechanical watch or : > : chronometer, or a battery-powered wristwatch, can be set to UTC using : > : radio time signals. Then when power fails, the sailor still has a : > : reasonably accurate spprodximation to UT1 available. : > : > If DUT1 is broadcast, then one can set the time keeping device to UT1 : > by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s : > with a similar accuacy (or better). There's nothing that says a watch : > has to display UTC to be set correctly. : > : > Warner : > : > . : > : And how is DUT1 to be broadcast in a language-independent manner? That : protocol needs to be established well in advance. I should add that I read your 'can be set to utc using radio time signals' to mean something like WWV or other radio time service. Those sevices do already broadcast DUT1. Any watch that is smart enough to decode those signals would be smart enough to add this minor correction as well. The mechanical watch might be a bit of a problem, but DUT1 doesn't change enough to introduce navigation errors similar to what we have today over the course of a year and can easily be looked up like someone would lookup what the weather was going to be like. I'd also add that GPS receivers today already do exactly this sort of correction when they decode the GPS time, but display the UTC time. Warner
Re: Risks of change to UTC
In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > James Maynard <[EMAIL PROTECTED]> writes: : > : ones position using sight reduction tables. Today a mechanical watch or : > : chronometer, or a battery-powered wristwatch, can be set to UTC using : > : radio time signals. Then when power fails, the sailor still has a : > : reasonably accurate spprodximation to UT1 available. : > : > If DUT1 is broadcast, then one can set the time keeping device to UT1 : > by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s : > with a similar accuacy (or better). There's nothing that says a watch : > has to display UTC to be set correctly. : > : > Warner : > : > . : > : And how is DUT1 to be broadcast in a language-independent manner? That : protocol needs to be established well in advance. It already is being broadcast in, eg, WWV. Warner
Re: Risks of change to UTC
James Maynard scripsit: > Small boats, sea water, and electrical systems don't mix very well. The > damp, salty environment all too often leads to failures of a boat's > electrical system. A prudent sailor should not rely for navigation only > on electrically powered systems like GPS or loran. Your points are excellent, although it seems to me that a wind-up GPS receiver is a possibility. > But if UTC is allowed to drift away from UT1 by eliminating leap > seconds, celestial navigation fixes will become less and less useful. A > time error of half an hour in UT1 equates about to 450 NM at the equator. Navigators are clearly people who would need access to |TI-UT1| along with astronomers, yes. -- John Cowan www.ccil.org/~cowan www.reutershealth.com [EMAIL PROTECTED] Mr. Henry James writes fiction as if it were a painful duty. --Oscar Wilde
Re: Risks of change to UTC
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : ones position using sight reduction tables. Today a mechanical watch or : chronometer, or a battery-powered wristwatch, can be set to UTC using : radio time signals. Then when power fails, the sailor still has a : reasonably accurate spprodximation to UT1 available. If DUT1 is broadcast, then one can set the time keeping device to UT1 by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s with a similar accuacy (or better). There's nothing that says a watch has to display UTC to be set correctly. Warner . And how is DUT1 to be broadcast in a language-independent manner? That protocol needs to be established well in advance. -- James Maynard Salem, Oregon, USA
Re: Risks of change to UTC
Neal McBurnett scripsit: > To sum it up, PLEASE don't fundamentally change the DEFINITION of UTC, > or you risk whole new kinds of confusion. Hopefully by now the folks > on this list that don't like leap seconds at least have agreed that > any change should be to a new time scale like TI, and announced > decades in advance. I certainly do, and I hope everyone else who is down-leaps does too. TI is a good name (you can read it as "TAI - A" where A is a constant to be decided when the scale is inaugurated). -- John Cowan www.ccil.org/~cowan www.reutershealth.com [EMAIL PROTECTED] [T]here is a Darwinian explanation for the refusal to accept Darwin. Given the very pessimistic conclusions about moral purpose to which his theory drives us, and given the importance of a sense of moral purpose in helping us cope with life, a refusal to believe Darwin's theory may have important survival value. --Ian Johnston
Re: Risks of change to UTC
In message: <[EMAIL PROTECTED]> James Maynard <[EMAIL PROTECTED]> writes: : ones position using sight reduction tables. Today a mechanical watch or : chronometer, or a battery-powered wristwatch, can be set to UTC using : radio time signals. Then when power fails, the sailor still has a : reasonably accurate spprodximation to UT1 available. If DUT1 is broadcast, then one can set the time keeping device to UT1 by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s with a similar accuacy (or better). There's nothing that says a watch has to display UTC to be set correctly. Warner
Re: Risks of change to UTC
In reply to Rob Seaman, John Cowan wrote: Seaman: >> [A]s clock time diverges further and further from solar time, more systems in more communities (transportation, GIS, innumerable scientific disciplines, what have you) would be revealed to need remediation. Cowan: Can you spell out some of those implications? Professional and amateur astronomers are not the only ones who need good estimates of UT1. A far more safety-related issue comes from the continuing need for celestial navigation as a backup for electrically powered navigation devices. Small boats, sea water, and electrical systems don't mix very well. The damp, salty environment all too often leads to failures of a boat's electrical system. A prudent sailor should not rely for navigation only on electrically powered systems like GPS or loran. It is still prudent to cultivate the skill of taking sights with a sextant and calculating ones position using sight reduction tables. Today a mechanical watch or chronometer, or a battery-powered wristwatch, can be set to UTC using radio time signals. Then when power fails, the sailor still has a reasonably accurate spprodximation to UT1 available. As long as one's timepiece is set to within 1 s of UT1, the error in longitude due to chronometer error will be less than 30 seconds of arc -- at the equator, an east-west error of half a nautical mile. If DUT1 is known to a resolution of 0.1 s (by counting the "double ticks" from time and frequency stations such as WWV and WWVH), the error in longitude due to chronometer error can be reduced to 3 seconds of arc: an error of 1/20 NM at the equator. But if UTC is allowed to drift away from UT1 by eliminating leap seconds, celestial navigation fixes will become less and less useful. A time error of half an hour in UT1 equates about to 450 NM at the equator. Celestial navigation was the "raison d'etre" for GMT, and it is still a useful skill. But celestial navigation depends on knowlege of UT1. The further civil time and UTC are allowed to drift away from UT1, the more impact there will be on safety of life at sea. -- James Maynard Salem, Oregon, USA
Re: Risks of change to UTC
In message: <[EMAIL PROTECTED]> Neal McBurnett <[EMAIL PROTECTED]> writes: : These astronomical and navigation systems currently get inputs of time : from all sorts of other systems and people: other instruments, other : computers, sub-contractors, etc. Changing the meaning of UTC would : lead to a cascade of systems that changed their own timescales and : I/O formats, meaning that auditing the flow of time data between them : would get more and more complex for a long time. The changing formats should indeed be phased in. First, changes to the data streams so that they can represent DUT1 > 0.9s. Next, fix everything that breaks... Repeat. You're likely right, this will take a long long time :-(. Warner
Re: Risks of change to UTC
On Fri, Jan 20, 2006 at 03:12:15PM -0500, John Cowan wrote: > Rob Seaman scripsit: > > Only a minority (small minority, one would think) of > > systems currently include any DUT1 correction at all - although these > > will perhaps tend to be the most safety-critical applications. [...] > > > > That is, of course, one of the major issues for astronomers - we rely > > on UTC providing a 0.9s approximation to UT1 and most of our systems > > don't use DUT1. Even our high precision applications (in either > > interval or universal time) don't tend to require conversions other > > than as a preprocessing step. Remediating our systems for such a > > fundamental change to UTC would involve much larger changes than Y2K > > did - algorithms and data structures would have to change, not just > > the width of some string fields and sprinkling some 1900's around. > > I don't understand this. The first class of applications, those > that actually receive DUT1 from somewhere, probably have a hard-coded > assumption that |DUT1| never exceeds 0.9s or at worst 1.0s. They would > need remediation. The second class, which just assumes UTC = UT1 > and doesn't care about subsecond precision, would simply need to be > front-ended with a routine that got DUT1 from somewhere and mixed it > with TI to generate their own UT1. This is technically remediation, > but of a rather black-box kind. I don't do this professionally, but here is my guess, and an attempt at an analogy. Hopefully the pros will correct me if I'm wrong. Imagine if someone changed the definition of the meter so that it changed over time How would you modify your systems to make sure that all your units were consistent - that some contractor didn't foul it up, and give you the wrong measurement, subtly or catastrophically changing the results? Like that fabled Mars mission that failed because some calculations were done with the wrong units? Today, for many systems, we can assume that DUT1 obeys the three-decade-old standard and is less than 0.9 s. If that changes because the definition of UTC changes, we have effectively a whole new unit, a non-UT civil time measure. And made it more confusing by reusing the old name and invalidating megatons of documentation! These astronomical and navigation systems currently get inputs of time from all sorts of other systems and people: other instruments, other computers, sub-contractors, etc. Changing the meaning of UTC would lead to a cascade of systems that changed their own timescales and I/O formats, meaning that auditing the flow of time data between them would get more and more complex for a long time. To sum it up, PLEASE don't fundamentally change the DEFINITION of UTC, or you risk whole new kinds of confusion. Hopefully by now the folks on this list that don't like leap seconds at least have agreed that any change should be to a new time scale like TI, and announced decades in advance. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
Re: Risks of change to UTC
Rob Seaman scripsit: > Only a minority (small minority, one would think) of > systems currently include any DUT1 correction at all - although these > will perhaps tend to be the most safety-critical applications. [...] > > That is, of course, one of the major issues for astronomers - we rely > on UTC providing a 0.9s approximation to UT1 and most of our systems > don't use DUT1. Even our high precision applications (in either > interval or universal time) don't tend to require conversions other > than as a preprocessing step. Remediating our systems for such a > fundamental change to UTC would involve much larger changes than Y2K > did - algorithms and data structures would have to change, not just > the width of some string fields and sprinkling some 1900's around. I don't understand this. The first class of applications, those that actually receive DUT1 from somewhere, probably have a hard-coded assumption that |DUT1| never exceeds 0.9s or at worst 1.0s. They would need remediation. The second class, which just assumes UTC = UT1 and doesn't care about subsecond precision, would simply need to be front-ended with a routine that got DUT1 from somewhere and mixed it with TI to generate their own UT1. This is technically remediation, but of a rather black-box kind. > Also, standalone applications would have to become network aware to > have access to externally derived tables of DUT1. Well, this is perhaps no worse than systems that now have access to UTC and want reliable interval time needing externally derived tables of leap seconds. > Astronomers might be unusual in needing to introduce DUT1 into our > systems (on a short schedule for a large expense) should Sauron win > and the nature of UTC change, but we wouldn't be alone. And as clock > time diverges further and further from solar time, more systems in > more communities (transportation, GIS, innumerable scientific > disciplines, what have you) would be revealed to need remediation. Can you spell out some of those implications? -- What has four pairs of pants, lives John Cowan in Philadelphia, and it never rains http://www.reutershealth.com but it pours? [EMAIL PROTECTED] --Rufus T. Firefly http://www.ccil.org/~cowan
Risks of change to UTC
On Jan 15, 2006, at 1:07 PM, John Cowan wrote: There are a lot of systems, it seems, that assume DUT1 is bounded by either 0.9s or 1s. If leap seconds are turned off, then I'd expect that these will break and be replaced by systems that assume DUT1 is unbounded. Ah. I see. You are focusing here on explicitly Y2K-like risks. Those are indeed an issue, but I agree not a large one for most constituencies. Only a minority (small minority, one would think) of systems currently include any DUT1 correction at all - although these will perhaps tend to be the most safety-critical applications. As with Y2K, all systems have to be inventoried for potential risks, not just ones you know about in advance. That is, of course, one of the major issues for astronomers - we rely on UTC providing a 0.9s approximation to UT1 and most of our systems don't use DUT1. Even our high precision applications (in either interval or universal time) don't tend to require conversions other than as a preprocessing step. Remediating our systems for such a fundamental change to UTC would involve much larger changes than Y2K did - algorithms and data structures would have to change, not just the width of some string fields and sprinkling some 1900's around. (I know that oversimplifies Y2K - suspect virtually everybody on this list was intimately involved with their organization's Y2K remediation effort.) Also, standalone applications would have to become network aware to have access to externally derived tables of DUT1. Astronomers might be unusual in needing to introduce DUT1 into our systems (on a short schedule for a large expense) should Sauron win and the nature of UTC change, but we wouldn't be alone. And as clock time diverges further and further from solar time, more systems in more communities (transportation, GIS, innumerable scientific disciplines, what have you) would be revealed to need remediation. That's where I was coming from. Another issue is interoperability. There is the thought, perhaps, that merely by deciding to cease issuing leap seconds that all clocks on the planet will automatically converge on TAI (+ inane constant + local offset). Some systems (like those in astronomy) will converge on universal time. Would think it unwise to simply assume that no significant risks will be revealed as the dual timescales diverge. We all can likely agree that many deployed systems (of whatever nature) are naively configured. Is this likely to change overnight? Rob Seaman NOAO
