Re: Wall Street Journal Article
On Aug 1, 2005, at 12:51 PM, Poul-Henning Kamp wrote:
I think we should give Rob the benefit of the doubt and let him
elaborate on this, I don't think anybody who argues for the
leapsecond quirks of UTC to be retained would advocate changing the
SI second, so he must mean something else...
Here is what I said in the referenced document, http://iraf.noao.edu/
~seaman/leap,
("watch A" means atomic time, "watch E" means solar time):
"Similarly adjusting watch A's rate, which is equivalent to
M&K's "Redefine the Second" is obviously a proposal that would be
denounced by every physical scientist and engineer on the planet."
And later:
"Eventually the leap second pace will indeed accelerate to the
point that a monthly (or even weekly or daily) rate fails to sample
the underlying waveform acceptably well. At that point - what? Will
our multi-millennial grandchildren find it reasonable to allow their
clocks to register day for night? Perhaps the thought is that some
entirely different clock will be used (one imagines some futuristic
variation on a "metric" clock). What difference does that make? The
same underlying issues will remain. The rates between the Earth and
the Atomic (or Antimatter :-) clocks will diverge and some scheme
will be needed to synchronize them.
So - they will need to find some reasonable revision of the
fundamental unit of time. Or more likely, they will define a civil
second that is some fraction longer than the "scientific" second. And
then they will continue to issue leap seconds on a palatable schedule
according to the Earth's whims. (The future PTTI community would have
the freedom to select an epoch for such a change that would
correspond to some nice round number or even ratio of fundamental
physical constants, and thus perhaps even simplify the handling of
time units.)
Redefine the unit to match the long term variation. Schedule
leap seconds for the short term deviations. That is - adjust watch
A's rate every few millennia AND reset watch E in between."
It doesn't surprise me that few will have read my little counter-
proposal. I'm sure the folks on the SRG/ITU committee have paid
precious little attention to this mailing list since its inception.
A little time spent on Steve Allen's web site (http://www.ucolick.org/
~sla/leapsecs) could raise the level of discourse significantly.
In general, both sides talk about far distant times to try to make
points about current policies. It is a rare message in this debate
that doesn't have something pertinent (no matter how repetitive) to
contribute. Unfortunately, we have nothing to talk about since the
process has been short circuited by the "solution" imposed by the ITU.
Rob Seaman
National Optical Astronomy Observatory
Re: Wall Street Journal Article
On Mon 2005-08-01T15:40:58 -0400, John.Cowan hath writ: > As should be eminently clear by now, I absolutely oppose leaps of any kind, > whether seconds or hours, in universal time (lower case generic term). > Hours are certainly worse than seconds in this respect. Sic semper faciebamus. Since the inception of clocks and the use of sexagesimal format for communicating time of day -- we've always done it this way. The whole point of the 24:60:60 notation is to match up with the day. In order to do that all civil time scales have always had leaps or seconds of non-uniform length or both. Dynamical time and atomic time have no such concept and should always have been communicated as a decimal count of elapsed seconds. Confusing the one entity with the other in the original definition of Ephemeris Time was perhaps the biggest timekeeping mistake ever made by astronomers. Not following the suggestion to define the cesium-based, Ephemeris-Time-inspired unit of duration as a new unit called the Essen was perhaps the biggest timekeeping mistake ever made by physicists. Allowing civilian entities to believe that the broadcast time signals originally intended for navigation could also be used for setting civil time was perhaps the biggest timekeeping mistake ever made by the CCIR (now ITU-R) and all the national time services. But the cascade of all of these historical booboos has created a set of sociological, technological and legal easements which cannot easily be abolished. In legal dealings with land use one cannot abolish such right-of-ways without unanimous agreement or a public court process. > Eventually that will become impossible. When solar days are 48 (current) > hours long, we will just have to get used to the idea that every other > waking period is in darkness. Duncan Steel made the point very well in his book on calendars: there is no point in trying to create a scheme which is expected to be valid for more than 1000 years. Nobody is worried about 4 years hence when the analemma of mean solar time has tilted back and forth twice and a leap second is needed every day, but the new GPS interface control documents specify a new counter of leap seconds which will serve for 3 years. The issue is whether to replace an existing system that matches the practice of all history but will fail in about 1200 years with a new system that violates the practice of all of history and will fail in about 600 years. There should be no rush to do this without considering all alternatives and coming to a broad consensus. -- Steve Allen <[EMAIL PROTECTED]> WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165 Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, "John.Cowan" writes: >Eventually that will become impossible. When solar days are 48 (current) >hours long, we will just have to get used to the idea that every other >waking period is in darkness. I think you overlook the biological adaptability here. Our circadian rythm is not close to 24 hours by accident. >> As I said more than four years ago (http://iraf.noao.edu/ >> ~seaman/leap), in the far future there are few options other than >> readjusting the length of the civil second to recalibrate to match >> the slowing Earth. > >What, and recalculate every single measurement ever made involving >length or duration? A complete nightmare. I think we should give Rob the benefit of the doubt and let him elaborate on this, I don't think anybody who argues for the leapsecond quirks of UTC to be retained would advocate changing the SI second, so he must mean something else... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Wall Street Journal Article
Rob Seaman scripsit: > No one has ever claimed that solar time won't face a challenge in the > far future. This proposal does absolutely nothing to address these > challenges - in fact, it complicates the issues by introducing a huge > unpalatable time step that will be no more predictable than leap > seconds. As should be eminently clear by now, I absolutely oppose leaps of any kind, whether seconds or hours, in universal time (lower case generic term). Hours are certainly worse than seconds in this respect. I do favor the idea of adjusting T LCT-UTC offsets as needed. > And to clarify, it isn't solar time that faces this challenge - it > will be atomic time. The Earth will continue to circle the Sun and > spin on its axis with enviable reliability. It is our simplified > model of the tick, tick, tick of time that will fall short. Civil > time will obviously continue to be synchronized to the Sun. Eventually that will become impossible. When solar days are 48 (current) hours long, we will just have to get used to the idea that every other waking period is in darkness. > As I said more than four years ago (http://iraf.noao.edu/ > ~seaman/leap), in the far future there are few options other than > readjusting the length of the civil second to recalibrate to match > the slowing Earth. What, and recalculate every single measurement ever made involving length or duration? A complete nightmare. -- I am expressing my opinion. When myJohn Cowan honorable and gallant friend is called, [EMAIL PROTECTED] he will express his opinion. This is http://www.ccil.org/~cowan the process which we call Debate. --Winston Churchill
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >> this is only economically feasible in very critical systems. > >Economics is the "dismal science". If there is any validity at all >to describing it as a science, inferences must be based on coherent >experimental design. Where is the evidence that ceasing leap seconds >won't be more expensive than continuing them? Should this not be >part of any viable proposal? Economics is not science. Economics is the current reality since everything these days is (made) a matter of money. And despite the fact that absense of evidence is not evidence of absense, it would strengthen your case a lot if you can come up with at least one relevant documented system that will get in trouble by the change and which incurs significant cost because of it. If one such case were to be put on the table, the proponents of abolishing leap seconds can no longer say "that is never a problem", but will have to address your claim. So far, I have not seen anything documented that would not be considered "trivial costs" in this context. [various snide comments ignored] >>> I hope this API will one day be replaced by a much simpler and >>> more generic one. >> >> We can only hope, but to do so you'd have to get buyin from at >> least [4xfooBSD, Linux, Dave Mills, Solaris, AIX] Of these Dave >> Mills is probably the harder one. > >He's always seemed reasonable to me. Dave is very reasonable, that is why he probably will be very disinclined to change an ABI which works, even if it is unelegant. >These are all very interesting questions. Why don't we simply drop >this silly ITU proposal and finally start discussing the fundamental >issues? Funny you should say that... Whenever we try to raise some of the fundamental issues, we get told by you that our computer systems should just be "done right" and that anything involving money is not relevant unless it is the astronomers money. Faced with that, we on the other side take a similar polarized position: "forget the astronomers if they are that disconnected from the real world". Quite frankly Rob, I think you are your opponents best argument right now because you are being patently unreasonable and unflexible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Wall Street Journal Article
Poul-Henning Kamp replies to Markus Kuhn: No. The leapsecond support, like any other operating facility examine and reject illegal data. Leapseconds and *defined* as happening on midnight at the end of a month and the operating system should not allow them anywhere else. I was reminded once that there is no good or bad karma, only karma. There are no illegal data - only data. As we are seeing, what is illegal today may be legal tomorrow - or the reverse. Definitions can change; well written software takes this into account. The kernel restricts itself to checking the midnight part, and that is a sensible shortcut. This is not a shortcut. This is the implementation of a design requirement. A layered design like NTP should, and apparently does, introduce only those restrictions into each interface that are strictly required. If a requirement is to "reject illegal data", those data should typically be rejected only by the externally visible layers of the system. this is only economically feasible in very critical systems. Economics is the "dismal science". If there is any validity at all to describing it as a science, inferences must be based on coherent experimental design. Where is the evidence that ceasing leap seconds won't be more expensive than continuing them? Should this not be part of any viable proposal? It also doesn't seem to be a winner of an argument to point out that the proposal seeks to benefit "not very critical" systems. And from a testing point of view, the UNIX computers are almost the smallest bits, it's all the weird crap people connect to them that makes testing a problem. Ah yes! The ITU proposal seeks to benefit "weird crap", too. I don't recall seeing that mentioned. Certainly no reason to expect that devices attached to computers be governed with similar professionalism as the computers themselves. Incompetent test design is an orders of magnitude heavier stone... Ohh, I fully agree, but that doesn't justify forcing a basically untestable concept like leap seconds on the morons. So "leap second users" are no longer simply world citizens, now they are to be regarded as morons? That'll go over big in front of a Congressional subcommittee. I hope this API will one day be replaced by a much simpler and more generic one. We can only hope, but to do so you'd have to get buyin from at least [4xfooBSD, Linux, Dave Mills, Solaris, AIX] Of these Dave Mills is probably the harder one. He's always seemed reasonable to me. And lots of reasonable people will have to ultimately reinvent the delivery of GMT to support traditional usage far afield of astronomy. John Cowan says: The real problems arrive when it is impossible to pretend any longer that a day consists of 24 hours. When, say, every third TAI second is a UTC leap second, and we have to fit three sleep/wake cycles into two solar days, we hopefully won't be hearing quite so much about the vital importance of keeping civil time slaved to the mean Sun. No one has ever claimed that solar time won't face a challenge in the far future. This proposal does absolutely nothing to address these challenges - in fact, it complicates the issues by introducing a huge unpalatable time step that will be no more predictable than leap seconds. And to clarify, it isn't solar time that faces this challenge - it will be atomic time. The Earth will continue to circle the Sun and spin on its axis with enviable reliability. It is our simplified model of the tick, tick, tick of time that will fall short. Civil time will obviously continue to be synchronized to the Sun. It is absurd to suggest that our descendants will cease to care about the rising of the Sun. Is that a future you want for your children's children? As I said more than four years ago (http://iraf.noao.edu/ ~seaman/leap), in the far future there are few options other than readjusting the length of the civil second to recalibrate to match the slowing Earth. This will obviously happen well before 8 leap hours are needed daily (something like 1.5 billion years from now). These are all very interesting questions. Why don't we simply drop this silly ITU proposal and finally start discussing the fundamental issues? It would be refreshing for the committee members to actually respond to our messages. Rob Seaman National Optical Astronomy Observatory
Re: Wall Street Journal Article
Poul-Henning Kamp scripsit: > For those of us who work in environments where "the system" is not > a PC, but rather something that takes a lot of racks which contain > computers interconnected with other stuff WMvare will just not cut it. Or worse yet, a small embedded device that depends on NTP directly. -- Do I contradict myself? John Cowan Very well then, I contradict myself.[EMAIL PROTECTED] I am large, I contain multitudes. http://www.ccil.org/~cowan --Walt Whitman, Leaves of Grass http://www.reutershealth.com
Re: Wall Street Journal Article
Markus Kuhn scripsit: > I don't see any technical problems for existing mechanisms to deal with > leap seconds until we need more than one leap second per day. The real problems arrive when it is impossible to pretend any longer that a day consists of 24 hours. When, say, every third TAI second is a UTC leap second, and we have to fit three sleep/wake cycles into two solar days, we hopefully won't be hearing quite so much about the vital importance of keeping civil time slaved to the mean Sun. -- John Cowan www.reutershealth.com www.ccil.org/~cowan [EMAIL PROTECTED] Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, The day and hour soon are coming / When all the IT folks say "Gosh!" It isn't from a clever lawsuit / That Windowsland will finally fall, But thousands writing open source code / Like mice who nibble through a wall. --The Linux-nationale by Greg Baker
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, Markus Kuhn writes: >Whenever I test leap seconds in an operating system function, I simply >insert one leap second, and a short time later, I delete another one. In >between, I run test software that shows me the evolution of the 1-second >time offset relative to a comparison system that does not execute the >test leap seconds. If the API you are testing requires you to jump to >the end of June or December, then it simply is a very badly designed API >and should be redone. No, it is an API which is carefully designed to reject illegal or invalid leapsecond information. The NTP kernel support will allow leapseconds on any midnight, but the NTP daemon is more strict. >The API of a kernel clock driver should be able to >schedule the insertion and deletion of a leap second any any start of a >UTC second, usually expressed in POSIX's "Seconds Since the Epoch" >scale. No. The leapsecond support, like any other operating facility examine and reject illegal data. Leapseconds and *defined* as happening on midnight at the end of a month and the operating system should not allow them anywhere else. The kernel restricts itself to checking the midnight part, and that is a sensible shortcut. But even having to test it at midnight means stepping the clock when testing. >In addition, it is always good practice to keep test and operational >environments strictly separated, for any sort of test, not just those >involving clocks. You should know that this is only economically feasible in very critical systems. >(With virtalization tools such as Xen or VMware, it >have become very easy to run such tests completely isolated on the same >hardware.) Yes, that's very nice if your concept of "the system" involves the PC on your desk. For those of us who work in environments where "the system" is not a PC, but rather something that takes a lot of racks which contain computers interconnected with other stuff WMvare will just not cut it. And from a testing point of view, the UNIX computers are almost the smallest bits, it's all the weird crap people connect to them that makes testing a problem. >> Leapseconds is such a stone for real-world IT installations. > >Incompetent test design is an orders of magnitude heavier stone... Ohh, I fully agree, but that doesn't justify forcing a basically untestable concept like leap seconds on the morons. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Wall Street Journal Article
Poul-Henning Kamp wrote on 2005-07-31 08:12 UTC: > >They're not broken. > > It was my distinct impression from reading > http://www.ucolick.org/~sla/leapsecs/dutc.html > that in a mere couple of thousand years, we will have more > than 12 leap seconds a year. > > That sounds broken to me. I don't see any technical problems for existing mechanisms to deal with leap seconds until we need more than one leap second per day. On the contrary, weekly or daily leap seconds will simply make it less necessary to insert test leap seconds when you design clock drivers, as the real thing will happen often enough. I have yet to see any piece of code or message format that assumes about the time of a leap second anything other than that it happens at the end of a UTC day. Humanity is facing far more interesting challenges before the need for intruducing 23:59:61 becomes acute in a few ten thousand years from now, (including, hopefully, the abolishion of our archaic base-60 time notation). Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Wall Street Journal Article
Poul-Henning Kamp wrote on 2005-07-31 06:23 UTC: > >> I have three times been through what ended up being total reinstalls > >> from backups because some operator by accident (or stupidity) set > >> the clock forward in time and then backward in time on a database > >> installation. > > > >Are you asserting that these problems had something - anything at all > >- to do with leap seconds? > > No, they had everything to do with computers don't liking time to > jump around. > > In order to test leapsecond handling, you need to jump the time > forward to end of june or december, afterwards you need to jump it > back. Whenever I test leap seconds in an operating system function, I simply insert one leap second, and a short time later, I delete another one. In between, I run test software that shows me the evolution of the 1-second time offset relative to a comparison system that does not execute the test leap seconds. If the API you are testing requires you to jump to the end of June or December, then it simply is a very badly designed API and should be redone. The API of a kernel clock driver should be able to schedule the insertion and deletion of a leap second any any start of a UTC second, usually expressed in POSIX's "Seconds Since the Epoch" scale. I fail to see, why a leap-second test should require major disruptions in the monotonicity of your OS clock. In addition, it is always good practice to keep test and operational environments strictly separated, for any sort of test, not just those involving clocks. (With virtalization tools such as Xen or VMware, it have become very easy to run such tests completely isolated on the same hardware.) > Leapseconds is such a stone for real-world IT installations. Incompetent test design is an orders of magnitude heavier stone ... with or without leap seconds. I see leap seconds more as one one among thousands of things that can go wrong with computers, and not one that has good prospect of ever featuring prominently as a root cause in software failure statistics. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Wall Street Journal Article
On Jul 31, 2005, at 12:19 AM, Poul-Henning Kamp wrote:The topic is: why do IT installations and manufacturers not test leap-seconds. The answer is: because it costs too much.Bull! They don't test against UTC (the full force of an international standard) because they are ignorant of the need to do so. One more time - the solution to ignorance is education, not dumbing down the curriculum. Leap seconds represent a real world constraint. The commercial world is expected to deal with other real world constraints. And, of course, there is the little matter that nobody has bothered to conduct a meaningful survey of the commercial communities no more than the technical communities. The fact that some may have ignored elementary real world tests doesn't imply that their competitors were so cavalier.We're all entitled to our own realities. Yours seem to not coincide with the IT industry to any great extent.George Orwell would be proud: the Sun is fantasy and the IT industry, reality.I don't hear the counter proposal from the astronomers to fix leap seconds.You don't perceive even the possibility of risks associated with disconnecting civil time from solar time - therefore such risks don't exist. You don't hear a counter proposal - therefore such proposals don't exist. Piaget tells us that children should achieve object permanence by the age of two.As Steve Allen says, leap seconds ain't broken. The current standard is viable for hundreds of years. Replacing it with another that guarantees a colossal headache on a similar time scale is daft. But if you want a counter proposal, see http://iraf.noao.edu/~seaman/leap, originally submitted to this list more than four years ago. The current standard is fine - the only problem is that we aren't taking full advantage of it. I'm sure the clever fellows currently wasting their time pushing the ITU proposal could come up with something better than my counter proposal. It sure would be more fun to seek a consensus for improving civil time, rather than continuing to pursue this one-dimensional failure of a debate - in a more and more public arena.Rob SeamanNational Optical Astronomy Observatory
Re: Wall Street Journal Article
On Jul 30, 2005, at 11:23 PM, Poul-Henning Kamp wrote: When you start out on a long march, you don't put a stone in your boot deliberately, and if one is there already, you take it out. Leapseconds is such a stone for real-world IT installations. No. Leap seconds are the real world. Your long march, like others before, is a retreat from reality. If I were a professional astronomer, I would be busy with all those things, but as it is, I have not a single computer anywere which will be negatively affected by missing leap seconds. A) Why do you believe that astronomers are not preparing for the worst - an unfunded, unnecessary, naive and senseless mandate that will likely cost us millions? B) You better hope you are right - a lack of imagination is poor protection. The short cut of eliminating leap seconds will introduce more risks than it will avoid. I thought I heard some astronomer say in this discussion that all applications which need proper timekeeping should use TAI ? Hearing voices again? There is no one single solution to all problems in time. There are many different time scales that are appropriate for different purposes. I would be just as upset if the time lords were attempting to subvert TAI - which, as a matter of fact, they are. If they want to celebrate TAI, simply base civil time directly on TAI, not some odd number of seconds difference that will forever confuse "users" (meaning anybody with a clock). At least now we get bulletins a couple of times per year that explicitly provide the formula for converting between civil time and TAI. Rob Seaman National Optical Astronomy Observatory
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, Steve Allen writes: >On Sun 2005-07-31T09:19:40 +0200, Poul-Henning Kamp hath writ: >> I don't hear the counter proposal from the astronomers to fix leap >> seconds. > >They're not broken. It was my distinct impression from reading http://www.ucolick.org/~sla/leapsecs/dutc.html that in a mere couple of thousand years, we will have more than 12 leap seconds a year. That sounds broken to me. If for some reason astronomers don't think that is broken, then I can't see the logic in claiming that a leap-hour 500 years down the road is broken. >All the surveys which were taken in the past six years indicate that >the majority of time users believe this to be the case. They also >indicate that there is no consensus about whether there needs to be a >change, let alone about what that change might be. Right, and that's why the major industrial states are not doing anything about global warming either: They're not sweating more than they used to. >> Is this discussion really just about astronomers trying to make >> sure this doesn't happen in their lifetime, and if not, why are >> there no counter proposals for a better solution ? > >When the Wall Street Journal reporter called them why did the >proponents of abolition either provide the same old and unjustified >explanations or avoid talking altogether? He didn't call me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Wall Street Journal Article
On Sun 2005-07-31T09:19:40 +0200, Poul-Henning Kamp hath writ: > I don't hear the counter proposal from the astronomers to fix leap > seconds. They're not broken. All the surveys which were taken in the past six years indicate that the majority of time users believe this to be the case. They also indicate that there is no consensus about whether there needs to be a change, let alone about what that change might be. > Is this discussion really just about astronomers trying to make > sure this doesn't happen in their lifetime, and if not, why are > there no counter proposals for a better solution ? When the Wall Street Journal reporter called them why did the proponents of abolition either provide the same old and unjustified explanations or avoid talking altogether? The content of that front page story was vetted for over two weeks, and the words "secret" and "secrecy" survived the WSJ editorial process. Why would the proponents risk such a public result? -- Steve Allen <[EMAIL PROTECTED]> WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165 Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, Steve Allen writes: >On Sun 2005-07-31T08:23:30 +0200, Poul-Henning Kamp hath writ: >> No, they had everything to do with computers don't liking time to >> jump around. > >But the reality is that no computer system (or any system, for even >NIST and USNO don't know what the value of TAI and UTC is until next >month) can guarantee that it always knows what time it is. Non sequitur. The topic is: why do IT installations and manufacturers not test leap-seconds. The answer is: because it costs too much. >> When you start out on a long march, you don't put a stone in your >> boot deliberately, and if one is there already, you take it out. >> >> Leapseconds is such a stone for real-world IT installations. > >In this sense leap seconds give the system designer the opportunity >and incentive to face reality instead of ignoring it. Taking away >leap seconds will not fix this. We're all entitled to our own realities. Yours seem to not coincide with the IT industry to any great extent. >> I'm pointing out that UTC with leap seconds is unsafe at any speed. > >Presuming that the system clock is always right is delusional. Non sequitur again. >> It would have been much smarter to use TAI, wouldn't it ? I thought >> I heard some astronomer say in this discussion that all applications >> which need proper timekeeping should use TAI ? > >If "proper timekeeping" means time as defined by physics then: >All applications which need proper timekeeping in the reference frame >of the solar system should use TCB. >All applications which need proper timekeeping in the terrestrial >environment should use TCG. >All applications which need proper timekeeping on the surface of the >earth should use TT. >These are the recommendations from astronomers to everyone. > >But these are not practical time scales. [...] So why would astronomers be recommending them ? >> And if anything, if astronomers switched to TAI on 2008-01-01 they >> would not run into this problem in the future. > >TAI is a practical time scale, but its seconds are not of constant >length. [...] Considering that we're comparing to a timescale which would be off by an hour in 600 years, I think these effects can be ignored for now and astronomy could use TAI profitably. >> I think the sneakage happened in 1972 and we're trying to evict it. > >Leap seconds were proposed and instituted by the physicists who ran >the atomic clocks. They were opposed by many astronomers, but after >the shouting stopped (and in the proceedings of the IAU GAs it is >evident that there was shouting) the astronomers agreed that UTC as SI >seconds with leap seconds was the best option. But let me turn this around for a second: I don't hear the counter proposal from the astronomers to fix leap seconds. I hear whinage about leap hours (which might or might not happen, depending on what scientists in the next 500 years decide) but I don't hear anything about how to fix UTC when leapseconds no longer are able to cope with the rate of DUT1 change. Is this discussion really just about astronomers trying to make sure this doesn't happen in their lifetime, and if not, why are there no counter proposals for a better solution ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Wall Street Journal Article
On Sun 2005-07-31T08:23:30 +0200, Poul-Henning Kamp hath writ: > No, they had everything to do with computers don't liking time to > jump around. But the reality is that no computer system (or any system, for even NIST and USNO don't know what the value of TAI and UTC is until next month) can guarantee that it always knows what time it is. If the system does not know what time it is (at boot time, or if the system does not have radio or network connectivity) then the system clock can be wrong. If the system clock can be wrong then the system either has to admit that it does not care that it is wrong or the system has to have procedures for correcting that wrongness. The system can correct the wrongness either by changing the length of seconds or by resetting (leaping) the system clock. > When you start out on a long march, you don't put a stone in your > boot deliberately, and if one is there already, you take it out. > > Leapseconds is such a stone for real-world IT installations. In this sense leap seconds give the system designer the opportunity and incentive to face reality instead of ignoring it. Taking away leap seconds will not fix this. > I'm pointing out that UTC with leap seconds is unsafe at any speed. Presuming that the system clock is always right is delusional. > It would have been much smarter to use TAI, wouldn't it ? I thought > I heard some astronomer say in this discussion that all applications > which need proper timekeeping should use TAI ? If "proper timekeeping" means time as defined by physics then: All applications which need proper timekeeping in the reference frame of the solar system should use TCB. All applications which need proper timekeeping in the terrestrial environment should use TCG. All applications which need proper timekeeping on the surface of the earth should use TT. These are the recommendations from astronomers to everyone. But these are not practical time scales. They are Platonic ideals. Some sort of conversion needs to be applied in order to compare them with practical time scales. The algorithms for that conversion are not trivial -- they involve complex numeric calculations. This is a fact of life that cannot be defined away. > And if anything, if astronomers switched to TAI on 2008-01-01 they > would not run into this problem in the future. TAI is a practical time scale, but its seconds are not of constant length. Even if TAI were the result of perfect atomic clocks, TAI currently ignores the diurnal GR effects of changing depth in the gravitational potentials of solar system objects. Someday TAI will have to incorporate those currently-too-subtle effects of the passage of proper time for every given clock. TAI is unarguably the best time scale for use in telecommunications, but that does not make it perfect. And even if TAI were perfect that does not make it the best time scale for civil time. > I think the sneakage happened in 1972 and we're trying to evict it. Leap seconds were proposed and instituted by the physicists who ran the atomic clocks. They were opposed by many astronomers, but after the shouting stopped (and in the proceedings of the IAU GAs it is evident that there was shouting) the astronomers agreed that UTC as SI seconds with leap seconds was the best option. -- Steve Allen <[EMAIL PROTECTED]> WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165 Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >On Jul 30, 2005, at 12:05 AM, Poul-Henning Kamp wrote: > >> I have three times been through what ended up being total reinstalls >> from backups because some operator by accident (or stupidity) set >> the clock forward in time and then backward in time on a database >> installation. > >Are you asserting that these problems had something - anything at all >- to do with leap seconds? No, they had everything to do with computers don't liking time to jump around. In order to test leapsecond handling, you need to jump the time forward to end of june or december, afterwards you need to jump it back. Since operating systems and databases in particular croak when you do that, testing for leapseconds is a major nightmare which takes very significant down time to accomplish. >Poor management of software >systems doesn't seem like a strong justification - or even >rationalization - for changing a completely unrelated international >standard. When you start out on a long march, you don't put a stone in your boot deliberately, and if one is there already, you take it out. Leapseconds is such a stone for real-world IT installations. >The solution to ignorance - what you so generously characterize as >"stupidity" - is education. I agree in principle, but who is going to pay for it ? And your plan looks a lot more feasible once you get a written confirmation from all operating system vendors that they will not release a product if the actual code has not correctly handled a real leap second. >You are really just supporting the tired >old notion of security through obscurity. As the traffic school cop >pointed out: there are no accidents, only collisions. Close, but no cigar: I'm pointing out that UTC with leap seconds is unsafe at any speed. >> Your workstation is not an "IT installation", it is just a >> workstation. > >I was our Y2K team lead. For that period of time, my workstation was >one of the primary development systems for an image processing >software package used by half the astronomers in the world. I'm sorry Rob, but this was what is normally called "a toy application" in the context of Y2K. >Why are we not discussing what new data structures, APIs, transport >protocols, deployed systems, operating procedures, staffing and >management issues will be necessary to implement such a major change >less than two-and-a-half years hence? How is it that this "proposal" >is completely devoid of any discussion whatsoever of its >implementation and ramifications? I think it is mainly because the people most in need of those facilities are being BHA's about the entire thing and therefore do not seem to prepare for the very likely situation that they won't get things their way. If I were a professional astronomer, I would be busy with all those things, but as it is, I have not a single computer anywere which will be negatively affected by missing leap seconds. In that situation I don't really see the political soundness in me imposing my ideas how to solve these problems on an astronomical community which doesn't seem receptive to the need. But if you find out that you're going to prepare for it, I'll be more than happy to assist anyway I can. Getting DUT1 into the NTP protocol would be one option (but unless stratum 1 servers can get hold of DUT1 it doesn't really help us that much). >UTC is the equivalent of ISO 8601 for the purpose of this never- >ending discussion. No, if that were so, it would be ISO that decided the fate of leap seconds. As it is, ISO8601 references UTC and is therefore based on UTC. >In point of fact, many ISO 8601 compliant strings >embedded in your databases implicitly assert that UTC ~ GMT. Doesn't that mean that your database contains baseless assumptions ? As I said earlier: it sounds a lot to me like astronomers made a blunder when they used UTC without realizing that the properties of that timescale is not in their control. It would have been much smarter to use TAI, wouldn't it ? I thought I heard some astronomer say in this discussion that all applications which need proper timekeeping should use TAI ? >Whatever happens to leap seconds in the future, proper interpretation >of your archival records will continue to depend on interpolating the >appropriate leap seconds. You mean "just like the rest of astronomys N thousand years of records ?" Some years ago I read with great interest about the problems trying to nail Tycho Brahes observations to a usable timescale, and I can't for the life of me think that the necessary interpretation of UTC is any harder. And if anything, if astronomers switched to TAI on 2008-01-01 they would not run into this problem in the future. >Or actually - not. Precisely because UTC >~ GMT, typical civil usage allows you to completely ignore leap >seconds when interpreting past data records. Are you saying the reason we have leap seconds is because they allow astronomers to b
Re: Wall Street Journal Article
On Jul 30, 2005, at 12:05 AM, Poul-Henning Kamp wrote:I have three times been through what ended up being total reinstallsfrom backups because some operator by accident (or stupidity) setthe clock forward in time and then backward in time on a databaseinstallation.Are you asserting that these problems had something - anything at all - to do with leap seconds? If you were the one cleaning up the mess, presumably you had something to do with hiring the operators and documenting their operating procedures. Poor management of software systems doesn't seem like a strong justification - or even rationalization - for changing a completely unrelated international standard.The solution to ignorance - what you so generously characterize as "stupidity" - is education. You are really just supporting the tired old notion of security through obscurity. As the traffic school cop pointed out: there are no accidents, only collisions.Your workstation is not an "IT installation", it is just a workstation.I was our Y2K team lead. For that period of time, my workstation was one of the primary development systems for an image processing software package used by half the astronomers in the world. The astronomical community responded promptly and appropriately to Y2K, with initiatives such as formally adopting ISO 8601 and introducing pivot dates into systems that had to remain backwards compatible. Coherent APIs were designed and implemented to handle both new format and old format date/time strings transparently.Why are we not discussing what new data structures, APIs, transport protocols, deployed systems, operating procedures, staffing and management issues will be necessary to implement such a major change less than two-and-a-half years hence? How is it that this "proposal" is completely devoid of any discussion whatsoever of its implementation and ramifications?UTC is the equivalent of ISO 8601 for the purpose of this never-ending discussion. In point of fact, many ISO 8601 compliant strings embedded in your databases implicitly assert that UTC ~ GMT. Whatever happens to leap seconds in the future, proper interpretation of your archival records will continue to depend on interpolating the appropriate leap seconds. Or actually - not. Precisely because UTC ~ GMT, typical civil usage allows you to completely ignore leap seconds when interpreting past data records. Rather, proper interpretation of your *future* database records may well require explicit time scale conversions. There is a vast web of implications associated with civil time. Trying to sneak through a major change of philosophy to an international standard simply to avoid having to think about its implications seems craven and intellectually dishonest.Why are tired, inaccurate and unconvincing leap second risks treated like plutonium is raining from the sky? And why are the subtle and real risks associated with violating the implicit assumption that civil time corresponds to Greenwich Mean Time ignored completely? GMT - and its successor, UTC - is a standard that has been in place since the nineteenth century. Wouldn't it make sense to conduct a risk analysis in advance of violating that standard worldwide?Rob SeamanNational Optical Astronomy Observatory
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >On Jul 29, 2005, at 2:11 PM, Poul-Henning Kamp wrote: > From 1998 to 1999, I left the clock on my desktop Sun workstation >set forward 11 years. This allowed me to test various Y2K >remediation issues. (The 11 years was to select the next year with >the same monthly calendar.) There is nothing untestable about leap >seconds in either theory or practice. I have three times been through what ended up being total reinstalls from backups because some operator by accident (or stupidity) set the clock forward in time and then backward in time on a database installation. Your workstation is not an "IT installation", it is just a workstation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Wall Street Journal Article
On Jul 29, 2005, at 2:11 PM, Poul-Henning Kamp wrote: And 62 o'clock happened precisely because leapseconds are untestable in practice for programmers. From 1998 to 1999, I left the clock on my desktop Sun workstation set forward 11 years. This allowed me to test various Y2K remediation issues. (The 11 years was to select the next year with the same monthly calendar.) There is nothing untestable about leap seconds in either theory or practice. The international triumph that was the non-story of Y2K is proof that time dependent code can be inventoried, characterized, remediated and tested in advance. I am proud of the modest part I played in this for the astronomical community. One imagines the proponents of the "private matter internal to the ITU" trotted out each and every example they have of leap second glitches for the WSJ reporter. And one has to wonder if the rather paltry list compiled by this most business-friendly of publications won't be dwarfed by bugs revealed if the equivalency between UTC and GMT is allowed to break. It seems particularly inappropriate to regard the Motorola bug as a "leap second bug" when it represents a class of bugs that will only be revealed should leap seconds cease. I certainly hope that bad-engineering does not expose the public to safety hazards on New Year's Eve. Perhaps proponents of the "U.S. Proposal [...] not for public discussion" might show a little humility and consider commissioning a risk analysis in advance of changing a standard that has been in place since the nineteenth century. What is possibly gained by neglecting this elementary precaution? Rob Seaman National Optical Astronomy Observatory
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, "Tom Van Baak" writes: >> >I don't get the electronic edition either but see: >> >http://www.leapsecond.com/history/wsj2005.htm >> > >> >They twice mentioned 62 o'clock. The history and >> >technical details behind capturing that event are at: >> >http://www.leapsecond.com/notes/leapsec256.htm >> >> And 62 o'clock happened precisely because leapseconds are untestable >> in practice for programmers. > >Poul-Henning, > >On the other hand, I was very pleased to see >in a recent GPS OEM timing receiver (Trimble >Resolution-T) a built-in facility to test timing >events such as leap seconds. I think this is >a brilliant idea, a good software engineering >technique, and even better that is was left in >the production code base and documented >for people like you and me rather than kept >hidden for internal Trimble development use. Ohh, absolutely! That allows you to inject a leap second from the GPS receiver, I do that as well with my own simulation code in the serial data stream handling. I wouldn't be surprised if this was a customer demand in the first place. But the problem about leap-second testability reaches far further than that. For instance, to test it on many systems, you have to set the date to either end of june or end of december, that's fine and well. Once the test is over however, you need to set the clock back to what it was before, and as any seasoned sysad know, you only do that at your peril, or better yet: with a reinstall / reload of software. The next thing is, since the leapsecond problem is mainly an interface problem, you need to simulate the entire (relevant) part of the installation. For a air traffic control system or missile launch system, this is not something you can do any random tuesday. Even given hardware and software for support, the cost is still astronomical compared to the benefit. >Take a look at this Resolution-T screen shot: >http://www.leapsecond.com/pages/res-t/clip8.gif > >By the way, another thing the Resolution-T >does (at least the manual says so) in TSIP >packet 8F-AB is report leap seconds with a >double 23:59:59 instead of a 23:59:60. I would >have liked to be a fly on the wall when that >UTC engineering decision was made. Perhaps >someone on the list from Trimble would like >to comment. That's actually pretty smart, it means that they won't confuse UNIX systems with their serial data. Not correct mind you, but smart nontheless. Should have been an option though. I guess I should get one of those Trimbles soon. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Wall Street Journal Article
Poul-Henning Kamp wrote: And 62 o'clock happened precisely because leapseconds are untestable in practice for programmers. I have written (and tested) data logging software for proper leap second handling. What am I missing? -Joe Fitzgerald
Re: Wall Street Journal Article
> >I don't get the electronic edition either but see: > >http://www.leapsecond.com/history/wsj2005.htm > > > >They twice mentioned 62 o'clock. The history and > >technical details behind capturing that event are at: > >http://www.leapsecond.com/notes/leapsec256.htm > > And 62 o'clock happened precisely because leapseconds are untestable > in practice for programmers. Poul-Henning, On the other hand, I was very pleased to see in a recent GPS OEM timing receiver (Trimble Resolution-T) a built-in facility to test timing events such as leap seconds. I think this is a brilliant idea, a good software engineering technique, and even better that is was left in the production code base and documented for people like you and me rather than kept hidden for internal Trimble development use. Features like this should exist in many other OEM timing products. It's a good trend, IMHO. Take a look at this Resolution-T screen shot: http://www.leapsecond.com/pages/res-t/clip8.gif By the way, another thing the Resolution-T does (at least the manual says so) in TSIP packet 8F-AB is report leap seconds with a double 23:59:59 instead of a 23:59:60. I would have liked to be a fly on the wall when that UTC engineering decision was made. Perhaps someone on the list from Trimble would like to comment. /tvb
Re: Wall Street Journal Article
On Fri 2005-07-29T13:51:33 -0700, Tom Van Baak hath writ: > > Unfortunately, I don't get the electronic edition so can't cut-and paste. This works, at least for today. http://online.wsj.com/article_email/0,,SB112258962467199210-H9je4Nilal4o52nbYCIbq6Em4,00.html -- Steve Allen <[EMAIL PROTECTED]> WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165 Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
Re: Wall Street Journal Article
In message <[EMAIL PROTECTED]>, Tom Van Baak writes: >I don't get the electronic edition either but see: >http://www.leapsecond.com/history/wsj2005.htm > >They twice mentioned 62 o'clock. The history and >technical details behind capturing that event are at: >http://www.leapsecond.com/notes/leapsec256.htm And 62 o'clock happened precisely because leapseconds are untestable in practice for programmers. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Wall Street Journal Article
> From: "John Ackermann N8UR" > To: "Discussion of precise time and frequency measurement" > The front page of today's Wall Street Journal has an article about the > debate. The headline is "Why the US wants to End the Link Between Time > and Sun." > > Unfortunately, I don't get the electronic edition so can't cut-and paste. > > From the article, it appears the USNO was the author of the proposal. > IT's attributed to Dennis D. McCarthy, who was "the Navy's 'Director of > Time'." > > The first part of the article is mainly about the anti-leapsecond > arguments, but the latter part points out the opposition. There's a > quote from Rob Seaman (among others). > > John I don't get the electronic edition either but see: http://www.leapsecond.com/history/wsj2005.htm They twice mentioned 62 o'clock. The history and technical details behind capturing that event are at: http://www.leapsecond.com/notes/leapsec256.htm /tvb
