Re: Leap-seconds, the epsilon perspective
On Tue 2003-01-28T23:10:07 -0500, John Cowan hath writ: > Dr. Mark Calabretta scripsit: > > > Much of the problem boils down to the question of why we would want > > to continue to pretend that a mean solar day has exactly 86400 SI > > seconds when in fact, it has 86400+epsilon SI seconds. > > I at least care that a *civil* day be 86400 SI seconds in length. > Mean solar days don't affect me to speak of. Mark's suggestion verges on yet another solution that might be adopted by some for the sake of civil time. Any telescope with a polar mount already has a clock that keeps another kind of time -- sidereal time. This is counted in sidereal seconds, of which there are always 86400 during one rotation of the planet (an interval which is currently about 86160 SI seconds, and getting longer). In this sense sidereal seconds are not really a measure of elapsed time, for they vary in duration; they are actually a measure of earth rotation. But in the old days of telescope control the difference between earth rotation and time duration was less than the drift of any clock. If in the far future when the earth has slowed significantly it is still deemed important for civil time to have 86400 civil seconds in a day, then that future society will have decided, like the astronomers, to keep two kinds of seconds in common use. It may not even be necessary to look to the far future if the proposal to drop leap seconds were to cause some (religious?) societies to reject the use of UTC for civil time. Which is more important... for civil time to be counted in SI seconds? for civil time to track the rotation of earth smoothly? Mark's alternative resembles the civil time solution adopted by the martian colonists in Kim Stanley Robinson's "Red/Green/Blue Mars" trilogy, where the clocks tick SI seconds, but every day at midnight they stop for 39.5 minutes of "slip time" to let the planet catch up. If we have decided that SI seconds are to be used, which is more important... for civil time to keep noon from drifting? for civil time to increase constantly? The above scenarios may seem infeasible in a real society, but if the clocks of the future have access to TAI (for the sake of timestamping, precision time, and legal time), and also have access to UT1 (for civil time), then they could be preferred by some groups of our descendants. > What for? Why should we (the people of the Earth) care about mean > solar days? For some purposes, apparent solar time is important, but > most of the time it's civil time that counts. Why should that be tied > to mean solar days? Partly because eventually the scheme of turning UTC into a constant offset form of TAI requires a leap hour lest our descendants find themselves having their midday meal at 18:00 local civil time. This sort of pushing the problem off onto our descendants implies that we really don't have the right solution, just one that salves some needs now. > > I suspect this would account for 99.9% of the world's clocks, > > including the clocks inside most computers, VCRs and microwave > > ovens; on your wrist; or next to your bed. > > Hmm. How reasonable is it to expect this to change in future? If the future is a world of ubiquitous networking where Bill Gates can make every wristwatch and refrigerator magnet into a .NET client, then we should very much expect this to change. I doubt that we can definitively answer the questions posed above in a way that will satisfy the needs and technological [lack of?] constraints for all of our descendants. For that reason I remain a proponent of not modifying the meaning of time scales that work now. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93
Re: What I do. What do you do?
On Tue, Jan 28, 2003 at 04:30:41PM -0700, Rob Seaman wrote: > Perhaps it would help our discussions to simply describe our professional > (or otherwise) connections to UTC and other precision timing issues. Okay, I'll bite. I have no direct professional connection to UTC. I am a computer programmer who has, at various times, had to deal with a variety of different frustrations related to how time is kept, one of which is reminding other programmers that "because of leap seconds, not all days are 86400 seconds long, stop building that assumption into your programs" (a very poorly received warning, I might add). I have a strong appreciation of the value of a good standard, and likewise a strong disdain for any standard which I can recognize as poorly put together. While I have limited technical background with precision time, I do have a strong incidental personal interest in its issues. While my weak background makes me sincerely doubt I will be in a position to slice fine technical details in discussions of precision time, I do feel that I have ample background to understand the kinds of issues involved, and because I lack a certain amount of sophistication, I have some ability to notice when people are making claims that are based on "I'm used to thinking this way" because their arguments fail to enlighten me as to "why this way of thinking is correct and relevant". (Put another way: if you know you're right and yet a posting from me seems to miss the point, first check your assumptions, and then try explaining a different way.) [samples of Rob Seaman's job task descriptions snipped for brevity] > The notion of discarding the connection between UTC and GMT is not > just philosophically distasteful - it clearly would make my job more > difficult for zero benefit. Given my position as an intelligent-but-uninformed observer, it seems like UTC is a "good enough" standard for your uses. I see that UTC, as defined, is useful to your doing the job in the way that you currently do it, and certainly more useful than TAI-plus-constant-offset would be; if those are the only two options then of course you personally will favor UTC. I do not see that UTC is a maximally useful time reference for your work, though. When you look at pictures of stars as they vary over time, do you really find that a time reference based on the annual mean interval of earth rotations _relative_to_the_sun_ to be exactly what the doctor ordered? Ignore "in the real world where I work" for the moment; ignore "UTC" and "UT1" and "TAI" and dream a little: what would an *excellent* time standard look like for your specific niche? Granted there will be a need to compromise eventually in order to make everyone (almost) happy, but I think the discussion to date of (crudely) "UTC vs TAI" fails to take significant details into account, making any hypothetical consensus less optimal than it could be. Yes, civil time, an important consumer of any time standard, would much prefer approximation-of-earth-rotation-relative-to-the-sun than random-arbitrary-interval (e.g., 100,000 SI-second "days") or approximation-of-earth-rotation-relative-to-"fixed"-stars as its time standard. But civil time is a different consumer of a potential time standard than you-as-worker-for-NOAO-Data-Products-Program, and wouldn't be nice if someone smarter than both of us could, upon understanding the details of the issues involved, see a better solution than UTC which addresses both of these (and a vast array of other) uses? Without the details of what the various "ideal" standards would look like, such a hypothetical insight seems, to my mind anyway, impossible to come by. I realize that the astronomical community has evolved to a consensus that UT1 (approximated by UTC) is a highly useful way to mark time, with the additional feature that it is usable as a civil time standard, but there is so much of that evolution which is based on historical accident rather than purely technical requirements that I find it hard to believe that there would be no possible way to improve upon it, even after non-astronomical constraints are factored in, if only it were possible to start anew with a clean slate. As to FITS standards: well of course they are UTC based --- that is what the current time reference standard is; I wouldn't expect them to use anything else (even more so since much of this is data whose collection depends on earth-orientation-in-space, not merely SI-seconds elapsed between observations). And any proposal for a new time reference standard would need to have a transition plan which would enable straightforward translation between it and something resembling UTC for at least a couple of decades while legacy applications, standards, and on-line data either exceed their useful lifetime or get converted (archived off-line data would not get converted, though a means to make such a conversion on an as-needed should be defined, even if that conversion is (
Re: Leap-seconds, the epsilon perspective
On Wed, Jan 29, 2003 at 12:33:48AM -0800, Steve Allen wrote: > > What for? Why should we (the people of the Earth) care about mean > > solar days? For some purposes, apparent solar time is important, but > > most of the time it's civil time that counts. Why should that be tied > > to mean solar days? > > Partly because eventually the scheme of turning UTC into a constant > offset form of TAI requires a leap hour lest our descendants find > themselves having their midday meal at 18:00 local civil time. This > sort of pushing the problem off onto our descendants implies that we > really don't have the right solution, just one that salves some needs > now. But civil time already has leap hours (positive and negative) jumping around most parts of the globe twice a year. Furthermore, about half of the year I have my "midday" meal at about 20:00 UTC, and the other half I have it at 19:00 UTC. And when I travel, my "midday" meal time often shifts to some other UTC time. Oh, sure, the locals refer to the time as "noon" or "12:00", but that is not what my watch (which is set to UTC) says. It is also very unusual for it to be what my sundial would say (if I happened to bring it with me). Trying to tie civil time to "mean solar noon" is merely a historical convention. While global civil time standards have been been fairly consistent in using this technique (even if there were sometimes competing definitions for which meridian to use), it is not a fundamental requirement of civil time. There are very few locations on earth which use unadulterated UTC as their time base (not even Great Britain, ignoring the distinction between GMT and UTC, because about half the year they are on BST.) The requirements of civil time are very forgiving --- if local solar noon is within a couple of hours (sometimes more) of "clock noon", that appears to be good enough for civil use (based on observation of current practice), and offset-from-time-standard is controlled by political whim, which means that current mechanisms are more than amply capable to make any "leap hour" adjustments when such adjustments are felt to be necessary. Can't we declare civil time a non-issue for now? I think both UTC and TAI are significantly more-than-adequate for its meager requirements (by precision time metrics). I know that plain TAI is "not acceptable" to the astronomical community, who is an important consumer of precision time, and that UTC (because it is an approximation of UT1) "is acceptable", but that's about it. Is there another community of time consumers for which UTC is better than TAI? (Okay, "astronavigators", but unless one of them speaks up about special needs I'll pretend like they are a subgroup of the "astronomical community".) Is there a more useful time reference than UT1 for the astronomical community? It seems like no one who is able to answer these questions of mine ever feels like they are worthy of an answer (or maybe I have just been too subtle in my asking), but I think they are vitally important to the question of whether (and if so how) our time standard should be changed. Yes, I am an ignorant fool, but I can learn. Enlighten me. --Ken Pizzini
Re: What I do. What do you do?
On Tue 2003-01-28T16:31:03 -0700, Rob Seaman hath writ: > A useful exercise from other mailing lists and conferences and such > is simply to get to know each other and how we all fit into the puzzle > under discussion. Without listing details, point by point my job is largely the same as Rob's except that I work for a state-funded agency that manages venerable equatorial mount telescopes in California and co-manages the largest az-alt mount binoculars in the world in Hawaii. I am an astronomer paid to write code, and I am more familiar with coordinates, timescales, and protocols than many. Among the student team who assisted with computer system management during my undergraduate days I am infamous for the "Steve Allen Memorial Gripe" when I submitted the report that the system clock was wrong by two minutes. I put NTP onto our local systems long before the OS vendors were supplying it as a default element of the system. I inserted language when the FITS standard revised its notions of date/time. > The notion of discarding the connection between UTC and GMT is not > just philosophically distasteful - it clearly would make my job more > difficult for zero benefit. For more than 20 years the Mt. Hamilton telescopes have been pointed by a system that runs off a multitasking, 8-bit, 6502 processor. Lick is currently constructing the replacement for this system and also contracting with an outside agency to supply the pointing system for a new telescope. These systems are expected to last for many decades. Neither of these systems expects UTC - UT1 > 1 second. Even if a concrete proposal for handling the side effects of abolishing leap seconds were available now, it would be too late for these new systems. For the sake of those whose systems are not yet as concrete as ours the possibility that leap seconds might cease means that the watchwords should be proclaimed: Do not presume that the value of (UTC - UT1) will remain negligible. Make the value of (UTC - UT1) into an inputtable parameter. This is somewhat useless as a specification in the absence of a definite future standard, but it relatively safely presumes that something called UTC will remain easily available (as now) and that the value of (UTC - UT1) will (continue to) change slowly enough that it can, if necessary, be put in manually. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93
FITS and the crafting of standards
On Tue 2003-01-28T16:31:03 -0700, Rob Seaman hath writ: > oscillatory modes.) Just one more example (among many) is my long > time participation in the FITS standards process. FITS is astronomy's > universal data format, whose metadata standards rely explicitly on > UTC. For the sake of further seeding the discussion of standard this explicit reliance deserves exposition. The FITS standard was re-crafted hurriedly in 1997 because an astute fellow noted that the original definition from 1980 was so short-sighted that it would break in Y2K. The resulting standards document contains the following: The value of the DATE keyword shall always be expressed in UTC when in this [the new Y2K-clean] format, for all data sets created on earth. The purpose of the DATE keyword is to indicate the creation date/time of the FITS file. The trailing clause about "earth" is an explicitly inserted safety valve due to my concerns that the required timescale should be accessible to the writer of a FITS file. The presumption was that UTC will be readily available on earth. For FITS file authors on spacecraft or elsewhere the standard tacitly admits that UTC may be neither available nor relevant, and that the timescale which might be used in such a case is beyond the scope of the document. In actual practice this requirement is not always met because the creation date of the file is usually determined by a call to the operating system. The system clock may not know absolute time even as well as my wristwatch does. Even if the system has access to NTP, the letter of the standard is going to be violated near the insertion of leap seconds. Very few systems have access to any actual form of UTC. On the other hand, the loss to posterity of not knowing when a file was created to within a second is rarely important, so science does not suffer much from this violation of the standard. Regarding the DATE-OBS keyword the standard says: When the [new Y2K-clean] format with a four-digit year is used, the default interpretations for time shall be UTC for dates beginning 1972-01-01 and UT before. Other date and time scales are permissible. The DATE-OBS keyword is intended to record the date/time of the observation. The language used here is much looser. The standard gives the default interpretation, but does not give any means for determining whether or not this default is in use. This was intended to serve as a guide that FITS file authors should use a timescale which has been most available throughout the history of most astronomical observations. This was presumed to be UT (and not necessarily UTC), but any other time scale is acceptable if the mission requirements demand it. The FITS standard has an appendix about time scales that goes into further details about suggested practices and relativistic gotchas. The content of the appendix is not binding. During the drafting there were voices requesting that the new standard should require the use of TAI rather than UT because (as noted above with NTP) TAI is less ambiguous than UTC. This was struck down for several reasons. One is that there are many astronomical observations from before the advent of TAI (and there are ongoing efforts to digitize old emulsion). Another reason is that TAI is simply not as available as UT, and the standard cannot place such a steep requirement on all the astronomical data acquisition systems in the world. Another reason is that many sorts of observations are reduced as if the observation occurred from a point other than the earth's surface, and TAI does not make sense for observers at different relative velocities and different depths in gravitational potentials. The point of all this is that the specification of UTC in FITS is for pragmatic purposes and for guiding usage toward the most precise meaning that is possible for a document that holds no power over pre-existing implementations. Several aspects were left intentionally vague in the anticipation that social trends in time scale usage would evolve. Hopefully the time and frequency community who initiated this forum are attempting to find a similarly sensitive way to handle the leapseconds issues. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93
Re: FITS and the crafting of standards
Can I muddy the waters with some facts/evidence I have collected recently? (if your answer is "no" - then hit 'delete' now ;-) First where do I fit in this debate. I am the systems manager for the Astronomy group at St.Andrews University. We run a small observatory with 4 telescopes, a couple of Meade LX200s, a 1980s built scope on a ~1900 Grub Parsons mount (where setting is done with large metal rings with painted scales - too new for Victorian engraved brass, too old for digital encoders, very nice to use) and a 1m class Schmidt-cass built on-site in the 1960s. When this discussion first came up I was about to re-re-write my code for the digital setting circles that have been added to the 1m telescope, and this needs a time feed - UTC does nicely but if it going to change I want to know. Over the past year or two I have given a talk entitled "What time is it?" to local Astronomical Societies. This is a quick romp from sundials giving 12 'hours' sunrise to sunset to TAI, UTC, TDT, TDB, LST, etc. with a bit about the moon slowing us down. As part of this I do a check on the accuracy of the timekeeping of the audience. The full range for the audience is usually plus/minus 20secs with ~25% in the +/-5 secs range. I had one gentleman who was happily 2 mins slow - good enough for catching an Edinburgh bus, he claimed! Thus we have a very rough measure of the accuracy of the interested man-in-the-street timekeeping. Yesterday morning over a cup of coffee I floated the question of leapseconds and their abolition passed a couple of friends in the University IT Services dept. One quickly decided that leapseconds were the obvious solution, then realised we have them, and wondered what the problem was. The other, thought for a bit, then decided that decoupling time from from the rotation of the earth was a bit more philosophical than technical and was the sort of world cultural heritage thing that should not be tinkered with. A slight worry I have is what the popular media would make of it if they decided that "scientists" were going to mess about with time. Yet more anti-science in the media :( Sorry nothing posative in this - but then users of clock-on-the-wall time are always going to be a problem. Roger Roger Stapleton [EMAIL PROTECTED] University of St.Andrews, School of Physics & Astronomy North Haugh, St.Andrews, Fife. KY16 9SS Phone 01334-463141 Fax 01334-463104
Re: Leap-seconds, the epsilon perspective
Steve Allen scripsit: > Which is more important... > for civil time to be counted in SI seconds? > for civil time to track the rotation of earth smoothly? IMHO the former. > Mark's alternative resembles the civil time solution adopted by the > martian colonists in Kim Stanley Robinson's "Red/Green/Blue Mars" > trilogy, where the clocks tick SI seconds, but every day at midnight > they stop for 39.5 minutes of "slip time" to let the planet catch up. I always thought that was silly. How do you keep experiments running (not necessarily precision-time ones, just ordinary ones) while your clock is saying "midnight, midnight, midnight, midnight, ...". And what about Martian time zones? > If we have decided that SI seconds are to be used, > which is more important... > for civil time to keep noon from drifting? > for civil time to increase constantly? The later. Non-monotonic civil time would be a disaster, and we are very lucky in the current regime that rotation is slowing and not speeding up. > Partly because eventually the scheme of turning UTC into a constant > offset form of TAI requires a leap hour lest our descendants find > themselves having their midday meal at 18:00 local civil time. This > sort of pushing the problem off onto our descendants implies that we > really don't have the right solution, just one that salves some needs > now. I think it's utopian to suppose that a "right" solution exists; we are trying to reconcile the fundamentally irreconcilable. Eventually (a very long time from now) we *will* have to abandon the 86400 seconds = 1 day assumption. (I utterly reject any attempt to redefine the SI second.) > > > I suspect this would account for 99.9% of the world's clocks, > > > including the clocks inside most computers, VCRs and microwave > > > ovens; on your wrist; or next to your bed. > > > > Hmm. How reasonable is it to expect this to change in future? > > If the future is a world of ubiquitous networking where Bill Gates can > make every wristwatch and refrigerator magnet into a .NET client, then > we should very much expect this to change. Not what I meant. I meant, how reasonable is it to expect to find 10^-8 reliable clocks in ordinary hands in the future? If every clock is indeed networked (a very unlikely future, I'd say), then of course the time scale can be arbitrarily futzed with and all clocks will stay in sync. -- John Cowanhttp://www.ccil.org/~cowan [EMAIL PROTECTED] Please leave your values| Check your assumptions. In fact, at the front desk. | check your assumptions at the door. --sign in Paris hotel |--Cordelia Vorkosigan
Re: What I do. What do you do?
Ken Pizzini scripsit: > Okay, I'll bite. What Ken says, except that: > Yes, civil time, an important consumer of any time standard, would > much prefer approximation-of-earth-rotation-relative-to-the-sun > than random-arbitrary-interval (e.g., 100,000 SI-second "days") > or approximation-of-earth-rotation-relative-to-"fixed"-stars as its > time standard. I don't think this case has been made yet, other than by handwaving and postulating. Specifically, that the current regime is better than a fixed scheme of 1 day = 86400 SI seconds. -- John Cowan <[EMAIL PROTECTED]> http://www.reutershealth.comhttp://www.ccil.org/~cowan .e'osai ko sarji la lojban. Please support Lojban! http://www.lojban.org
Re: What I do. What do you do?
Rob Seaman wrote on 2003-01-28 23:31 UTC: > A useful exercise from other mailing lists and conferences and such > is simply to get to know each other and how we all fit into the puzzle > under discussion. OK, here we go: I'm a lecturer (en-US: assistant professor) in computer science and a programmer. I developed my strong interest in precision computer time keeping while I was an undergraduate at the University of Erlangen, Germany, where quite a lot of work was done in the early 1990s on improving the xntpd clock synchronization software and its kernel support in various Unix-style operating systems. This software is today widely used to synchronize workstations to within better than 1 ms with UTC. I contributed minor bits of the early Linux kernel clock code and I am in-depth familiar with the clock implementations and API issues of POSIX-compliant operating systems. I wrote various drafts for revised clock APIs that are under consideration by various programming language and operating system standards committees, e.g. see http://www.cl.cam.ac.uk/~mgk25/c-time/ http://www.cl.cam.ac.uk/~mgk25/uts.txt for two examples. I am well familiar with the computer science literature on and practical issues with clock synchronization in distributed systems at all levels and have reasonably good contacts with the NTP and Linux-kernel communities. I'm also a reasonably well-educated hobby astronomer. One of my on-going minor time-related battle fields is to convince the Microsoft NT kernel team to support keeping the battery clock of a PC in UTC as opposed to local time, to reduce significantly the difficulties experienced by people who travel with dual-boot laptops between multiple time zones and/or reboot their machine within an hour after the end of DST: http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html I also made various efforts to spread familiarity with the ISO 8601 international date and time notatiuon standard: http://www.cl.cam.ac.uk/~mgk25/iso-time.html My views in this discussion: - I believe that basing local civilian times on either an atomic time with or without leap seconds will not make any significant difference in practice (both in astronomy and in distributed real-time information processing and communication systems). - There are many very practical engineering solutions known to handle either case safely, elegantly, inexpensively and reliably. [I am happy to explain these in more detail on request to anyone who still believes that leap seconds do necessarily cause any significant problems in practice.] - Those who believe that you can't keep a battery clock to UTC as it might miss leap seconds when it is offline, I'd like to remind gently that the frequency error of most mass-market crystal clocks is three orders of magnitude (factor 1000) worse then the frequency difference between TAI and UT1, therefore this discussion is naive. It remains so as long as there are no cheap clock oscillators with <<10^-7 relative frequency error on the horizon anywhere. Available clocks costing less then several tens of kiloeuros behave neither like TAI nor like UTC at all on their own. They always need to be integrated into an externally controlled PLL to follow either TAI or UTC, and then you can run them equally easily with or without leap seconds, just as you please. This is unlikely to change in the forseeable future. - Computer software should in practice run on a smoothed version of UTC (such as UTS) to avoid the rare anormality of the 23:59:60 timestap. Even though this is already widely used practice, it hasn't been formally standardized yet and therefore isn't done consistently in practice yet. This issue needs to be addressed in the information technology communities as soon as the dust has settled in this discussion on revising UTC, but this is nothing the astronomy or time-broadcast communities needs to get involved with significantly. It will be purely a software engineering API convention under the umbrella of different international standards organizations. - Since leap seconds do in practice not have to cause any significant disruptions or complications, I am not convinced that there is a good case for justifying any modification on the existing UTC standard. On the other hand, I could live equally well with a TAI-locked local time. Advantages and disadvantages on either side seem to hold the ballance. - UTC ain't broken, so don't fix it. Markus -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
Re: What I do. What do you do?
Rob Seaman wrote: > Perhaps it would help our discussions to simply describe our professional > (or otherwise) connections to UTC and other precision timing issues. Excellent idea. I'm a freelance programmer based in High Wycombe, England. Over the last few years I've worked on a quite a lot of geographical related software (data preparation for the Ordnance Survey Interactive Atlas of Great Britain CD and AutoCAD based software to help with designing aircraft instrument approach procedures) and also, more relevant to this discussion, data logger devices used for scoring various sports. The first were loggers used to record the output of GPSs for gliding (I fly gliders and aeroplanes in my spare time) which were then adapted for use in motor racing and sailing. Most recently we've done some loggers which read RFID tags attached to motor cyclists for scoring off-road events. More generally, I have a lot of interest in the design of programming languages and standards. A lot of what Ken Pizzini wrote in the first two paragraphs of his posting on this subject also applies to me. I thought of quoting those paragraphs directly but I'll just use one sentence: > I have a > strong appreciation of the value of a good standard, and likewise a > strong disdain for any standard which I can recognize as poorly put > together. For good practical reasons but also as an exercise in standard writing I've been having a go at defining a format for geographical positions in contexts such as XML documents. Have a look at: http://www.edavies.nildram.co.uk/lat-long/index.html While I'm not very serious about it I have a more-than-average interest in amateur astronomy. Two of my friends have reasonable size telescopes (8" and 11") which I go and peer through from time to time. I've been following with interest their experiments with motorizing these and with use of webcams with extended exposure times. I do some satellite watching - it was a mention of the campaign to drop leap seconds in the SeeSat-L list that brought me to this list. Here's the first paragraph of a message I posted to SeeSat-L in July last year: > My first thought was that the idea of dropping leap seconds was > potty but having read a bit about it and reflected on the requirements > and knowledge of different users I'm coming round to the view that > it might not be such a bad idea. My general concern is that currently most software neglects leap seconds but that in the future, as systems become more tightly networked, this will not be possible. For example, the aviation industry is moving (slowly, as is understandable) towards a new generation of communication, navigation and surveillance systems which will be much more dependent on GPS and the like. In particular, GPS time will be used for many functions such as allocation of time slots for transmissions on VHF and UHF frequencies. Software will, in many cases, run on standard PCs. (There a radar-like system running on Microsoft Windows systems on trial in Sweden and the FAA has somebody looking into the use of Pocket PCs for in-cockpit displays in light aircraft). GPS is widely used in cars, boats, light aircraft and so on. It's use will become more tightly integrated with other systems. The overall result is that there will not be a simple distinction between "precision" timing applications (which need to know about leapseconds and so on) and "non-precision"/"civil" applications which can ignore them. The two will co-exist on the same machines in many application areas - and often in the hands of users who don't want to have to care about the difference. (I'm using "precision" pretty loosely here - meaning anything that cares about time to an accuracy of better than about one second, never mind the nano second level). If we are to continue with the application of leap seconds to civil time then there is a need for a huge education program (particularly of programmers) and some careful thinking to make sure that "precision" applications can get the information they need while existing naive software doesn't get messed up. My worry is that the long term cost of this effort will be neglected because it is widely distributed and not accounted directly. Ed Davies.
Telescope pointing and UTC, was: Re: What I do. What do you do?
Steve Allen wrote: > ... > For more than 20 years the Mt. Hamilton telescopes have been pointed > by a system that runs off a multitasking, 8-bit, 6502 processor. Lick > is currently constructing the replacement for this system and also > contracting with an outside agency to supply the pointing system for a > new telescope. These systems are expected to last for many decades. > Neither of these systems expects UTC - UT1 > 1 second. ... Out of curiousity, where do these systems get UTC from? Broadcasts like WWV or GPS, via NTP or someplace else? I assume there is a local, reasonably accurate, clock which is corrected from the external source. Also, do they actually use UTC as an approximation to UT1 or do they correct UTC to UT1 but just have some built in assumption that the correction will be less than one second? If they make the correction, where do they get UT1 - UTC from? Is it entered manually? Ed Davies.
Re: FITS and the crafting of standards
Roger Stapleton scripsit: > Yesterday morning over a cup of coffee I floated the question of > leapseconds and their abolition passed a couple of friends in the > University IT Services dept. One quickly decided that leapseconds were > the obvious solution, then realised we have them, and wondered what the > problem was. The problem is that they are not announced much in advance, and one needs to keep a list of them back to 1972 which grows quadratically in size. > Sorry nothing posative in this - but then users of clock-on-the-wall time > are always going to be a problem. We have met the enemy and he is us, in fact. We are all users of civil time first and foremost. -- John Cowan [EMAIL PROTECTED] www.reutershealth.com ccil.org/~cowan Dievas dave dantis; Dievas duos duonos --Lithuanian proverb Deus dedit dentes; deus dabit panem --Latin version thereof Deity donated dentition; deity'll donate doughnuts --English version by Muke Tever God gave gums; God'll give granary --Version by Mat McVeagh
Re: What problems do leap seconds *really* create?
John Cowan wrote on 2003-01-29 17:56 UTC: > The problem is that they are not announced much in advance, and one needs > to keep a list of them back to 1972 which grows quadratically in size. Is this a real problem? Who really needs to maintain a full list of leap seconds and for what application exactly? Who needs to know about a leap second more than half a year in advance but has no access to a time signal broadcasting service (the better ones of which all carry leap second announcement information today)? For pretty much any leapsecond-aware time-critical application that I can think of, it seems more than sufficient to know: - the nearest leap second to now - TAI-UTC now - UT1-UTC now This information is trivial to broadcast in a fixed-width data format. (For the nitpicker: The number of bits to represent TAI-UTC admittendly grows logarithmically as be move away from 1950. We know we can live with that, as O(log(t)) is equivalent to O(1) for engineering purposes.) Markus -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
Re: What problems do leap seconds *really* create?
Markus Kuhn scripsit: > Who really needs to maintain a full list of leap seconds and for what > application exactly? Anyone who needs to convert arbitrary timestamps to the corresponding LCT times. > Who needs to know about a leap second more than half a year in advance > but has no access to a time signal broadcasting service (the better ones > of which all carry leap second announcement information today)? Any isolated system that it isn't practical to upgrade every six months. -- "In my last lifetime, John Cowan I believed in reincarnation;http://www.ccil.org/~cowan in this lifetime, [EMAIL PROTECTED] I don't." --Thiagi http://www.reutershealth.com
Re: What problems do leap seconds *really* create?
On Wed 2003-01-29T14:49:14 -0500, John Cowan hath writ: > > Who needs to know about a leap second more than half a year in advance > > but has no access to a time signal broadcasting service (the better ones > > of which all carry leap second announcement information today)? > > Any isolated system that it isn't practical to upgrade every six months. Please explain why this requirement is not confounded every time your legislature decides to mess with the start and stop of summer time (with a year's notice because of the olympics, or with a week's notice because the war effort is going badly, or whatever). -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93
Re: What problems do leap seconds *really* create?
Steve Allen scripsit: > > > Who needs to know about a leap second more than half a year in advance > > > but has no access to a time signal broadcasting service (the better ones > > > of which all carry leap second announcement information today)? > > > > Any isolated system that it isn't practical to upgrade every six months. > > Please explain why this requirement is not confounded every time your > legislature decides to mess with the start and stop of summer time > (with a year's notice because of the olympics, or with a week's notice > because the war effort is going badly, or whatever). I was a little too clipped. If you know all the leap seconds, you can convert a Unix-style timestamp to UTC reliably; if you further know all the timezone changes, you can convert UTC to LCT reliably. -- A rabbi whose congregation doesn't want John Cowan to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it [EMAIL PROTECTED] isn't a man.--Jewish saying http://www.reutershealth.com
Re: What problems do leap seconds *really* create?
Markus Kuhn wrote: > > John Cowan wrote on 2003-01-29 17:56 UTC: > > The problem is that they are not announced much in advance, and one needs > > to keep a list of them back to 1972 which grows quadratically in size. > > Is this a real problem? > > Who really needs to maintain a full list of leap seconds and for what > application exactly? (rest deleted) Markus: Any application which seeks to calculate the difference in time between two events recorded in UTC time needs to know if there are any leap seconds between the start and stop time. For example, suppose you were studying solar flares, and analyzing some data taken in 1998, and you saw a burst of hard X-rays at 23:59:53 UT on Dec 31, followed by a rise in EUV emission at 00:00:10 UT the next day. You'd think that the delay time between the two would be 17 seconds, but it's really 18 seconds because of the leap second introduced that day. That's a vital difference for the scientific analysis of the data. On another subject, we were asked to introduce ourselves, and explain our relationship to UTC/TAI issues. My name is William Thompson, and I'm a solar astronomer working at the NASA Goddard Space Flight Center. I work on various solar satellite missions, including the Solar and Heliospheric Observatory (SOHO) and the upcoming Solar Terrestrial Relationships Observatory (STEREO). My introduction to UTC/TAI issues came about because of the SOHO program. I was writing the telemetry processing software for one of the instruments, and realized that the spacecraft operated in TAI time, i.e. the number of seconds since 1-Jan-1958, while all the science planning and commanding would be done in UTC. I therefore wrote software to handle the conversions between these two kinds of time, in Interactive Data Language (IDL) which is a scientific data analysis package from Reseach Systems Inc., and which is widely used in astronomy and solar physics. This UTC/TAI conversion software is now used by a number of science instrumentation teams for spacecraft commanding and telemetry processing. And yes, part of that software package includes a list of all leapseconds added since 1 Jan 1972. Currently, my software doesn't handle TAI/UTC conversions between 1958 and 1972, when UTC seconds had varying lengths. William Thompson
Re: What problems do leap seconds *really* create?
On Wed 2003-01-29T15:05:59 -0500, John Cowan hath writ: > > > > Who needs to know about a leap second more than half a year in advance > > > > but has no access to a time signal broadcasting service (the better ones > > > > of which all carry leap second announcement information today)? > > > > > > Any isolated system that it isn't practical to upgrade every six months. > > > > Please explain why this requirement is not confounded every time your > > legislature decides to mess with the start and stop of summer time > > (with a year's notice because of the olympics, or with a week's notice > > because the war effort is going badly, or whatever). > > I was a little too clipped. If you know all the leap seconds, you can > convert a Unix-style timestamp to UTC reliably; if you further know all > the timezone changes, you can convert UTC to LCT reliably. I remain confused about why this "isolated system" cares whether it keeps time as UTC or TAI. How does its time get set? How does its time stay locked to SI seconds? Are you supposing that the system is able to keep SI seconds because it has some sort of unshielded PLL which is tracking the carrier signal from something like the US Navy's high powered VERDIN VLF transmissions for submarines? (With their 50 baud message that basically says "We're still here so don't launch" and if your clock stops ticking, nothing really matters much anymore.) If not, why does it not just count time as crystal oscillations since the POST phase of its motherboard and not bother with names like TAI or UTC? Is there really any system such as this? -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93
Re: What problems do leap seconds *really* create?
William Thompson scripsit: > Any application which seeks to calculate the difference in time between > two events recorded in UTC time needs to know if there are any leap > seconds between the start and stop time. For example, suppose you > were studying solar flares, and analyzing some data taken in 1998, > and you saw a burst of hard X-rays at 23:59:53 UT on Dec 31, followed > by a rise in EUV emission at 00:00:10 UT the next day. You'd think > that the delay time between the two would be 17 seconds, but it's > really 18 seconds because of the leap second introduced that day. Thanks for the example. Of course it is not astronomy-specific: the same thing applies if you are calculating how long somebody spoke for in field linguistics, or the amount of time it takes a moving part to stop moving in engineering. What we are dealing with here is time-zone independent civil time. > That's a vital difference for the scientific analysis of the data. Indeed. > And yes, part of that software package includes a list of all > leapseconds added since 1 Jan 1972. Currently, my software doesn't > handle TAI/UTC conversions between 1958 and 1972, when UTC seconds > had varying lengths. Modern Unix time packages (both GNU and ADO) assume that TAI-UTC was 10 from the epoch until 1972-06-30T23:59:60 UTC. Or to put it another way, the epoch was at 1970-01-01T00:00:10 TAI. When did the TAI timescale first come into existence? One answer seems to be that TAI was born on 1958-01-01T00:00:00 UT2, which was also 1958-01-01T00:00:00 TAI. But OTOH the definition of the SI second changed in 1967 and again in 1997. What did these changes do to the uniformity of TAI? I found the following interesting statement at http://www.maa.mhn.de/Scholar/times.html : # The need for leap seconds is not caused by the secular slowdown # of Earth's rotation (which is less than 2 milliseconds per century) # but by irregular variations in this rotation and by the fact that the # definition of the SI-second is fixed on the duration of the year 1900 # which was shorter than average. -- Not to perambulate || John Cowan <[EMAIL PROTECTED]> the corridors || http://www.reutershealth.com during the hours of repose || http://www.ccil.org/~cowan in the boots of ascension. \\ Sign in Austrian ski-resort hotel
Re: Telescope pointing and UTC, was: Re: What I do. What do you do?
The astronomers on this list have had no qualms about providing concrete examples of how their systems work and why they would break if leap seconds were stopped. Aside from GLONASS, those who wish to abolish leap seconds have not concreately identified the systems which don't like leaps. This is an uncomfortable asymmetry. On Wed 2003-01-29T15:14:14 +, Ed Davies hath writ: > Steve Allen wrote: > > by a system that runs off a multitasking, 8-bit, 6502 processor. Lick > Out of curiousity, where do these systems get UTC from? Broadcasts > like WWV or GPS, via NTP or someplace else? I assume there is a > local, reasonably accurate, clock which is corrected from the > external source. The Lick telescope control systems have a reasonably good crystal oscillator. Originally the clocks were set via commands over a home-grown serial multiplexer interface that used coaxial cable as the interconnect medium. The commands were issued, nightly as needed, from other 8-bit microcomputers. Time was set by typing in a target time and hitting on the tone of a radio broadcast. Currently these commands travel over TCP/IP up to an interface board that talks the old language to the controller. The time setting commands are issued regularly from a 32-bit Unix box that has NTP. > Also, do they actually use UTC as an approximation to UT1 or do they > correct UTC to UT1 but just have some built in assumption that the > correction will be less than one second? If they make the correction, > where do they get UT1 - UTC from? Is it entered manually? There is no distinction between UT1 and UTC in this system, and given the engineering requirements it would have been a waste even to consider the difference some 25 years ago. The telescope for which it was designed is 50 years old. At that era it was clock driven, and the telescope operator and astronomer both spent most of their time in the dome, at least one of them peering through the guide scope while trying not to freeze. This was the era of photographic emulsions and gentleman astronomers not hurrying the pointing because the exposure would be 4 hours long and besides he hadn't got the tobacco in his pipe lit yet. Besides that, the longitude of the telescope wasn't actually known much better than a second of time. When the current system was implemented around 25 years ago the telescope operator and astronomer had moved into the control room doing most of their target acquisition and guiding via image-intensified video. The tons of steel and bearings of the telescope structure, however, proved to have (modellable) flexure and (unmodellable) hysteresis effects which made sub-second accuracy not terribly relevant. Now we are in the era of CCD astronomy with astronomers unhappy that the target did not slew right into the center of the autoguider spot, and there are 50 more objects to acquire tonight (and 100 other astronomers who are competing for her job if she fails to get tenure). The new telescope control system system under construction still presumes that UTC is the available form of time and that UT1 is close enough to it that it doesn't matter for this old telescope. We have source code control over this system, so we will be able to fix it later if necessary. The automated observing programs to be run on the new telescope that a contractor will soon build for us do require sub-second UT1. Given the lack of concrete in this "no leap seconds" proposal we cannot specify that the contractor provide a means for handling a condition for which no specification exists. This almost certainly means calling the contractor back for more work if leap seconds are stopped. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93
Re: What problems do leap seconds *really* create?
Those of us with a day job may be having a hard time keeping up with the messages as they arrive fast and furious :-) > # The need for leap seconds is not caused by the secular slowdown > # of Earth's rotation (which is less than 2 milliseconds per century) > # but by irregular variations in this rotation and by the fact that the > # definition of the SI-second is fixed on the duration of the year 1900 > # which was shorter than average. Basically we don't have leap seconds because the Earth's rotation is slowing down (by transfering angular momentum to the Moon). Rather, we have leap seconds because the Earth has *already* slowed down since 1900. See the rather consistent slope of about 7 seconds per decade on the plot of UT1-UTC (with leap seconds removed) versus date: ftp://gemini.tuc.noao.edu/pub/seaman/leap/noleap.pdf The current dynamical effects are the subtle wiggles imposed on this trend. This is actually a fairly useful bias since it guarantees (short of asteroid impact or armageddon) that there will be no negative leap seconds. Again, please note how consistent the divergence is between atomic and Earth timescales over decade long periods. Where precisely is the urgency to adopt a quick fix? Ken Pizzini says: > I realize that the astronomical community has evolved to a consensus > that UT1 (approximated by UTC) is a highly useful way to mark time, Rather we've evolved a consensus that different problems require different systems of time - not surprising, since we invented most of them. > with the additional feature that it is usable as a civil time standard, It isn't just usable - it is preferable to many alternatives. > but there is so much of that evolution which is based on historical > accident rather than purely technical requirements "Historical accident" makes it sound like the practice of timekeeping was some afterthought to events. The reality is that timekeeping has often been central to other, bloodier, battles - from Augustus Caesar appropriating an extra day from February into "his" month - to Harrison's chronometer that was instrumental to the building of a later empire. Is there nobody on this list who was present at the birth of UTC? It is a good, solid, pragmatic standard. The ability to issue leap seconds monthly clearly represents a recognition that these would be needed to preserve the standard over hundreds or thousands of years. > that I find it hard to believe that there would be no possible way to > improve upon it, even after non-astronomical constraints are factored > in, if only it were possible to start anew with a clean slate. The astronomical community isn't afraid to discuss a successor to UTC. The mere presence here of several vocal members of that community should demonstrate this. There is always room for improvement - although the elegant simplicity of UTC will be hard to rival. What we object to (if my friends don't mind my saying so) is not the idea of *improving* UTC. What we object to is this current process which appears to be an attempt to discard the standard entirely - and to do so with minimal consent. Please! Let's talk about ways to improve UTC and civil timekeeping. And let's take the appropriate amount of time to reach a decision - say - 40 or 50 years. In the mean time, let's pay attention to the real question, which is how to build an infrastructure that will dramatically improve the dissemination of all time signals. NTP is a lovely mechanism. Astronomers are likely among its most passionate users. The limitations of NTP or of any other general purpose mechanism for disseminating time signals should not limit the definition of the standards behind those signals. Rather, NTP, WWV, GPS - and heavens to Betsy, GLONASS - should be built in a fashion that can handle a general parametrized time standard. This should include a static offset as used by GPS, as well as frequently or infrequently introduced time jumps of variable sizes in either direction as required by daylight saving or leap seconds. These systems should perhaps be parametrized to support epsilon schemes as described by Calabretta or by Kuhn's UTS. And a general purpose time distribution mechanism should support differing rates as required by sidereal time, for example. Similarly, personnel associated with various projects are expected to know enough engineering to build incredibly complicated radio equipment and other devices. Why aren't these same projects expected to handle time issues with similar professionalism? If they need unsegmented time - they should use some variation of TAI - and if they don't require an Earth fixed time scale - they shouldn't use UTC. And if they do use UTC, well then, they should figure out how to handle leap seconds. Leap seconds are discussed very prominently in a very short document. Rob Seaman National Optical Astronomy Observatory
Re: What problems do leap seconds *really* create?
On Wed 2003-01-29T15:43:24 -0700, Rob Seaman hath writ: > Please! Let's talk about ways to improve UTC and civil timekeeping. > And let's take the appropriate amount of time to reach a decision - > say - 40 or 50 years. In the mean time, let's pay attention to the > real question, which is how to build an infrastructure that will > dramatically improve the dissemination of all time signals. Alas, we do not have 40 years, we have less than 35. The end of 32-bit Unix time is 2038-01-19T03:14:07. Well before that the Unixes of the future must have decided on the proper way to implement the algorithms for handling 64-bit time_t when receiving inputs from the NTP(s) of the future. Although there are many technical aspects to the situation, for practical purposes any change of UTC is legislation. Effective legislation seeks the common good while remaining congruent with the will of the people. When that will is split because of pre-existing practices and notions of what is good, the process inevitably becomes political. If this change is going to affect civil time, then, politically speaking, the 32-bit end of time is a looming deadline that should serve to motivate an answer about the fate of UTC within the next 10 years. In the mean time we may learn that a fifth fundamental force has implications for the spacetime metric that invalidate all the current time scales in use by astrophysics. As before, the response to that kind of paradigm shift in physical thinking would trigger the creation of yet more time scales to be used by astronomers. The old time scales would remain, unmodified, and less used. On Mon 2003-01-27T17:32:19 -0500, John Cowan hath writ: > I would have no problem with deciding now to change UTC, effective in 2033. Over that interval all the observatories in the world could assuredly handle any change. But in the context of the history of time scales, changing the character of UTC would still be the wrong thing to do. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93
Re: What I do. What do you do?
On Tue 2003/01/28 16:31:03 PDT, Rob Seaman wrote in a message to: [EMAIL PROTECTED] >A useful exercise from other mailing lists and conferences and such >is simply to get to know each other and how we all fit into the puzzle >under discussion. I am a lapsed astrophysicist, currently a programmer with the Australia Telescope National Facility (ATNF, http://www.atnf.csiro.au), a radio observatory. These days I am mainly engaged in developing software for the Parkes radiotelescope (http://www.parkes.atnf.csiro.au) in two spheres: 1) All aspects of general data reduction for the Multibeam system (http://www.atnf.csiro.au/research/multibeam/) including the 21cm HIPASS, ZOA, and HVC surveys of the southern hemisphere. 2) The GUI used for the Telescope Control System (TCS), I also have a finger in several other pies, mostly related to astronomical data reduction. In particular, I am a co-author of the two latest FITS standards documents which deal with astronomical coordinates (http://www.atnf.csiro.au/~mcalabre/WCS). In past years I wrote the high-precision ephemeris routines, ATELIB, (ftp://ftp.atnf.csiro.au/pub/software/atelib/) for the Australia Telescope Compact Array (ATCA, http://www.narrabri.atnf.csiro.au). As an adjunct to this I wrote a software system to collect and parse IERS-A email bulletins and update a database primarily containing information on leap-seconds, the predicted difference between UTC and UT1, and the celestial pole offset. This has been running since 1989 and I continue to maintain it. The IERS-A digest is also used to update the AT Distributed Clock (ATDC, http://www.atnf.csiro.au/technology/electronics/docs/atdc/atdc.html) used at all ATNF observatories and is also sent to Jodrell Bank for their use. My professional interest in UTC: 1) The ATELIB routines require Greenwich apparent sidereal time (GAST) to high precision. The observatory maintains its approximation of TAI using an atomic clock and uses the leap- second and UTC-UT1 tables to compute UT1, and thence GMST and GAST. 2) The TCS GUI provides a separate graphical display of the sky showing a source catalogue and current telescope position. Observers may use this directly to drive the telescope, or, typically, just monitor the telescope position and decide what best to observe next. This display uses unix system time and relies on UTC approximating UT1. A couple of seconds accuracy is enough, but an error of several minutes would be unacceptable. This is especially so for sources near the zenith; the display is based on an equi-rectangular projection scaled by the azimuth and elevation drive rates so sources near the zenith appear to move swiftly across it. My perspective on UTC: 1) As far as ATELIB is concerned, TAI and UT1 are the times of interest and UTC is just a bloody nuisance. ATELIB has to deal with it only because IERS-A tabulates UTC-UT1 rather than TAI-UT1. If the latter was tabulated, then UTC would only be calculated for the sake of our NTP servers and the ATDC display (http://www.atnf.csiro.au/technology/electronics/ - docs/atdc_display/atdc_display.html). And yes, I have had to confront the tedium of engineering software so that it handles leap-second updates that occur during a 12 hour observation. No, I didn't get it right the first time. 2) UTC (civilian time) ought to track the diurnal motion of the Earth just as the Gregorian calendar tracks it's orbital motion - and for the same reason. A practical alternative to the Gregorian calendar - Julian Date, is not used for civilian timekeeping because it is not tied to the annual cycle of the seasons. Even the Julian calendar was not considered accurate enough over the millennia, so, yes, we do have to do some tedious bookkeeping and calculation sometimes. Likewise, a system of diurnal time as a numerical count of SI seconds with no relation to the day, the most important of climatic cycles, would be equally unwelcome. In this context, I should point out an important difference between leap-seconds and leap-days (i.e. leap-years). It would not be practical to construct a calendar containing a fractional number of days because then the new-year and all later days in the year would start at a strange time as measured by the position of the Sun. However, there is no similar impediment to a day containing a fractional number of SI seconds because an SI second is not tied directly to any phenonenon of practical daily interest. I note that, as yet, we have not heard a reasoned argument against my proposal for UTC to measure the true length of day in SI seconds. Mark Calabretta ATNF
Re: Leap-seconds, the epsilon perspective
On Tue 2003/01/28 23:10:07 CDT, John Cowan wrote in a message to: [EMAIL PROTECTED] >I at least care that a *civil* day be 86400 SI seconds in length. This begs the question of why you care. >Mean solar days don't affect me to speak of. We're looking for a solution which will satisfy the broadest spectrum of users with the least inconvenience. >What for? Why should we (the people of the Earth) care about mean >solar days? For some purposes, apparent solar time is important, but >most of the time it's civil time that counts. Why should that be tied >to mean solar days? Would you consider measuring civil time as a non-cyclic count of SI seconds, akin to Julian Date? >Hmm. How reasonable is it to expect this to change in future? Personal clocks might well become more accurate, but the ABC would still start its programs five minutes late so my VCR's millisecond accuracy would be wasted. Buses would still run at semi-random times, and I would still be woken by the Koels before my alarm clock went off at precisely 07:30:00.000! Mark Calabretta ATNF
Re: What problems do leap seconds *really* create?
On Wed 2003/01/29 15:53:08 CDT, William Thompson wrote in a message to: [EMAIL PROTECTED] >Any application which seeks to calculate the difference in time between two >events recorded in UTC time needs to know if there are any leap seconds between >the start and stop time. For example, suppose you were studying solar flares, >and analyzing some data taken in 1998, and you saw a burst of hard X-rays at >23:59:53 UT on Dec 31, followed by a rise in EUV emission at 00:00:10 UT the >next day. You'd think that the delay time between the two would be 17 seconds, >but it's really 18 seconds because of the leap second introduced that day. >That's a vital difference for the scientific analysis of the data. It is instructive to look at this from the 86400+epsilon point-of-view. In that scenario, there would be no leap-seconds but a proper calculation of the time difference would always require epsilon to be considered. Thus the time span would be 17+epsilon seconds. However, the error introduced by ignoring epsilon (currently 2ms) would be 1 part in 10,000 rather than 1 in 18 by ignoring the leap-second. Over longer timespans the fractional error would decrease progressively and flatten off after about 18 months to roughly 1 part in 10^8. Only very high precision measurements would care about such an error. The only way to produce a large fractional error would be to difference two times a few millisec on either side of the change-of-day, an improbably occurrence. Mark Calabretta ATNF
Re: What problems do leap seconds *really* create?
On Wed 2003/01/29 15:43:24 PDT, Rob Seaman wrote in a message to: [EMAIL PROTECTED] >Basically we don't have leap seconds because the Earth's rotation is >slowing down (by transfering angular momentum to the Moon). Rather, >we have leap seconds because the Earth has *already* slowed down since >1900. See the rather consistent slope of about 7 seconds per decade >on the plot of UT1-UTC (with leap seconds removed) versus date: >ftp://gemini.tuc.noao.edu/pub/seaman/leap/noleap.pdf > >The current dynamical effects are the subtle wiggles imposed on this >trend. This is actually a fairly useful bias since it guarantees (short >of asteroid impact or armageddon) that there will be no negative leap >seconds. > >Again, please note how consistent the divergence is between atomic >and Earth timescales over decade long periods. Where precisely is the >urgency to adopt a quick fix? I agree with you that there is plenty of time to make an informed decision, that nothing need be done on a timescale of decades, and also that the process to date appears, at least to some of us, to have bordered on Machiavellian, though I'm sure it was not. It's also true that the leap-seconds we have now do come from the slowdown since 1900. However, your "consistent slope of about 7 seconds per decade" obscures the basic point about the long term future of UTC. Your graph shows a linear approximation to what is actually a parabola. The graph in the "GPS World" article shows the long term trend much better. Though its fit to a parabola is not much more convincing - we do know that it is a parabola because the physics of the Earth-Moon dynamical system tells us so. The wiggles are caused by the motion of dense material in the Earth's mantle which cause the Earth's moment of inertia to vary unpredictably, thus causing it to spin up as well as down. They are what leap-seconds were originally designed to handle, not the predictable, long-term secular deceleration of the Earth's rotation. Thus, what is 7 seconds per decade now will become 35 seconds per decade in another two hundred years time. When you add up all those so-many-seconds per decade over the next 20 decades the cumulative error runs to many minutes - already nearly 60s by 2050 according to the GPS World article, not 35s by a linear extrapolation, and more than 140s by 2100, double the linear-extrapolated value. The cumulative error grows quadratically; that is the problem. Mark Calabretta ATNF
Re: Leap-seconds, the epsilon perspective
Mark Calabretta scripsit: > >Mean solar days don't affect me to speak of. > > We're looking for a solution which will satisfy the broadest spectrum > of users with the least inconvenience. I meant "me as random citizen", not "me as me". > >What for? Why should we (the people of the Earth) care about mean > >solar days? For some purposes, apparent solar time is important, but > >most of the time it's civil time that counts. Why should that be tied > >to mean solar days? > > Would you consider measuring civil time as a non-cyclic count of SI > seconds, akin to Julian Date? No, primarily because it's not mnemonic enough, so it doesn't have enough error correction. But if people can cope with clocks that read 1400 or even 1500 close to solar noon, a maximum drift of 59 minutes from apparent time to civil time can't be that awful. -- John Cowan <[EMAIL PROTECTED]> http://www.ccil.org/~cowan "One time I called in to the central system and started working on a big thick 'sed' and 'awk' heavy duty data bashing script. One of the geologists came by, looked over my shoulder and said 'Oh, that happens to me too. Try hanging up and phoning in again.'" --Beverly Erlebacher
Re: What problems do leap seconds *really* create?
Mark Calabretta says: > I agree with you that there is plenty of time to make an informed > decision, that nothing need be done on a timescale of decades, and > also that the process to date appears, at least to some of us, to > have bordered on Machiavellian, though I'm sure it was not. I'm glad the subtleties in my arguments haven't been lost :-) > However, your "consistent slope of about 7 seconds per decade" > obscures the basic point about the long term future of UTC. Your > graph shows a linear approximation to what is actually a parabola. Indeed. The biggest problem I've seen with this discussion since the beginning is a too eager willingness to move into a sky-is-falling debate about extremely long term effects. Perhaps I over simplified as a result. That UT1 and TAI are diverging quadratically can be used to strengthen the argument for civil time to track the former - after all, day will turn into night all the quicker. The question under discussion has never been how to *improve* UTC and civil time. In fact, it appears that a committee met exactly once and voted to reject all possible options except for discarding the standard entirely. Now, either that committee has also been discussing this issue privately on some other forum that is closed to us - or they haven't been discussing it at all. I'm not sure at which of these options I'd be more offended. Rob Seaman National Optical Astronomy Observatory
Re: What problems do leap seconds *really* create?
On Wed, Jan 29, 2003 at 07:04:23PM +, Markus Kuhn wrote: > Who really needs to maintain a full list of leap seconds and for what > application exactly? If a file storage system stores timestamps as "SI seconds since some epoch", and a legal question arises about whether a given document was stored on that system before or after midnight on some given date, the logic which converts the timestamp to a UTC date will need to know how many leap seconds to adjust for, which in the general case means that the logic converting these file-timestamps into UTC will need a full list of leap seconds. (Just answering the asked question; I make no claim that any system which might realistically be involved in the above scenario would have any difficulty in maintaining such a list.) --Ken Pizzini
Re: Telescope pointing and UTC, was: Re: What I do. What do you do?
On Wed 2003-01-29T22:14:35 -0800, Ken Pizzini hath writ: > You lost me on this: you require sub-second UT1, which means that > you have some means of inputting either UT1 or UTC-UT1 besides > feeding in the standard time broadcasts. The standard time broadcasts contain estimates of DUT1, the difference between UTC and UT1, to an accuracy of 0.1 s. See http://www.boulder.nist.gov/timefreq/stations/iform.html#ut1 http://inms-ienm.nrc-cnrc.gc.ca/time_services/chu.html The GPS frames contain the information needed to compute DUT1, but not a direct estimate as the shortwave signals do. Mark Calabretta just mentioned an operational system using another means of getting DUT1, which is to scrape it off the web pages of the earth rotation agencies. It is our presumption that the contractor delivering this new telescope will choose one of these means in order to meet the pointing accuracy specifications, but at this stage we do not know which means will be chosen. > Why would the means of > injecting this input be tightly integrated with the observing > programs, rather than designing the obeserving programs to take > a declaration of "this is my best effort at UT1" as input, and > having a thin, readily replaced, interface doing whatever translation > it is that you need to do with UTC (as it exists now) to give you your > sub-second UT1? I have no idea what this question is asking. In order to point the telescope accurately it is necessary to know the sidereal time, and that is computed directly from UT1 and the longitude of the telescope. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93
