Re: The ends won't justify the means
On Mon 2005-01-24T10:13:47 -0700, Rob Seaman hath writ: > How (precisely) can we improve the distribution of time signals to > the worldwide communities that depend on them? I know that NIST has folks working on this. I suspect that they are talking with folks at NRL and PTB and GPS/Navstar and Galileo. I can't say who or what for the same reasons Rob mentions. One such reason is succinctly phrased at the end of this posting in the eternal discussion thread about POSIX time_t behavior: http://www.opengroup.org/platform/single_unix_specification/show_mail.tpl?source=L&listname=austin-group-l&id= -- 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
The ends won't justify the means
I'm pleased to see such a robust discussion - yet again. Some of the posters are very familiar from previous rounds of discussion, some names seem new to me. If there are new members of this list (and we certainly could benefit from such - no irony intended), they may not have stumbled onto the list archives: http://rom.usno.navy.mil/archives/leapsecs.html Many of the current talking points have been thrashed out over and over again. It must surely be clear to everyone on all sides of this decision that there is no consensus. In such a case what is the best thing to do? I see two options. First, attempt to open the discussion to a wider community who may be able to offer new perspectives on the issues. This is the brave approach. Second, retreat to our separate bunkers and lob verbal bombs at each other with the hope of eventually "winning" the battle. Some might characterize this as the "prudent" approach. I've surrounded "prudent" in quotes because I believe such a strategy will eventually prove itself flawed not only to the losers of the leap second battle, but to the winners. You may disagree with my statements above. Clearly a large fraction of the members of this list disagree with my point of view on other issues :-) Just as nobody else has expressed an opinion that appears to be shared by a majority of current list members. It's anybody's guess what the folks on the standards committee(s) think. Why then do we continue to focus on the places where we disagree? I think there is at least one area that we all will agree deserves further discussion. It is the area that for five years has been (at least apparently) ignored by the powers that be. It seems to me that this issue should be at the center of the decision making process related to civil time, and of its past and future relationship to Coordinated Universal Time and/or International Atomic Time. That issue is: How (precisely) can we improve the distribution of time signals to the worldwide communities that depend on them? After all, the UTC standard is a discussion of the explicit details involved in distributing a joint radio time signal that conveys TAI at about the millisecond level and UT (UT1 to be precise) at the tenth second level. (See comments below.) The fact is that the astronomers already compromised on the precision of UT delivery - TAI benefits by two orders of magnitude. Astronomers have long since demonstrated that they are willing to compromise. Others need to do the same. Surely a better mechanism (or mechanisms) could be designed for conveying interval time and time-of-day worldwide. Surely the first step for any project team handed such a daunting mandate would be to spend a significant amount of time and resources in a requirements discovery phase. Clearly there are some very interesting technical requirements that members of this list are competent to begin to address. But not all (or even most) of the requirements are technical. Previous editions of the leap second follies have made convincing cases for legal requirements, religious requirements, business requirements, historical requirements, science requirements and many other requirements that should form the core of any decision relating to a change in leap second handling. The technology is the "how" of the implementing the decision. I would think it a tautology that the "what" of any decision regarding civil time standards should be based on the requirements of the full range of civil time users. A second is not an intrinsically small unit of time. For some purposes a nanosecond is a lifetime. For other purposes, a million years is the blink of an eye. This decision deserves the attention to detail that our best work demands. No public decision deserves the lazy back room politics of the intellectually dishonest leap hour proposal. It should be removed from the table and we should roll up our sleeves to address the issues head on. Rob Seaman National Optical Astronomy Observatory 1) One questions whether the designers of UTC and the drafters of the standard really intended that the Radio Telecommunications community have ultimate authority over not just the delivery of civil time signals worldwide, but also over the definition of the concept of civil time itself. The ITU isn't even the same organization under which the standard originated. And surely we have long since passed the point where radio signals handed the baton to computer packets as the world's primary time distribution technology. In any event, the UTC standard assumes implicitly that Universal Time is defined to be a close approximation of Greenwich Mean Time. In fact, the original UTC standard stated this explicitly: "GMT may be regarded as the general equivalent of UT." 2) UTC does not stand alone as a standard. Coordinated Universal Time is only the public face of a whole family of Universal Time standards and definitions (UT0, UT1, UT2)
Re: two world clocks
I hadn't seen this before - thanks. It doesn't surprise me, though. Unless I'm missing something, getting replacing leap seconds with leap hours (r leap-anything related of the length of a day) would not simplify any of this. The only way to simplify it is to remove the ability to adjust for day length altogether. This voids the whole purpose of UTC, and we might as well just go to TAI. Given the discussion we've seen, I doubt that would meet with general approval. My claim is that there are very few applications in the world that really need something like this longtime API. I've heard a few speculated about (e.g. legal contracts), but none I've seen stand up under scrutiny. Do you know of any? /glen > -Original Message- > From: Leap Seconds Issues [mailto:[EMAIL PROTECTED] > On Behalf Of Poul-Henning Kamp > Sent: January 21, 2005 10:46 AM > To: LEAPSECS@ROM.USNO.NAVY.MIL > Subject: Re: [LEAPSECS] two world clocks > > In message > <[EMAIL PROTECTED] > om>, "Seeds, Glen" writes: > > >This was not an oversight. Considerable analysis went into > >understanding how this would work. The bottom line is that > it's not a > >problem for all but a very few applications, which have ways to work > >around it. These same applications have timekeeping synchronization > >costs that are far larger than the costs of these workarounds. > > One of the better arguments for getting rid of leapseconds is > seen by printing this page: > > http://david.tribble.com/text/c0xlongtime.html > > And then marking all the stuff that would not be necessary > and remove all the support for optionally represented leapseconds. > > There is a lot less left afterwards. > > -- > 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. > > > This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.
Re: two world clocks AND Time after Time
Tom Van Baak scripsit: > Another observation is that our local newspaper always > prints Sun and Moon rise and set times. But not time > of noon. Why is this? Maybe it's just our paper (noon > implies sun and we don't see much of it here in Seattle). Some people need to know sunset for religious reasons, and perhaps sunrise is occasionally useful too; I have been checking sunset times lately to figure out when to tell my daughter to be at home by. Solar noon just doesn't have the same importance. > Sure, but it seems to me - regardless of the timezone, > regardless of daylight saving time, regardless of the > season, regardless of latitude, to the general public > 12:00 means lunchtime (or their VCR got unplugged). > The sun doesn't have much say about it. Amen. -- Is a chair finely made tragic or comic? Is the John Cowan portrait of Mona Lisa good if I desire to see [EMAIL PROTECTED] it? Is the bust of Sir Philip Crampton lyrical, www.ccil.org/~cowan epical or dramatic? If a man hacking in fury www.reutershealth.com at a block of wood make there an image of a cow, is that image a work of art? If not, why not? --Stephen Dedalus
Re: two world clocks AND Time after Time
Steve Allen scripsit: > What we are being told by the Time Lords is that, starting from a date > in the near future, knowing when noon is will also be a specialist > operation. Already true. For many months of the year, solar noon is closer to 1 PM, or even 1:30 PM, in a great many countries, and how many people actually realize *that*? -- Winter: MIT, John Cowan Keio, INRIA,[EMAIL PROTECTED] Issue lots of Drafts. http://www.ccil.org/~cowan So much more to understand! http://www.reutershealth.com Might simplicity return?(A "tanka", or extended haiku)
Re: two world clocks AND Time after Time
In message <[EMAIL PROTECTED]>, Steve Allen writes: >On Mon 2005-01-24T00:50:10 -0800, Tom Van Baak hath writ: >> Isn't knowing when noon is already a specialist operation? >> I mean, most people could tell you when noon is to within >> an hour or two or three, but finer than that requires a far >> amount of daily mental calculation, no? > >Noon has long required a calendar, an almanac, a longitude, and the >ability to perform addition and subtraction. You forget a lawyer or at least a copy of the relevant laws in your area, because surely you're not assuming that my watch runs on UTC ? -- 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: Time after Time
In message <[EMAIL PROTECTED]>, Markus Kuhn writes: >You surely must have seen my detailed UTS proposal for how UTC leap >seconds should be handled trivially and safely by the overwhelming >majority of computer applications, without any special considerations >whatsoever by normal application programmers: > > http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf > http://www.cl.cam.ac.uk/~mgk25/uts.txt Markus, that's all very nice and cute, but it is a grusome hack and should not be propagated. It is less gruesome than what we have now in the NTP code, but it is still a gruesome hack. There are far to many problems in this that you don't consider: 1) Computers booting inside your 1000 second interval do what ? 2) What about a computer being offline (by design or accidentally) during the 1000second window ? 3) Many real time systems will not tolerate 1e-3 clock error. 4) How wold a leap-time aware application run on such an operating system ? 5) You still need to way to distribute leapseconds to embedded and offline computers. Your proposal pastes over some of the minor issues with leap seconds, but it doesn't address the two fundamental problems: 1. You don't know when they will happen with long enough warning. 2. You can't test one when you need to. -- 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: Time after Time
Poul-Henning Kamp wrote on 2005-01-24 09:32 UTC: > In message <[EMAIL PROTECTED]>, Markus Kuhn writes: > > >In summary: There are basically three proposals on the table: > > > > a) Keep UTC as it is (|UTC - UT1| < 900 ms) and just make TAI more > > widely available in time signal broadcasts > > [...] > >My views: > > > > a) is perfectly fine (perhaps not ideal, but certainly workable) > > This is where we disagree: leapseconds are too small and too > infrequent (in the next century at least) to be taken sufficiently > serious in computer programming. You surely must have seen my detailed UTS proposal for how UTC leap seconds should be handled trivially and safely by the overwhelming majority of computer applications, without any special considerations whatsoever by normal application programmers: http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf http://www.cl.cam.ac.uk/~mgk25/uts.txt All this is just a matter of providing an adequate standard guideline for the very few Time Geeks that implement OS time APIs and kernel clock drivers. The UTS draft has been discussed repeatedly here and elsewhere over the past five years. I have yet to see a single technical objection or a suggestion for improvement to it. (The only suggestion I remember came from Daniel Gambis at the Torino meeting, which was only about the name, because there is already another timescale called UTS defined by IERS.) Markus -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
Re: Time after Time
In message <[EMAIL PROTECTED]>, Markus Kuhn writes: >In summary: There are basically three proposals on the table: > > a) Keep UTC as it is (|UTC - UT1| < 900 ms) and just make TAI more > widely available in time signal broadcasts > > b) Move from frequent UTC leap seconds to far less frequent UTC leap > hours, by relaxing the UTC-UT1 tolerance (e.g., |UTC - UT1| < 59 min) > > c) Remove any future leap from UTC, such that UTC becomes TAI plus a fixed > constant (i.e., |UTC - UT1| becomes unbounded and will start to grow > quadratically). In this scenario, LCTs would have to change their > UTC offset every few hundred years, to avoid day becoming night > in LCTs. > >My views: > > a) is perfectly fine (perhaps not ideal, but certainly workable) This is where we disagree: leapseconds are too small and too infrequent (in the next century at least) to be taken sufficiently serious in computer programming. The community which benefit from sticking with a) is so small and so far more capable of dealing with the complexity than the rest of the planets sentient population. > b) is utterly unrealistic and therefore simply a dishonest proposal > (UTC is so popular today in computing primarily because it is > *free* of leap hours) Well, it is not unrealistic, in fact it may be the only realistic way to implement c) as it allows the ITU-T delegation to vote for the proposal without exceeding their mandate and gives us a couple hundred years to allows the countries time to adapt their legislation before we admit that c) was what we wanted all along. > c) I could live with that one, but what worries me is that > it will create a long-term mess in a few millenia, when > |UTC-LCT| >> 1 day. You know, amongst the things we have to worry about in the next couple of millenia, this is way down the list. If it comes to that, we don't even know what melting the icecap on Greenland or having a new ice-age (take your pick :-) will do to the earths rotation rate, and both are events which have (p > .1) over the next 2500 years. And I am sure that the simple farmer society living in pact with mother nature avoiding all technology or the colonies around distant stars (take your pick) will find it most amusing that they have to fiddle with their timescale because the old home planet had a bunch of boffins decide that for them 2000 years ago. > I am annoyed that this long-term mess and solutions > around it are not even being discussed. Very few people have a horizon that long, and since this is all conventional anyway, most realize that conventions live only a few generations after the brains who wrote them. BTW: If we call the rotational time of Earth "universal", what are we going to call the rotational time of Mars ? Certainly I would not expect an "universal time" to be adjusted because of the variability of rotation of one specific planet. -- 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: two world clocks AND Time after Time
On Mon 2005-01-24T00:50:10 -0800, Tom Van Baak hath writ: > Isn't knowing when noon is already a specialist operation? > I mean, most people could tell you when noon is to within > an hour or two or three, but finer than that requires a far > amount of daily mental calculation, no? Noon has long required a calendar, an almanac, a longitude, and the ability to perform addition and subtraction. This has long been something that could be presumed within the abilities of any locality big enough to call itself a town. The tasks of business, payroll, and banking demand that much. Sunrise and sunset have required haversines. That's why the newspapers publish them. Trigonometry was not required for simple civil life. -- 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: two world clocks AND Time after Time
In message <[EMAIL PROTECTED]>, Tom Van Baak writes: >Another observation is that our local newspaper always >prints Sun and Moon rise and set times. But not time >of noon. Why is this? Maybe it's just our paper (noon >implies sun and we don't see much of it here in Seattle). > >Why is the instant of sunrise or sunset of popular value >while the high point of noon isn't. What does this suggest >about the risk of allowing noon to wander an hour over >the span of 1000 years? Several countries have codified sunrise and sunset as when traffic needs to light up. In Denmark while cars and motorbikes are lit up at all times, bicycles and horses must be lit up from sunset to sunrise. There are similar rules for vessels on water I belive. >> "Month" is entirely conventional in its meaning. >> "Year" is entirely conventional in its meaning. >> So soon "day" will be entirely conventional in its meaning. > >Can you explain this more? I can see how Month >would be conventional, or even entirely conventional >but are year and day also such extreme cases? The Year represents when the constellations repeat their performance, but the precision of this is wrecked by the leap-years, so it is only conventional these days. >It seems to me the popular understanding of a year >is accurate to +/-1 day. And the popular understanding >of noon is accurate to +/- 1 hour or two. Does that make >them "entirely conventional"? Seen from an astronomical point of view: yes, you can't point your telescope with it. >> The trick will be to educate the general public that 12:00 means >> slightly less about where the sun is in longitude than the Gregorian > >Sure, but it seems to me - regardless of the timezone, >regardless of daylight saving time, regardless of the >season, regardless of latitude, to the general public >12:00 means lunchtime (or their VCR got unplugged). >The sun doesn't have much say about it. Fully agreed. I would even venture to claim that a lot of todays teenagers are only mildly aware of the "noon -- more light outside" connection :-) -- 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: two world clocks AND Time after Time
Steve Allen wrote on 2005-01-24 06:09 UTC: > But the current strategy of retaining the name UTC creates one real > and unresolvable problem that will persist indefinitely. It is very > bad policy to corrupt the historical meaning of anything called > "Universal Time" by redefining UTC to be something that has no > relation to the rotation of the earth. It has been historically rather bad terminology to start with, so I wouldn't shed too many tears here. "Universal Time" sounds to me like a more suitable name for a time scale that is linked to a property of the entire known universe, say a frequency defined by the electron configuration of the caesium atom. "Terrestrial Solar Time" would have sounded like a *far* more fitting name of a time scale that is linked to Earth's rotational angle. Unfortunately, astronomers chose their terms exactly the wrong way round in a counter-intuitive way, where "Terrestrial Time" is actually a physical time scale and "Universal Time" is an Earth angle time scale. Of course, relativity tells us that there is no such thing as a "Universal Time", and that we have to attach any time scale to some coordinate system (e.g., barycenter of sun or earth). It would be nice to have a more streamlined terminology, where individual words/letters in the acronyms unambiguously indicate - whether the time is physical (counting SI seconds) or solar (defined by the position of the mean sun relative to a body in the solar system) - if it is physical time, where the relativistic reference frame is attached (barycenter of the milkyway, sun, or some planet, or the surface of some planet) - if it is a solar time, which planet and how is the prime meridian defined - if it is a solar time, which periodic deviations have been removed Markus -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
Re: Time after Time
John Cowan wrote on 2005-01-23 18:37 UTC: > Markus Kuhn scripsit: > > > UTC currently certainly has *no* two 1-h leaps every year. > > There seems to be persistent confusion on what is meant by the term > "leap hour". Why? > I understand it as a secular change to the various LCT offsets, > made either all at once (on 1 Jan 2600, say) or on an ad-lib basis. No. A "UTC leap hour" is an inserted 60-minute repeat segment in the UTC time scale, which starts by jumping back on the UTC time scale by one hour. This has been proposed by BIPM in Torino to be done for the first time to UTC in about 2600, instead of doing the about 1800 leap seconds that would be necessary under the current |UTC - UT1| < 900 ms until then. The proposed "UTC leap hour" simply means that the definition of UTC is relaxed to (something like) |UTC - UT1| < 59 min, and the size of the adjustment leap is increased accrodingly from 1 s to 3600 s. Local civilian times are of no convern to ITU, as they are entirely the responsibility of numerous national/regional arrangements. > You seem to be using it in the sense of a 1h secular change to universal > time (lower-case generic reference is intentional). I can't understand what could be ambiguous here. A leap hour means to turn a clock forward or backward by an hour. We have done it twice a year in many LCTs. The BIPM suggested in Torino that we should do it every couple of hundred years to UTC as well, which would become permissible by going from the rule |UTC - UT1| < 900 ms to a relaxed rule such as |UTC - UT1| < 59 min. The term "leap hour" does in no way imply what time zone/scale we are talking about, and in this context we are talking mostly about UTC. [How a UTC leap hour would affect LCTs is up the maintainers of the these LCTs. Since the LTCs currently in use have their leap hours on many different days of the year, a UTC leap hour would mean that at least some LCTs would have three leap hours in that year. This could only be avoided if all LCTs would agree to do their DST leaps simultaneously with the UTC leap.] In summary: There are basically three proposals on the table: a) Keep UTC as it is (|UTC - UT1| < 900 ms) and just make TAI more widely available in time signal broadcasts b) Move from frequent UTC leap seconds to far less frequent UTC leap hours, by relaxing the UTC-UT1 tolerance (e.g., |UTC - UT1| < 59 min) c) Remove any future leap from UTC, such that UTC becomes TAI plus a fixed constant (i.e., |UTC - UT1| becomes unbounded and will start to grow quadratically). In this scenario, LCTs would have to change their UTC offset every few hundred years, to avoid day becoming night in LCTs. My views: a) is perfectly fine (perhaps not ideal, but certainly workable) b) is utterly unrealistic and therefore simply a dishonest proposal (UTC is so popular today in computing primarily because it is *free* of leap hours) c) I could live with that one, but what worries me is that it will create a long-term mess in a few millenia, when |UTC-LCT| >> 1 day. I am annoyed that this long-term mess and solutions around it are not even being discussed. (My hope would have rested on resolving the |UTC-LCT| >> 1 day problem by inserting leap days into the LCTs every few thousand years as necessary, to keep |UTC-LCT| < 36 hours this way, and that these leap days in LCTs could perhaps be the same that may be necessary anyway every few millenia to fix the remaining Easter drift in the Gregorian calendar: http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00206.html ) Markus -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
Re: two world clocks AND Time after Time
Steve, Some comments on your fine posting... > But Essen claims for himself (in both this autobiography > and in Metrologia I found the Metrologia article interesting. I had heard of 100 ms steps (leap tenth-seconds) but not the 50 ms steps. Did you notice he appears to refer to a leap second when he suggests "moving the minute marker along by 1 second on a prearranged date, possibly 1 January and 1 June". A scan of the Essen article is now at: http://www.leapsecond.com/history/1968-Metrologia-v4-n4-Essen.pdf > Knowing the tides is a specialist operation, and has always been. > Knowing the phase of the moon is a specialist operation, and has been > in western culture for over two millenia. > What we are being told by the Time Lords is that, starting from a date > in the near future, knowing when noon is will also be a specialist > operation. Isn't knowing when noon is already a specialist operation? I mean, most people could tell you when noon is to within an hour or two or three, but finer than that requires a far amount of daily mental calculation, no? Another observation is that our local newspaper always prints Sun and Moon rise and set times. But not time of noon. Why is this? Maybe it's just our paper (noon implies sun and we don't see much of it here in Seattle). Why is the instant of sunrise or sunset of popular value while the high point of noon isn't. What does this suggest about the risk of allowing noon to wander an hour over the span of 1000 years? > "Month" is entirely conventional in its meaning. > "Year" is entirely conventional in its meaning. > So soon "day" will be entirely conventional in its meaning. Can you explain this more? I can see how Month would be conventional, or even entirely conventional but are year and day also such extreme cases? It seems to me the popular understanding of a year is accurate to +/-1 day. And the popular understanding of noon is accurate to +/- 1 hour or two. Does that make them "entirely conventional"? > The trick will be to educate the general public that 12:00 means > slightly less about where the sun is in longitude than the Gregorian Sure, but it seems to me - regardless of the timezone, regardless of daylight saving time, regardless of the season, regardless of latitude, to the general public 12:00 means lunchtime (or their VCR got unplugged). The sun doesn't have much say about it. /tvb http://www.LeapSecond.com
