From sla at ucolick.org Sat Feb 9 23:36:02 2008 From: sla at ucolick.org (Steve Allen) Date: Sat, 9 Feb 2008 20:36:02 -0800 Subject: [LEAPSECS] a modest proposal Message-ID: <20080210043602.GA14616@ucolick.org> What if the plan outlined at Torino in May 2003 were to be implemented, but with a few more details? I think the resolutions from Torino do need a little more detailed guidance about implementation by various systems, and chief among those is the interaction with POSIX. I think that the ITU-R is not well structured to be in charge of defining a time scale. It is good for defining radio broadcasts. I think that the ITU-R should retire TF.460, and at the same time adopt a new resolution as called for in Torino, defining International Time (TI). Radio broadcasts of precision time signals should give TI. I think that POSIX time_t should be redefined to be TI, with no leap seconds. I think that the leap seconds should be included in the zoneinfo files. POSIX already allows that the local time can be offset by an arbitrary number of seconds (not just hours and minutes) from the system value of time_t. The mechanism by which this is communicated to POSIX systems is zoneinfo. The zoneinfo maintainers are accustomed to making changes many times a year, with almost no advance notice, subject to whims of political entities which are much less predictable than leap seconds. This keeps the simplicity of POSIX system time with the only cost being one of interpretation: the system time_t is TI, and UTC be an entity derived using zoneinfo. I think the ITU-R should formally turn UTC over to the BIPM, to be maintained in conjunction with the IERS. This makes UTC a two-agency activity rather than the current three agencies. This allows BIPM to maintain full authority over all time scales, precision and civil. This allows all the bureaus of the IERS to continue to represent to their funding agencies that their work is essential for the purposes of telling the world what time it is. (If UTC were redefined instead of replace with TI, the earth rotation monitoring of the IERS becomes moot from the standpoint of commerce.) It seems to me that with these changes in effect *almost nothing technical breaks*! Yes, at a bureaucratic and political level they are major upheavals and they require serious cooperation between many agencies. They require NIST and other national time bureaus to make the case that it is internationally desirable to broadcast a time scale which has a slightly more complicated relationship to the legal civil time than it used to have. But at a technical level all the mechanisms already exist and work. The worst effect I see is that maintaining the zoneinfo files becomes a tad trickier. There are very few systems which are not POSIX compliant, and not capable of updating their zoneinfo. I recognize that a few things do break, chief among them the radio controlled clocks and wristwatches which currently give correct civil time. Nevertheless, I assert that for non-civil purposes it is merely a bureaucratic change to have to note that, e.g., the radio-controlled timestamps on the milk cartons are now actually TI instead of UTC. For those radio-controlled clocks which must give correct civil time, I assert that they will pass unobtrusively into obsolescence or be upgraded before the difference between UTC and TI becomes relevant. The worst case will be those WWVB clocks (and similar longwave systems in other regions) which are digital, for they will show the missing leap seconds clearly. (I discount the analog versions from the start, for the three mechanical WWVB clocks that I brought back from my dad's place have already stripped the gears for their second hands.) I am also prepared disregard the recommended date from Torino. If done well there is no need to wait until year 2022. I can't remember whether LEAPSECS has discussed this particular way of implementing the change, but I think it has not been so. The question then is What objections are there to this way of getting leap seconds out of broadcast time signals while keeping them in UTC? -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From cowan at ccil.org Sat Feb 9 23:44:40 2008 From: cowan at ccil.org (John Cowan) Date: Sat, 9 Feb 2008 23:44:40 -0500 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080210043602.GA14616@ucolick.org> References: <20080210043602.GA14616@ucolick.org> Message-ID: <20080210044440.GB16774@mercury.ccil.org> Steve Allen scripsit: > There are very few systems which are not POSIX compliant, and not > capable of updating their zoneinfo. I confess I didn't see where the satire came in until here. -- John Cowan cowan at ccil.org http://ccil.org/~cowan The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra From sla at ucolick.org Sat Feb 9 23:47:45 2008 From: sla at ucolick.org (Steve Allen) Date: Sat, 9 Feb 2008 20:47:45 -0800 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080210044440.GB16774@mercury.ccil.org> References: <20080210043602.GA14616@ucolick.org> <20080210044440.GB16774@mercury.ccil.org> Message-ID: <20080210044745.GA14689@ucolick.org> On Sat 2008-02-09T23:44:40 -0500, John Cowan hath writ: > Steve Allen scripsit: > > There are very few systems which are not POSIX compliant, and not > > capable of updating their zoneinfo. > > I confess I didn't see where the satire came in until here. Can we identify and enumerate them? -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From cowan at ccil.org Sat Feb 9 23:58:58 2008 From: cowan at ccil.org (John Cowan) Date: Sat, 9 Feb 2008 23:58:58 -0500 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080210044745.GA14689@ucolick.org> References: <20080210043602.GA14616@ucolick.org> <20080210044440.GB16774@mercury.ccil.org> <20080210044745.GA14689@ucolick.org> Message-ID: <20080210045858.GC16774@mercury.ccil.org> Steve Allen scripsit: > Can we identify and enumerate them? Probably not, but we can characterize them: viz. Windows systems. Windows does not use zoneinfo, nor is it (in the ordinary sense) Posix compliant. If you use the term "modest proposal", you have to expect that you will be seen as a satirist: see http://art-bin.com/art/omodest.html . -- As we all know, civil libertarians are not John Cowan the friskiest group around -- comes from cowan at ccil.org forever being on the qui vive for the sound http://www.ccil.org/~cowan of jack-booted fascism coming down the pike. --Molly Ivins From jhein at timing.com Sun Feb 10 00:19:23 2008 From: jhein at timing.com (John Hein) Date: Sat, 9 Feb 2008 22:19:23 -0700 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080210044745.GA14689@ucolick.org> References: <20080210043602.GA14616@ucolick.org> <20080210044440.GB16774@mercury.ccil.org> <20080210044745.GA14689@ucolick.org> Message-ID: <18350.35163.122215.143528@gromit.timing.com> Steve Allen wrote at 20:47 -0800 on Feb 9, 2008: > On Sat 2008-02-09T23:44:40 -0500, John Cowan hath writ: > > Steve Allen scripsit: > > > There are very few systems which are not POSIX compliant, and not > > > capable of updating their zoneinfo. > > > > I confess I didn't see where the satire came in until here. > > Can we identify and enumerate them? 'Twould take some time. All the same systems that could not update their leap seconds table... and more. Those systems that have no connectivity or no [easy] mechanism for receiving leap second updates (these are the systems for which people have mentioned they would like leap second tables out to 10 years in the future or more) will be similarly out of luck for receiving zoneinfo files. At least _some_ deployed systems have been manhandled (it's not pretty) to get leap second updates (via GPS, for instance). Those systems have no mechanism to get zoneinfo files. Not to mention many of these systems specifically and purposefully don't care about time zones _because_ of the zoneinfo updating problem. That said, I understand where you're coming from. Now if we could even take it a step further. If only we can convince people and their computer clocks to stop using UTC and just use TI (a non-leap-second timescale) for figuring out when to pick their kids up from school, then the systems I've described will no longer be mandated to provide UTC (!). Then the time everyone uses for daily life can freely drift off from solar time, our progeny can casually ponder the days when it used to be sunny at noon, and UTC can be relegated to historical applications of time rather than real time ones. Yes, that would make life easier for lots of systems. +1 p.s. add to the bureaucratic hurdles you mentioned the task of convincing the zoneinfo maintainers to sign on to the job of keeping leap seconds, too. Not rocket science, but it is more work for them to do. From seaman at noao.edu Sun Feb 10 01:33:45 2008 From: seaman at noao.edu (Rob Seaman) Date: Sat, 9 Feb 2008 23:33:45 -0700 Subject: [LEAPSECS] a modest proposal In-Reply-To: <18350.35163.122215.143528@gromit.timing.com> References: <20080210043602.GA14616@ucolick.org> <20080210044440.GB16774@mercury.ccil.org> <20080210044745.GA14689@ucolick.org> <18350.35163.122215.143528@gromit.timing.com> Message-ID: <84048361-8F35-407B-AD19-87C8983F1BB8@noao.edu> Folks, Don't you think Steve's plan - heck, any coherently expressed suggestion - is worth a hearing? Must the integrated role timekeeping plays in our society's systems be belabored? Any viable plan moving forward is going to face challenges of communication, bureaucracy, technology, standards, funding and so forth and so on. The "to hell with leap seconds" notion is an attempt to sweep most of that natural complexity under the table. There is no plan - viable or otherwise. Rather, any competent system engineering management plan would take all of the issues into account. If you believe that solar time is merely a quaint oddment, the way to make the case would be a trade-off study or formal risk analysis. Sell a design, not a gimmick. Rob Seaman National Optical Astronomy Observatory From phk at phk.freebsd.dk Sun Feb 10 03:52:04 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 10 Feb 2008 08:52:04 +0000 Subject: [LEAPSECS] a modest proposal In-Reply-To: Your message of "Sat, 09 Feb 2008 20:36:02 PST." <20080210043602.GA14616@ucolick.org> Message-ID: <67449.1202633524@critter.freebsd.dk> Steve, Your proposal is commendable, nuanced and well thought out. I think you underestimate some of the technical and practical issues, but that can be hashed out. But how do you propose to get the attention of the people who will need to allocate significant IT resources and budget to these changes ? WP7A isn't going to be able to. At the very moment WP7A comes out with anything that would indicate software updates, all civilized countries will run home, do hearings and study groups and come back and say "This is far too expensive, and we can see no sufficient big benefit for the expenditure". Try to study what happened when ITU changed the channel grid to 9kHz in Europe. That was a change that merely involved changing some crystals and tuning some radios a bit. The only reason they got it through in the end, was that it enabled some very big european countries getting more broadcasting channels. Leapseconds carry no such political benefit and will not get the necessary attention, which is, btw, one of the major arguments against them: people do not take them seriously. If a leap second caused a big catastrofe, people would take leap seconds seriously, and they would be gone, before WP7A could even order coffee for their next meeting. So yes, you have outlined a possible technical fix, but that is not the problem that is hard to solve, the one you need to solve first is "who is going to pay, and how do we make them ?" Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From ch at murgatroid.com Sun Feb 10 12:32:09 2008 From: ch at murgatroid.com (christopher hoover) Date: Sun, 10 Feb 2008 09:32:09 -0800 Subject: [LEAPSECS] a modest proposal In-Reply-To: <67449.1202633524@critter.freebsd.dk> References: Your message of "Sat, 09 Feb 2008 20:36:02 PST." <20080210043602.GA14616@ucolick.org> <67449.1202633524@critter.freebsd.dk> Message-ID: <000001c86c0a$dd3f11f0$97bd35d0$@com> Poul-Henning Kamp wrote: > So yes, you have outlined a possible technical fix, but that is not > the problem that is hard to solve, the one you need to solve first > is "who is going to pay, and how do we make them ?" One way would to get the spec written into a major US gov't procurement bid as a requirement. -ch From phk at phk.freebsd.dk Sun Feb 10 12:58:22 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 10 Feb 2008 17:58:22 +0000 Subject: [LEAPSECS] a modest proposal In-Reply-To: Your message of "Sun, 10 Feb 2008 09:32:09 PST." <000001c86c0a$dd3f11f0$97bd35d0$@com> Message-ID: <66527.1202666302@critter.freebsd.dk> In message <000001c86c0a$dd3f11f0$97bd35d0$@com>, "christopher hoover" writes: >Poul-Henning Kamp wrote: >> So yes, you have outlined a possible technical fix, but that is not >> the problem that is hard to solve, the one you need to solve first >> is "who is going to pay, and how do we make them ?" > >One way would to get the spec written into a major US gov't procurement bid >as a requirement. Yes, that will give you a proof of concept implementation. And then what ? First somebody has to convince Microsoft that they have to support this technical infrastructure. The best you can hope for is a buggy version in Windows 2008 which arrives in 2010. Then around 2012 it might sort of work. Open source OS's will be ready before that if IPv6 and similar is any indication. Then you need to convince _everybody_, including the German government, NASA, your local water-utility, the radiologist at your favourite hospital, SSBN owning defenses, the CIA and _everybody_ else to do the necessary system updates and upgrades. Lets be optimistic and say that it's going to happen the time after next time they buy new kit, because the 3rd party vendors need to get their things working first. So, realistically, we might be able to have a technical fix implemented around 2050 -- 2040 at best. You have to remember, this is far more subtle *and* intrusive than just the IPv4/IPv6 thing, which so far has taken 15 years to get absolutely no where (see RFC 1287, which has about the same level of detail as the proposal Steve just published). And also remember: IPv6 has had the "we'll run out of IPv4 addresses" sword hanging over peoples head all along, we have no similar fulcrum issue for leap seconds. Compare this with "lets just forget about leapseconds" which will give us some astronomers complaining about their instruments and computers and potential problems that might happen 200 years from now, but which also means "we don't have to muck about with all the computers". How do you propose to sell against that ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From imp at bsdimp.com Sun Feb 10 13:10:44 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun, 10 Feb 2008 11:10:44 -0700 (MST) Subject: [LEAPSECS] a modest proposal In-Reply-To: <000001c86c0a$dd3f11f0$97bd35d0$@com> References: <20080210043602.GA14616@ucolick.org> <67449.1202633524@critter.freebsd.dk> <000001c86c0a$dd3f11f0$97bd35d0$@com> Message-ID: <20080210.111044.-545557232.imp@bsdimp.com> In message: <000001c86c0a$dd3f11f0$97bd35d0$@com> "christopher hoover" writes: : Poul-Henning Kamp wrote: : > So yes, you have outlined a possible technical fix, but that is not : > the problem that is hard to solve, the one you need to solve first : > is "who is going to pay, and how do we make them ?" : : One way would to get the spec written into a major US gov't procurement bid : as a requirement. You mean like ISO/OSI networking? Warner From phk at phk.freebsd.dk Sun Feb 10 16:15:01 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 10 Feb 2008 21:15:01 +0000 Subject: [LEAPSECS] a modest proposal In-Reply-To: Your message of "Sun, 10 Feb 2008 11:10:44 MST." <20080210.111044.-545557232.imp@bsdimp.com> Message-ID: <99511.1202678101@critter.freebsd.dk> In message <20080210.111044.-545557232.imp at bsdimp.com>, "M. Warner Losh" writes : >In message: <000001c86c0a$dd3f11f0$97bd35d0$@com> > "christopher hoover" writes: >: Poul-Henning Kamp wrote: >: > So yes, you have outlined a possible technical fix, but that is not >: > the problem that is hard to solve, the one you need to solve first >: > is "who is going to pay, and how do we make them ?" >: >: One way would to get the spec written into a major US gov't procurement bid >: as a requirement. > >You mean like ISO/OSI networking? Now now! We're in polite company where we don't use that kind of TLA's. Besides, OSI was augmented, so that TCP/IP is now OSI protocols, so OSI is a fantastic success: everybody uses it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Sun Feb 10 17:45:37 2008 From: seaman at noao.edu (Rob Seaman) Date: Sun, 10 Feb 2008 15:45:37 -0700 Subject: [LEAPSECS] a modest proposal In-Reply-To: <67449.1202633524@critter.freebsd.dk> References: <67449.1202633524@critter.freebsd.dk> Message-ID: <968AC643-450C-405C-AAD3-3FBF79AA7027@noao.edu> Poul-Henning Kamp wrote: > Steve, > > Your proposal is commendable, nuanced and well thought out. Ok, but then what about providing a well thought out proposal, at least as commendable and nuanced, for the ITU's UTC whimsy? > I think you underestimate some of the technical and practical > issues, but that can be hashed out. And a number of list members - colleagues in time - believe the ITU underestimates issues associated with ceasing leap seconds. Considering nobody associated with the ITU has ever deigned to post on this list, how are those concerns to be hashed out? > Compare this with "lets just forget about leapseconds" which will > give us some astronomers complaining about their instruments and > computers and potential problems that might happen 200 years from > now, but which also means "we don't have to muck about with all the > computers". Maybe you won't have to muck about with computers - but large expanses of astronomical infrastructure will have to be refactored by others. Each missed leap second is 15 arcseconds on the celestial equator - many time the precision required to point a telescope. But really, if astronomers' concerns are deemed so easy to dispatch, why not just dispatch them by putting together a coherent system engineering plan for the redefinition of UTC that is actually on the table? Surely it would be better to invest a modest amount to design a coherent solution, thus saving the vast treasure you are suggesting Steve's commendable proposal would demand? Which is it? Either the cessation of leap seconds is a complex question that demands a well thought out plan - or the cessation of leap seconds is a simple question for which a plan would be trivial to generate at the level of nuance required. Either way, is it too much to expect that an actual plan be written? Rob Seaman National Optical Astronomy Observatory From phk at phk.freebsd.dk Sun Feb 10 18:04:52 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 10 Feb 2008 23:04:52 +0000 Subject: [LEAPSECS] a modest proposal In-Reply-To: Your message of "Sun, 10 Feb 2008 15:45:37 MST." <968AC643-450C-405C-AAD3-3FBF79AA7027@noao.edu> Message-ID: <93448.1202684692@critter.freebsd.dk> In message <968AC643-450C-405C-AAD3-3FBF79AA7027 at noao.edu>, Rob Seaman writes: >Maybe you won't have to muck about with computers - but large expanses >of astronomical infrastructure will have to be refactored by others. I think we have been over this ground before. Last I checked, computers with an awareness of H:M:S time outnumber astronomical instruments 100.000 to 1, likely more. >Each missed leap second is 15 arcseconds on the celestial equator - >many time the precision required to point a telescope. This is where I fail to see the magnitude of the problem you claim: It obviously follows, that with leap second granularity of 1 SI second, you need to keep track of the residual also, so your telescope already uses (UTC + DUT1), effectively UT1, for pointing, right ? So all that you will suffer, is that DUT1 is not guaranteed to be numerically less than plus/minus one. I seriously doubt that is going to be a major catastrophic problem for astronomy. But I'll grant you that some astronomy tools will need fixing, but they are outnumbered at least 100.000:1 by computers that just won't care or need to care. Add on top of that, that the majority of the 100.000 computers are under the control of morons, and the one computer in astronomy is not to be touch by anybody less than a graduate student, and the relative trouble of fixing things gets even more skewed in astronomys disfavour. Yes, it's unfair, but astronomy is outnumbered and without the former clout of owning the navigational aids, I can't see much you guys can do about it... That's why I think what you should do, is play cooperative, and try to get as much money and new instruments out of it as you can, while you can. >Which is it? Either the cessation of leap seconds is a complex >question that demands a well thought out plan - or the cessation of >leap seconds is a simple question for which a plan would be trivial to >generate at the level of nuance required. Either way, is it too much >to expect that an actual plan be written? I would expect, that the plan may be written down on the back of a napkin somewhere, having the following substance: 1. Ratify changed document. 2. Announce changed document. 3. Mail copy to BIPM. 4. Case closed -- not our problem any more. That is a large part of the attractiveness of just dropping leap-seconds. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From ch at murgatroid.com Sun Feb 10 21:13:51 2008 From: ch at murgatroid.com (christopher hoover) Date: Sun, 10 Feb 2008 18:13:51 -0800 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080210.111044.-545557232.imp@bsdimp.com> References: <20080210043602.GA14616@ucolick.org> <67449.1202633524@critter.freebsd.dk> <000001c86c0a$dd3f11f0$97bd35d0$@com> <20080210.111044.-545557232.imp@bsdimp.com> Message-ID: <003601c86c53$be734590$3b59d0b0$@com> : One way would to get the spec written into a major US gov't procurement bid : as a requirement. > You mean like ISO/OSI networking? Yes, indeed. If hadn't been written into most RFP's as a requirement, it would never have happened, because as you well know, no one else wanted it. -ch From ch at murgatroid.com Sun Feb 10 21:12:34 2008 From: ch at murgatroid.com (christopher hoover) Date: Sun, 10 Feb 2008 18:12:34 -0800 Subject: [LEAPSECS] a modest proposal In-Reply-To: <66527.1202666302@critter.freebsd.dk> References: Your message of "Sun, 10 Feb 2008 09:32:09 PST." <000001c86c0a$dd3f11f0$97bd35d0$@com> <66527.1202666302@critter.freebsd.dk> Message-ID: <003301c86c53$90e85610$b2b90230$@com> >>One way would to get the spec written into a major US gov't procurement bid >>as a requirement. > Yes, that will give you a proof of concept implementation. I wonder if I haven't explained myself well. If you get the requirement written into a major procurement proposal, along with establishing a qualifying test suite -- these are typically run by NIST, this alone will get a number of vendors to implement it in major operating systems. (And hopefully one of them will donate the implementation to open source.) This is the story -- possibly apocryphal -- of the origin of the POSIX layer in Window NT. (NIST has a POSIX compliance test suite.) Vendors do a lot of extra work to make it possible to win these contracts. Sometimes it is stupid make-work, like the OSI stack. -ch From seaman at noao.edu Sun Feb 10 22:12:43 2008 From: seaman at noao.edu (Rob Seaman) Date: Sun, 10 Feb 2008 20:12:43 -0700 Subject: [LEAPSECS] a modest proposal In-Reply-To: <93448.1202684692@critter.freebsd.dk> References: <93448.1202684692@critter.freebsd.dk> Message-ID: <3C72C762-30DC-4A94-9DCA-B98A6601B720@noao.edu> Poul-Henning Kamp wrote: > I think we have been over this ground before. Well, knock me over with a feather! > It obviously follows, that with leap second granularity of 1 SI > second, you need to keep track of the residual also, so your > telescope already uses (UTC + DUT1), effectively UT1, for pointing, > right ? No. Some applications are DUT1 aware. Many are not, precisely because DUT1 is required to be small. The former will be subject to Y2K-like failures. The latter will require more drastic rewriting of algorithms. This will clearly be a much larger expense to astronomy than Y2K. Moving on... >> Which is it? Either the cessation of leap seconds is a complex >> question that demands a well thought out plan - or the cessation of >> leap seconds is a simple question for which a plan would be trivial >> to generate at the level of nuance required. Either way, is it too >> much to expect that an actual plan be written? > > I would expect, that the plan may be written down on the back of a > napkin somewhere, having the following substance: > > 1. Ratify changed document. > > 2. Announce changed document. > > 3. Mail copy to BIPM. > > 4. Case closed -- not our problem any more. > > That is a large part of the attractiveness of just dropping leap- > seconds. A monk asked Chao-chou, "Has the cow Buddha nature or not?" Chao-chou said, "Mu." - Rob From phk at phk.freebsd.dk Mon Feb 11 02:32:25 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 11 Feb 2008 07:32:25 +0000 Subject: [LEAPSECS] a modest proposal In-Reply-To: Your message of "Sun, 10 Feb 2008 18:12:34 PST." <003301c86c53$90e85610$b2b90230$@com> Message-ID: <95212.1202715145@critter.freebsd.dk> In message <003301c86c53$90e85610$b2b90230$@com>, "christopher hoover" writes: > >>>One way would to get the spec written into a major US gov't procurement >bid >>>as a requirement. > >> Yes, that will give you a proof of concept implementation. > >I wonder if I haven't explained myself well. I think you didn't understand Warners point: Getting the software written is the least part of the trouble, as OSI showed, getting people to use it is far harder. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dot at dotat.at Mon Feb 11 08:31:17 2008 From: dot at dotat.at (Tony Finch) Date: Mon, 11 Feb 2008 13:31:17 +0000 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080210043602.GA14616@ucolick.org> References: <20080210043602.GA14616@ucolick.org> Message-ID: On Sat, 9 Feb 2008, Steve Allen wrote: > > I think that POSIX time_t should be redefined to be TI, with no leap > seconds. I think that the leap seconds should be included in the > zoneinfo files. POSIX already allows that the local time can be > offset by an arbitrary number of seconds (not just hours and minutes) > from the system value of time_t. The mechanism by which this is > communicated to POSIX systems is zoneinfo. The zoneinfo maintainers > are accustomed to making changes many times a year, with almost no > advance notice, subject to whims of political entities which are > much less predictable than leap seconds. > > This keeps the simplicity of POSIX system time with the only cost > being one of interpretation: the system time_t is TI, and UTC be an > entity derived using zoneinfo. This is quite an attractive idea. I wonder how to deal with some of the consequences: How should the kernel interpret time stamps stored in filesystems? Do you propose to retrospectively re-interpret them as being in TI instead of POSIX time? (This is related to the problem that Unixes have with FAT filesystems that store timestamps in some unspecified local time, which implies that the kernel can't be ignorant of local time.) How do you cope with programs that assume that POSIX time is UTC, and which therefore bypass the tz code when handling UTC timestamps? How do you represent TI textually? i.e. how should ISO 8601 be revised? How does this affect NTP, which uses a POSIX-like timescale? I note that the tz code has had support for your proposal for a very long time, though it requires compile-time configuration to enable it. (The tzdata distribution also includes a leapseconds file, though it has not been updated to bulletin C 35 yet.) Yet no-one ships systems configured this way. > This allows all the bureaus of the IERS to continue to represent to > their funding agencies that their work is essential for the purposes > of telling the world what time it is. (If UTC were redefined instead > of replace with TI, the earth rotation monitoring of the IERS becomes > moot from the standpoint of commerce.) Surely its work on the ITRF is still needed for satellite navigation. Tony. -- f.a.n.finch http://dotat.at/ BAILEY: SOUTHERLY 7 TO SEVERE GALE 9 DECREASING 4 OR 5, VEERING NORTHWESTERLY IN NORTH LATER. VERY ROUGH OR HIGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. From magnus at rubidium.dyndns.org Mon Feb 11 08:52:01 2008 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Mon, 11 Feb 2008 14:52:01 +0100 (CET) Subject: [LEAPSECS] a modest proposal In-Reply-To: References: <20080210043602.GA14616@ucolick.org> Message-ID: <20080211.145201.75173118839584719.cfmd@bredband.net> From: Tony Finch Subject: Re: [LEAPSECS] a modest proposal Date: Mon, 11 Feb 2008 13:31:17 +0000 Message-ID: > On Sat, 9 Feb 2008, Steve Allen wrote: > > > > I think that POSIX time_t should be redefined to be TI, with no leap > > seconds. I think that the leap seconds should be included in the > > zoneinfo files. POSIX already allows that the local time can be > > offset by an arbitrary number of seconds (not just hours and minutes) > > from the system value of time_t. The mechanism by which this is > > communicated to POSIX systems is zoneinfo. The zoneinfo maintainers > > are accustomed to making changes many times a year, with almost no > > advance notice, subject to whims of political entities which are > > much less predictable than leap seconds. > > > > This keeps the simplicity of POSIX system time with the only cost > > being one of interpretation: the system time_t is TI, and UTC be an > > entity derived using zoneinfo. > > This is quite an attractive idea. I wonder how to deal with some of the > consequences: > > How should the kernel interpret time stamps stored in filesystems? Do you > propose to retrospectively re-interpret them as being in TI instead of > POSIX time? (This is related to the problem that Unixes have with FAT > filesystems that store timestamps in some unspecified local time, which > implies that the kernel can't be ignorant of local time.) > > How do you cope with programs that assume that POSIX time is UTC, and > which therefore bypass the tz code when handling UTC timestamps? > > How do you represent TI textually? i.e. how should ISO 8601 be revised? The trouble with this proposal is that "TI" will in a few years time be as arbitrary as "TAI" with the only major difference is the magical 33 or 34 second offset. It would be much more sensible to use TAI directly IMHO. The ISO 8601 problem would be the same thought. > How does this affect NTP, which uses a POSIX-like timescale? NTP would require to support both UTC and TAI/TI to be usefull, else we have to toss NTP over the shoulder and start from the beginning. Cheers, Magnus From sla at ucolick.org Mon Feb 11 13:40:32 2008 From: sla at ucolick.org (Steve Allen) Date: Mon, 11 Feb 2008 10:40:32 -0800 Subject: [LEAPSECS] a modest proposal In-Reply-To: References: <20080210043602.GA14616@ucolick.org> Message-ID: <20080211184032.GA21325@ucolick.org> On Mon 2008-02-11T13:31:17 +0000, Tony Finch hath writ: > How should the kernel interpret time stamps stored in filesystems? Do you > propose to retrospectively re-interpret them as being in TI instead of > POSIX time? (This is related to the problem that Unixes have with FAT > filesystems that store timestamps in some unspecified local time, which > implies that the kernel can't be ignorant of local time.) I suggest that the question of retrospective time stamps is not interesting, for it is rarely possible to be sure that a system clock was set "correctly", and it is never possible to convince history to revise its notion of what time it thought it was (today is George Washington's birthday, O.S.). The interoperational scenario of POSIX systems, Windows systems, NTP, and anything else which is making an effort to maintain filesystem timestamp synchrony deserves closer analysis. > How do you cope with programs that assume that POSIX time is UTC, and > which therefore bypass the tz code when handling UTC timestamps? My impression is that if TI is internationally endorsed (BIPM has already indicated openly that if UTC were to abandon leaps they might consider abandoning TAI) then it is mostly a change in documentation to say that such codes will henceforth be handling the international standard TI instead of the other international standard UTC. > How do you represent TI textually? i.e. how should ISO 8601 be revised? Given that the ephemerides all started making plain distinction between time scales starting in the year I was born I'm flabbergasted to note that ISO 8601 did not already face this issue. Plainly the IAU's long-time recommendations that the time scale be explicit belong in ISO 8601. Until then TI will not be representable. > How does this affect NTP, which uses a POSIX-like timescale? My impression was that NTP already has more than enough complexity to handle the situation. It already has a monotonic time scale which can tolerate leaps, but is distinct from any civil or scientific standard therefore requiring a formatting or conversion to other operational time scales. My point in this whole exercise is basically admitting that in a world of machine-assisted telecommunications the underlying operational time scale need be monotonic. In such a world mean solar time is equally conventional with daylight/summer time shifts. > Surely its work on the ITRF is still needed for satellite navigation. Agreed, but somehow I get the impression that will not catch the attention of legislators and bureaucrats nearly as well as pointing out that their earth rotation measurements directly affect how they set their watches. I expect the IERS would lose a lot of visibility and political clout without leap seconds. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From paul_j at ste-marie.org Mon Feb 11 16:25:05 2008 From: paul_j at ste-marie.org (Paul J. Ste. Marie) Date: Mon, 11 Feb 2008 13:25:05 -0800 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080211184032.GA21325@ucolick.org> References: <20080210043602.GA14616@ucolick.org> <20080211184032.GA21325@ucolick.org> Message-ID: <47B0BD31.6030707@ste-marie.org> Steve Allen wrote: > ... (BIPM has > already indicated openly that if UTC were to abandon leaps they might > consider abandoning TAI) ... I thought TAI/TDT/TDB had all been superseded by some later standard. Was it just the TDx's that were replaced? From paul_j at ste-marie.org Mon Feb 11 16:27:14 2008 From: paul_j at ste-marie.org (Paul J. Ste. Marie) Date: Mon, 11 Feb 2008 13:27:14 -0800 Subject: [LEAPSECS] a modest proposal In-Reply-To: <47B0BD31.6030707@ste-marie.org> References: <20080210043602.GA14616@ucolick.org> <20080211184032.GA21325@ucolick.org> <47B0BD31.6030707@ste-marie.org> Message-ID: <47B0BDB2.3020304@ste-marie.org> Apologies. That was supposed to by a private reply to Steve. I hate Reply-To munging. From jsm at polyomino.org.uk Mon Feb 11 16:43:50 2008 From: jsm at polyomino.org.uk (Joseph S. Myers) Date: Mon, 11 Feb 2008 21:43:50 +0000 (UTC) Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080211184032.GA21325@ucolick.org> References: <20080210043602.GA14616@ucolick.org> <20080211184032.GA21325@ucolick.org> Message-ID: On Mon, 11 Feb 2008, Steve Allen wrote: > On Mon 2008-02-11T13:31:17 +0000, Tony Finch hath writ: > > How should the kernel interpret time stamps stored in filesystems? Do you > > propose to retrospectively re-interpret them as being in TI instead of > > POSIX time? (This is related to the problem that Unixes have with FAT > > filesystems that store timestamps in some unspecified local time, which > > implies that the kernel can't be ignorant of local time.) > > I suggest that the question of retrospective time stamps is not > interesting, for it is rarely possible to be sure that a system clock > was set "correctly", and it is never possible to convince history to > revise its notion of what time it thought it was (today is George > Washington's birthday, O.S.). The question does not relate to the *correctness* of those timestamps, it's a case where consistency is much more important than correctness. If a system has a timestamp and exports an interpretation of that timestamp, and another system stores that interpretation or a second timestamp derived from it, and then one system changes its interpretation, the timestamps are no longer in sync between the two systems. This can cause issues such as unnecessary remirroring of very large amounts of data whose timestamps no longer match at the two ends. See http://lists.debian.org/debian-user/1997/03/msg00075.html for an example of this from when Debian made the mistake of trying to go it alone with a different interpretation of timestamps. There are further discussions in the debian-devel archives from March-May 1997 of things that broke. If you do not change the timestamp interpretation formula in POSIX, but stop inserting leap seconds at some point (or define that timestamps after that point are in TI not UTC), you can avoid the issue of reinterpreting existing timestamps. If time signals start giving TI and so de facto civil time becomes based on TI without associated legal changes, of course you bring back 19th century legal problems and enrich the lawyers. We know that a nine second difference (between TI used by clocks and GMT as a basis for legal time, say) is sufficient to be legally significant: http://www.theregister.co.uk/2007/11/07/delay_sinks_unfair_dismissal_claim/ -- Joseph S. Myers jsm at polyomino.org.uk From seaman at noao.edu Tue Feb 12 01:27:34 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 11 Feb 2008 23:27:34 -0700 Subject: [LEAPSECS] Regarding the ITU's very immodest proposal In-Reply-To: <80ADA4E1-8F73-437B-80A4-CFF55BB908DE@noao.edu> References: <93448.1202684692@critter.freebsd.dk> <3C72C762-30DC-4A94-9DCA-B98A6601B720@noao.edu> <80ADA4E1-8F73-437B-80A4-CFF55BB908DE@noao.edu> Message-ID: <978E42EC-2ADC-4C8D-80B4-68C919632266@noao.edu> > A monk asked Chao-chou, "Has the cow Buddha nature or not?" Chao- > chou said, "Mu." I suppose one should explain, though explanation subverts the koan. "Mu" is a call to unask a question. Replace "cow" with "dog" and copy the koan into a search box for pages of commentary and historical context. Apologies for the sophomoric pun. Planning is an unalloyed good for system design. Complex designs cannot proceed without it. Whereas planning for simple designs costs little and can reveal significant deficiencies and missed opportunities. The benefits always outweigh the expense. To suggest that a particular project demands that planning must not occur is batty. Hence "mu". Rather, I think such a bizarre political maneuver is a tacit admission that planning would reveal deficiencies in the conception of the project. (I'll spare my familiar opinions about what those deficiencies might be.) Every comment about some challenge facing an alternative proposal (such as Steve's) represents a mirror challenge that should be clearly addressed in a carefully drafted proposal for the ITU scheme. They are seeking to redefine the nature of civil timescales worldwide - ask yourself why a decision is being made in haste, behind closed doors and without a plan. No - I don't think it's a conspiracy, rather I think their idea is half-baked and they know it. Just some of the questions that should be addressed before proceeding to adopt any change to UTC: 1) What funding is required? Where will that funding come from? 2) How will timekeeping roles change? What organizations will fulfill these roles? 3) Eventually the embargoed leap seconds must be released. How will this happen? 4) Is there some connection with the standard time zone offsets? How will this be handled? 5) What risks are being mitigated by the change? How is improvement to be evaluated? 6) What risks may be introduced by the change? How will the new risks be gauged? 7) What communities will be disproportionately affected? How will this be mitigated? 8) Redefining UTC will amplify the importance of DUT1. How will DUT1 be promulgated? (Not exhaustive and in no particular order. Others will likely occur to you.) I'm not looking for this group to address these questions (and the many others). Rather, the authors of the non-proposal now stewing at the ITU should draft a real proposal - an actual plan, schedule and WBS responsive to clearly delineated use cases and requirements. Is it really too much to expect to see a professionally conceived trade-off study and risk analysis? Or is it just that in a fair fight the status quo (continuing leap seconds) is anticipated to beat the pants off the competition? Rob Seaman National Optical Astronomy Observatory From phk at phk.freebsd.dk Tue Feb 12 10:03:46 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 12 Feb 2008 15:03:46 +0000 Subject: [LEAPSECS] Regarding the ITU's very immodest proposal In-Reply-To: Your message of "Mon, 11 Feb 2008 23:27:34 MST." <978E42EC-2ADC-4C8D-80B4-68C919632266@noao.edu> Message-ID: <5209.1202828626@critter.freebsd.dk> In message <978E42EC-2ADC-4C8D-80B4-68C919632266 at noao.edu>, Rob Seaman writes: >Every comment about some challenge facing an alternative proposal >(such as Steve's) represents a mirror challenge that should be clearly >addressed in a carefully drafted proposal for the ITU scheme. Yes, but you seem to misunderstand what ITU is and what it does. ITU is just a forum for holding referendums on documents. >Just some of the questions that should be addressed before proceeding >to adopt any change to UTC: > >1) What funding is required? Where will that funding come from? ITU in general do not consider money in any form. They have several times proposed big technical schemes that would have cost fortunes for no realistic benefit of the same scale. All we have to show for vast amount of wated money on the earlier mentioned OSI protocol, is the fact that LDAP is X.500 based and SNMP and cryptography uses ASN.1. >2) How will timekeeping roles change? What organizations will fulfill >these roles? Nothing will change for ITU, since ITU does not have any operational responsibilities. BIPM gets a job less, but that and any other change is not ITUs problem, these are all left as an exercise to the member countries. >3) Eventually the embargoed leap seconds must be released. How will >this happen? "This is subject for further study" This is what ITU writes about any hard problem, such as the conversion from voice to teletex in the X.400 email standard. Compared to some of the other issues ITU has pushed in front of it, this one is quite benign. >4) Is there some connection with the standard time zone offsets? How >will this be handled? This is not relevant to ITU, time zones are under memberstates jurisdiction. >5) What risks are being mitigated by the change? How is improvement >to be evaluated? These at the kind of things member countries should think carefully about before they vote. >6) What risks may be introduced by the change? How will the new risks >be gauged? ditto. >7) What communities will be disproportionately affected? How will >this be mitigated? ditto. >8) Redefining UTC will amplify the importance of DUT1. How will DUT1 >be promulgated? That is also not ITU-s problem. Whoever needs DUT1 propagation, will have to solve that. (Subject, of course, to T&F transmission formats and frequency allocation, which is ITU's resort, should they opt for radio broadcasting.) >(Not exhaustive and in no particular order. Others will likely occur >to you.) But these are not the questions in front of ITU, the question in front of ITU is limited to: "Will this proposal be approved, yes/no". The work in WP7A and any other WP is just to weed out proposals that will have no realistic chance of getting approval and to try to avoid wasting effort with competing proposals. The judgment of the proposals _actual_ merit happens before and through the vote in plenum. If you want to have an effect on that, find out who waves the flag for your country, and convince them to wave the way you want. In other words: You're barking up the wrong tree: yelling at the secretary doing the text-procesing will not help your cause. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dot at dotat.at Tue Feb 12 10:55:25 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 12 Feb 2008 15:55:25 +0000 Subject: [LEAPSECS] a modest proposal In-Reply-To: <47B0BD31.6030707@ste-marie.org> References: <20080210043602.GA14616@ucolick.org> <20080211184032.GA21325@ucolick.org> <47B0BD31.6030707@ste-marie.org> Message-ID: On Mon, 11 Feb 2008, Paul J. Ste. Marie wrote: > Steve Allen wrote: > > ... (BIPM has > > already indicated openly that if UTC were to abandon leaps they might > > consider abandoning TAI) ... > > I thought TAI/TDT/TDB had all been superseded by some later standard. Was it > just the TDx's that were replaced? TT replaced TDT. It's used as a benchmark to check the uniformity of the realization of TAI. TDB is a separate timescale decoupled from the Earth. Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: WESTERLY 5 TO 7 BECOMING VARIABLE 3 OR 4 THEN EASTERLY 6 OR 7, PERHAPS GALE 8 LATER. ROUGH OR VERY ROUGH . RAIN LATER. MODERATE OR GOOD. From dot at dotat.at Tue Feb 12 11:05:45 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 12 Feb 2008 16:05:45 +0000 Subject: [LEAPSECS] a modest proposal In-Reply-To: References: <20080210043602.GA14616@ucolick.org> <20080211184032.GA21325@ucolick.org> Message-ID: On Mon, 11 Feb 2008, Joseph S. Myers wrote: > > If a system has a timestamp and exports an interpretation of that > timestamp, and another system stores that interpretation or a second > timestamp derived from it, and then one system changes its interpretation, > the timestamps are no longer in sync between the two systems. This can even happen within a single program, if one code path gets time straight from the kernel, and one goes via the tz code. At the moment these are guaranteed to be consistent when the time zone offset is zero. Steve's idea removes this guarantee, which is likely to lead to bugs. Tony. -- f.a.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHEAST BECOMING VARIABLE 3 OR 4. SMOOTH OR SLIGHT. FOG BANKS. MODERATE OR VERY POOR. From imp at bsdimp.com Tue Feb 12 11:18:08 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue, 12 Feb 2008 09:18:08 -0700 (MST) Subject: [LEAPSECS] a modest proposal In-Reply-To: References: <20080211184032.GA21325@ucolick.org> Message-ID: <20080212.091808.232837362.imp@bsdimp.com> In message: Tony Finch writes: : On Mon, 11 Feb 2008, Joseph S. Myers wrote: : > : > If a system has a timestamp and exports an interpretation of that : > timestamp, and another system stores that interpretation or a second : > timestamp derived from it, and then one system changes its interpretation, : > the timestamps are no longer in sync between the two systems. : : This can even happen within a single program, if one code path gets time : straight from the kernel, and one goes via the tz code. At the moment : these are guaranteed to be consistent when the time zone offset is zero. : Steve's idea removes this guarantee, which is likely to lead to bugs. I can 100% guarantee that there will be bugs. I've seen lots of code that knows these two sources of time are the same. Because, like why would there be more than one notion of time... Warner From seaman at noao.edu Tue Feb 12 11:39:59 2008 From: seaman at noao.edu (Rob Seaman) Date: Tue, 12 Feb 2008 09:39:59 -0700 Subject: [LEAPSECS] Regarding the ITU's very immodest proposal In-Reply-To: <5209.1202828626@critter.freebsd.dk> References: <5209.1202828626@critter.freebsd.dk> Message-ID: <5000A55D-7404-4E9F-B710-A14B816BF941@noao.edu> Some days I feel like my shadow's casting me... In the Fall of 1999, Judah Levine contacted an astronomer regarding our community's interest in seeing leap seconds continue. The astronomer contacted the U.S. National Observatory (NOAO), and its director, or one of his or her minions, contacted me to look into it. I say "his or her", because NOAO is a complex institutional entity with facilities both north and south of the equator, covering both nighttime and solar astronomy, the optical and the infrared, and with several sister organizations such as the Space Telescope Science Institute. So at this late date I don't recall who passed Levine's email on to me, and the tale doesn't depend on it. As of a year ago there were 116 subscribers to the original LEAPSECS mailing list. The subscribers aren't available for the current list, but I presume the count remains several dozen. So, for more than eight years, several dozen people have been interested enough in the question of civil timekeeping to continue posting and reading posts that are often fractious and tedious. This is quite remarkable. Over all that time, it has been unclear exactly what entities are pushing the inane initiative to eliminate leap seconds. So, when I say "ITU", it is indeed eminently true that I'm implicating a drab body of unimaginative technocrats, but I simply don't know who better to address. And this tale doesn't depend on it. My point remains the same. Timekeeping is important (else why are we all here?) and any change to timekeeping standards deserves the best planning activities we can muster. Going out of your way to avoid planning such a transition is laughably pathetic and potentially criminal. Without a plan, what possible basis is there to claim that risks won't increase dramatically when we start pretending the two types of time ("atomic time" and Earth orientation) are one and the same? That Steve's suggestion is being subjected to criticism is a good thing. Why not invest in a formal trade-off study between several candidate options, including but not limited to: TI, UTC w/o leaps, and UTC with leaps? (A good trade-off study always includes the status quo.) Either the "ITU proposal" (misattributed or not) will triumph in a fair trade-off comparison - or it won't. I have to believe that the funding agencies in the U.S. would look at a proposal to conduct such a trade-off study quite favorably. Surely European funding could be identified as well. It is precisely the constant rush to judgement that has kept such obvious studies from being conducted before now. And it is precisely such studies that can provide a mechanism to form a durable consensus among the factions represented on this mailing list. ...Some days the sun don't shine Rob From msokolov at ivan.Harhan.ORG Tue Feb 12 14:24:17 2008 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Tue, 12 Feb 2008 19:24:17 GMT Subject: [LEAPSECS] Regarding the ITU's very immodest proposal Message-ID: <0802121924.AA22829@ivan.Harhan.ORG> Rob Seaman wrote: > Over all that time, it has been unclear exactly what entities are > pushing the inane initiative to eliminate leap seconds. So, when I > say "ITU", it is indeed eminently true that I'm implicating a drab > body of unimaginative technocrats, but I simply don't know who better > to address. And this tale doesn't depend on it. I think I know who they are. They are the PHKs of this world. There are plenty of people in our world who believe that their computers are more important than the planet we live on. Although we don't know exactly who are the people behind WP7A, I think our own PHK is a perfectly good example of what those people are like. "Mean solar time be damned, my computers don't care if the Sun is up or not!" The invisible entities behind WP7A probably have more political clout than our own dear PHK, but that's probably the only difference. If my hypothesis is correct in that the ITU people are like PHK, it would follow that you and Steve are wasting your breath trying to reason or plead with them. PHK has already told you that he is deaf to your pleas for mean solar time, he'll walk right over you because his systems outnumber yours 100000 to 1. The same would go for the ITU WP7A gang if their mindset is the same as PHK's, as my hypothesis argues. If this is the case, I think that those of us who care about mean solar time need to take a totally different approach. Stop wasting our breath pleading to those who have already damned us, and commit civil disobedience instead. Forget about UTC and cut our losses. Go back to the old way we've used before UTC was invented. Commit civil disobedience by disregarding ITU orders and their leapless "UTC" radio broadcasts, and set your wristwatch, your wall clock, the clocks on your stove, microwave, PC and cellphone from your backyard analemmatic sundial instead. Run your own personal life on mean solar time in direct defiance to the orders of the time lords. This is what I am personally prepared to do. Who else is with me? I also wonder what will Monsieur Gambis do when push comes to shove... When the day comes when ITU orders him to stop sending out Bulletin C, will he have the courage to defy the bastards and continue sending leap second announcements from his home PC during off-work hours? If they don't allow him to use mailing lists hosted at obspm.fr for this purpose, there will be a long lineup of private citizens offering the use of their mailing list servers - I'll be the first to offer mine! Goddess Bless, MS From phk at phk.freebsd.dk Tue Feb 12 15:13:47 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 12 Feb 2008 20:13:47 +0000 Subject: [LEAPSECS] Regarding the ITU's very immodest proposal In-Reply-To: Your message of "Tue, 12 Feb 2008 19:24:17 GMT." <0802121924.AA22829@ivan.Harhan.ORG> Message-ID: <7222.1202847227@critter.freebsd.dk> In message <0802121924.AA22829 at ivan.Harhan.ORG>, Michael Sokolov writes: >Rob Seaman wrote: >I think I know who they are. They are the PHKs of this world. I am honoured to be made the clavis of an entire population segment, but I think you have confused my *interpretation* of the situation with my *opinion* about the situation and therefore ascribe me a single-mindedness about the issue, which I don't posses. It's a common mistake, not being able to tell opinion from interpretation, because most people don't have more than the same, those of us are capable of seeing things from more than two sides at once get used to it after some time. So let me make my *opinion* clear: I have only one thing against leap-seconds: they don't work in practice because the six month warning is an order of magnitude to short. I'm totally agnostic on the question of solar time or for that matter, the duration of the second, and all that. (As a time-nut I love to play with it, but that's a different story). All I want for the worlds computerbased infrastructure, is a time definition that has at least 20 times longer than a six month horizon of predictability. Therefore my first proposal was: Change the rules as follows: "Leap seconds must be announced 10 years in advance". 10 years warning is fine for the computer business, we'll get around to update the table before then, it can be done during regular software maintenance, instead of as a mad scramble where nobody know anything or have time to test anything properly. There is still a lot of expenses for coding, testing and fall out from bugs in the code, and that must be counted on the balance sheet against the value of leap second adjustment. The obvious fall-out is that the +/- 1s DUT1 cannot be guaranteed, unless BIPM's models are good enough, and they'd better be because the tolerance band needs to go from the text: we can't have two conflicting rules. But exactly because I'm totally agnostic on solar time, the obvious follow up question is: why leap seconds at all ? People live up to 5 hours away from solar time already today, so it cannot be very important to have the sun in south at noon. So we can save the expense of handling leap-seconds in software entirely by dropping leapseconds. We would have to maintain earth rotatation angle as a scientic exercise, along with all the other earth rotation parameters. This already happens with greater precision than UTC ever had. If informing the world, as such, that the civil time makes a jump in six months time can be done by email, it is unlikely that the dissemination of the earth rotation angle is going to be a technical challenge for the highly intelligent usercommunity of that measurement. We can leave any necessary adjustments to civil time, if/when night turns into day, to the national governments who already are far too keen to fiddle timezones for their own economic welfare. Downside ? People with thing pointing to extraterrestial objects are going to be cross, but they'll get over it. And that is, pretty close, the proposal in WP7A, except they mention the "leap-hours" as a silly figleaf to the astronomers and other die-hard sun-in-the-south-at-noon (mostly religious) addicts. There, now you know my *opinon*, then let me give you the *interpretation* also: USA launched the proposal in WP7A. We have, as far as I know, never identified which agency, branch or entity in USA was the instigator, but there is plenty of reason to suspect the strategic forces and their expensive standdown routine whenever too many digits on the clock changes at the same time. Although, I wouldn't be surprised if people in Air Traffic Control and to some extent telecoms have nodded violently in agreement. Nothing of any technical nature has any influence on the proposals chances of getting ratified in ITU, that's purely a matter of politics, most of it under the radar at civil servant level, and once the plenum vote approaches, also at ambasador level if USA feels badly enough for this. All the moral high ground studies, propoals, round-tables Rob is looking for, are not going to happen if the people behind the proposal can avoid it: We know their aim is to kill leap-seconds as fast as possible (from the fact that the original proposal tried to preempt the next likely leap-second). Therefore, if Rob wants to keep leap seconds, he knows where to go: Find the people in USA who are pushing, and offer them a better suggestion, that works both for him, and them. If, as you claim, I am the clavis for this group, then Rob can use my *opinion* above to guide that effort, but don't take it for dicta. And should we stop the name-calling while we're at it ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From sla at ucolick.org Tue Feb 12 21:38:06 2008 From: sla at ucolick.org (Steve Allen) Date: Tue, 12 Feb 2008 18:38:06 -0800 Subject: [LEAPSECS] how bad precision timekeeping was Message-ID: <20080213023806.GA9433@ucolick.org> I've got a lot of documents from the 1960s which indicate what was going on with precise time. I've got a lot of retrospectives about who did what. Many of these documents I can't just put on the web. Even if they were on the web they require translation or footnoting because they use jargon which was still in development and which has since been discarded. There is one public document which presents the picture in pretty plain language. It was developed for NASA by a geodecist who had to sit down with Markowitz in order to get the picture and then write it all down in a way that folks not in the time bureaus could grok. http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19660020453_1966020453.pdf See the amount of effort that went into producing precise time, and in changing the published conventional longitudes of every time observing station on earth. See the amount of effort that went into decoding broadcast signals in order to figure out their meaning and make use of them for any precision purpose. That horror is what the CCIR was fixing when they adopted UTC with leap seconds, which they did unilaterally despite calls for discussion by a handful of international scientific organizations. And that document dates from before there was cesium at all the transmitter locations for LORAN-C (imagine what it was like on New Years Eve when entire chains of LORAN-C had to have techs on duty to implement time steps along with carrier frequency and modulation shifts). There are other documents from the 1970s which indicate significant dissatisfaction with the new scheme of UTC, and with the way the CCIR mandated it. (My impression is that the discussions in hallways and at dinner parties were very interesting at the conferences with people who were members of both CCIR and the committees of the various scientific organizations.) On Tue 2008-02-12T20:13:47 +0000, Poul-Henning Kamp hath writ: > I have only one thing against leap-seconds: they don't work in > practice because the six month warning is an order of magnitude > to short. We have ample experience that nobody can tell the legislators and bureaucrats not to mess around with summer/daylight time transition dates, so we all have to deal with regular updates to the zoneinfo mechanisms if we want our systems to produce the legal civil time. If we move the leap seconds into that same mechanism we allow the underlying broadcast and computer time scales to become uniformly monotonic. Daniel Gambis always gives more notice to the whole world than Hugo Chavez did to Venezuela last year. > So we can save the expense of handling leap-seconds in software > entirely by dropping leapseconds. We have to resign ourselves to the expense of updating zoneinfo, or the equivalents in Windows, and cell-phone towers, and anything else that uses precision time and purports to supply civil time too. Zoneinfo in its POSIX implementation includes enough ability to handle the leap seconds. Yes, most actions by the ITU-R have costs to various parties. Despite the dissatisfaction, what the CCIR did in 1970 was a compromise. We have the mechanisms in place to support a compromise. Dropping leap seconds entirely would not be a compromise. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From phk at phk.freebsd.dk Wed Feb 13 02:53:28 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 13 Feb 2008 07:53:28 +0000 Subject: [LEAPSECS] how bad precision timekeeping was In-Reply-To: Your message of "Tue, 12 Feb 2008 18:38:06 PST." <20080213023806.GA9433@ucolick.org> Message-ID: <10104.1202889208@critter.freebsd.dk> In message <20080213023806.GA9433 at ucolick.org>, Steve Allen writes: >We have ample experience that nobody can tell the legislators and >bureaucrats not to mess around with summer/daylight time transition >dates, so we all have to deal with regular updates to the zoneinfo >mechanisms if we want our systems to produce the legal civil time. Correct, but for stupidity at this level, politicians can be held accountable in their constituency. But besides, timezones are an entirely different kettle of fish than leap-seconds: Time-zones is just a representation format which does not get involved until you try to represent a timestamp for a human being, whereas leap-seconds affect the raw timestamp. This is why ATC systems use UTC, that way an airline pilot does not need to have a fully up to date zoneinfo file in his pocket: part of the tower protocol is to announce the local time before planes land, information which the captain on commercial flights usually relays verbatim to the passengers. >If we move the leap seconds into that same mechanism we allow the >underlying broadcast and computer time scales to become uniformly >monotonic. Daniel Gambis always gives more notice to the whole world >than Hugo Chavez did to Venezuela last year. But still not enough notice to let the computer geeks handle this in a sane fashion. >We have to resign ourselves to the expense of updating zoneinfo, >or the equivalents in Windows, and cell-phone towers, and anything >else that uses precision time and purports to supply civil time too. If I remember the numbers right, we should expect countries to start shifting one hour in about 150 years, right ? 150 years ago Edison was 11 years old. But yes, zoneinfo changes must be expected, but the changes will be national, and that means if some raving politician tries to change the timezone with too short notice, his country have a mechanism for dealing with him. Nobody can seem to do much about Daniel Gambis and his short notices. Ohh, wait... That's what WP7A's proposal is about, isn't it ? :-) >Yes, most actions by the ITU-R have costs to various parties. >Despite the dissatisfaction, what the CCIR did in 1970 was a compromise. >We have the mechanisms in place to support a compromise. >Dropping leap seconds entirely would not be a compromise. As I said: come up with a workable proposal, canvas it for the right people, repeat until done. Just crossing your arms and muttering "this isn't right" will not stop the WP7A party. Feel free to use me as the litmus test for your proposals, if you think that helps save you time. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Wed Feb 13 12:57:15 2008 From: seaman at noao.edu (Rob Seaman) Date: Wed, 13 Feb 2008 10:57:15 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <3E0BDAFF-42D1-4567-BB16-9D3F24292F65@noao.edu> References: <7222.1202847227@critter.freebsd.dk> <3E0BDAFF-42D1-4567-BB16-9D3F24292F65@noao.edu> Message-ID: The threads are coming fast and furious. Cutting to the chase. If the precision timekeeping establishment falters in its role of delivering a useful representation of mean solar time, clearly some other community will have to pick up the slack. It is likely not helpful to bring the Goddess into it, but I personally spurn no support offered. The heart of civil timekeeping is the dynamic tension between the two definitions of the "second": - as 1/86400 of a mean solar day, and - as the SI unit of time If this distinction had been made crystal clear in the beginning, we wouldn't be having this discussion now. Recall the historical idea of calling the SI unit the "essen". What if, in addition, the essen had a duration of a size that could not be confused with the fractional part of the day? For example, what if the essen had been chosen such that the acceleration due to gravity was a convenient 1.0 meters per essen-squared. So: 1.0 m/essen^2 = 9.8 m/s^2 1.0 second = 3.13 essen, and 1.0 essen = 0.319 second In this case (or pick some other physically significant value), there never would have been the confusion about counting essens using sexigesimal notation. In particular, a meaningless tally of 86400 essens would have wrapped around 3+ times per day. And the definition of a day - that is, an actual mean solar day - would remain clear. In short, the distinction between the role of the second and the role of the essen in timekeeping architecture would remain obvious. This design pattern can be used to distinguish technically viable solutions - like UTC with leap seconds, and Steve's expression of TI - from technically nonviable solutions like a so-called "UTC" without leap seconds. The role of political expediency in the decision-making would be clear. I won't say expediency still wouldn't triumph over technical common sense, but that fact would be clear to all. > And that is, pretty close, the proposal in WP7A, except they mention > the "leap-hours" as a silly figleaf to the astronomers and other die- > hard sun-in-the-south-at-noon (mostly religious) addicts. Let me - yet again - emphasize that people with diametrically opposed notions of timekeeping all regard the leap hour as an absurd notion. > come up with a workable proposal, canvas it for the right people, > repeat until done. This group is one place the canvas is taking place. Part of making a proposal workable is pointing out the unworkable proposals, especially if the unworkable ones are receiving undue (and unwise) political support. At any rate, glad to see that you agree that the process should focus on characterizing the workability of coherently expressed and properly communicated proposals. That's pretty much what I've been saying for eight years. It is also simply the definition of a trade-off study. I especially like that you focus on this as an iterative process. Rob Seaman National Optical Astronomy Observatory From phk at phk.freebsd.dk Wed Feb 13 15:47:49 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 13 Feb 2008 20:47:49 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Wed, 13 Feb 2008 10:57:15 MST." Message-ID: <19959.1202935669@critter.freebsd.dk> In message , Rob Seaman writes: >The heart of civil timekeeping is the dynamic tension between the two >definitions of the "second": > > - as 1/86400 of a mean solar day, and > - as the SI unit of time I have still not found where the first definition have any importance in civil timekeeping, apart from sundials. Can you give more detail ? >If this distinction had been made crystal clear in the beginning, we >wouldn't be having this discussion now. You are barking up the wrong tree again. The problem at the heart of civil timekeeping is that the rules for counting time are only known for the next six months at any one time. How we count, what we count and what it adds up to in the long run, is totally without relevance in this picture, the problem is, crudely put, that we know how many seconds there are in the next six months, but not the next 12 months. It's not the seconds, it's how we count them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Wed Feb 13 19:02:11 2008 From: seaman at noao.edu (Rob Seaman) Date: Wed, 13 Feb 2008 17:02:11 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <19959.1202935669@critter.freebsd.dk> References: <19959.1202935669@critter.freebsd.dk> Message-ID: <41894EFF-A356-4887-AB85-EB98B0A1754E@noao.edu> In case folks haven't noticed, Steve and I have each (separately) been trying to talk about new topics (or, at least, new facets of old topics :-) Meanwhile...Poul-Henning Kamp replies: >> The heart of civil timekeeping is the dynamic tension between the >> two definitions of the "second": >> >> - as 1/86400 of a mean solar day, and >> - as the SI unit of time > > I have still not found where the first definition have any > importance in civil timekeeping, apart from sundials. Can you give > more detail ? Look back at a hundred arguments in a thousand emails. The "day" is a key concept in our civilization. The "mean solar day" is the natural way to implement this. Sundials have nothing to do with the mean solar day, but rather the apparent solar day. Apparent solar time has nothing to do with either UTC (as we currently know it) or TAI. > The problem at the heart of civil timekeeping is that the rules for > counting time are only known for the next six months at any one time. My colleague, Dr. Steve, and I perceive the heart, you perceive a narrowly construed pathology. Your stethoscope is tuned to the murmur and you aren't hearing the healthy heart sounds (http://en.wikipedia.org/wiki/Heart_sounds ). lub dub...lub dub...lub dub The solution to your problem won't become evident until you perceive the beating heart of the larger design. To stress the analogy perhaps a little too far, the ITU is about to sew up the patient's chest cavity with the forceps still inside. In any event, there are lots of things you will need to know in six months that are hidden from you today. Addressing such issues is simply a requirement placed on whatever systems are involved. > How we count, what we count and what it adds up to in the long run, > is totally without relevance in this picture, the problem is, > crudely put, that we know how many seconds there are in the next six > months, but not the next 12 months. And that is because you are confusing two different meanings of time, that is, of the word "second". > It's not the seconds, it's how we count them. Put your O-O glasses on. It is BOTH the attributes AND the methods of the class called "civil time". Rob Seaman NOAO From phk at phk.freebsd.dk Wed Feb 13 19:21:45 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 00:21:45 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Wed, 13 Feb 2008 17:02:11 MST." <41894EFF-A356-4887-AB85-EB98B0A1754E@noao.edu> Message-ID: <20904.1202948505@critter.freebsd.dk> In message <41894EFF-A356-4887-AB85-EB98B0A1754E at noao.edu>, Rob Seaman writes: Rob, Discussing leap seconds with you is like discussing papal infalibility with a catholic priest. According to you, people like me know nothing, have no problems and don't understand anything about time. I beg to differ. We are getting to the point where your email behaviour could make me cheer the WP7A proposal on, if for no other reason, then out of spite for your snotty treatment of legitimate concerns. Sometimes, I even wonder if you are staging an intricate PR war against leap-seconds, hoping to get them abolished by behaving as an utterly unreasonable block-head ? The reminder in my .signature normally terminates that train of thought. But to show that I'm, still, trying to take you seriously: What are your comments to my proposal to announce leap seconds 10 years in advance ? Could you live with that ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From ashley at semantic.org Wed Feb 13 19:42:10 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Wed, 13 Feb 2008 16:42:10 -0800 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <20904.1202948505@critter.freebsd.dk> References: <20904.1202948505@critter.freebsd.dk> Message-ID: <1202949730.6165.5.camel@sherbourne> On Thu, 2008-02-14 at 00:21 +0000, Poul-Henning Kamp wrote: > What are your comments to my proposal to announce leap seconds > 10 years in advance ? Could you live with that ? Surely this would encourage programmers to hard-code leap-second tables, thus guaranteeing problems after ten years use? At least now software developers are (more) forced to do the right thing. Also, how much error can we expect on a ten-year estimate? This is a quadratic sort of thing, isn't it, what with the angular momentum of the earth? -- Ashley Yakeley Seattle WA From seaman at noao.edu Wed Feb 13 21:52:28 2008 From: seaman at noao.edu (Rob Seaman) Date: Wed, 13 Feb 2008 19:52:28 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <20904.1202948505@critter.freebsd.dk> References: <20904.1202948505@critter.freebsd.dk> Message-ID: <1EE6D186-6694-4CCC-B256-CDCAF8449164@noao.edu> > Discussing leap seconds with you is like discussing papal > infalibility with a catholic priest. The good fathers at Villanova might balk at characterizing me so. I won't respond to the rest of your commentary, other than to point out that "infalibility" is misspelled :-) My general intent is to stay on message whatever the context. I could certainly wish my rhetorical skills were less abrasive, thus more persuasive. > What are your comments to my proposal to announce leap seconds 10 > years in advance? It would require more detail to amount to a proposal... > Could you live with that? ...and a viable process for adopting any sort of proposal requires more extensive vetting :-) That said, I perceive no issues with extending the leap second schedule - per se. The proposal would need to delve into the magnitude of DUT1. While such a possibility was mentioned in the original GPS World piece, the intent has clearly always been to eliminate leap seconds entirely. My own ancient precis for a proposal (http://iraf.noao.edu/~seaman/ leap) also focuses on tweaking the scheduling algorithm and I think there are many possibilities there. It is not the astronomers who have been unwilling to entertain alternative concepts of civil timekeeping. Rob Seaman NOAO From seaman at noao.edu Wed Feb 13 22:58:53 2008 From: seaman at noao.edu (Rob Seaman) Date: Wed, 13 Feb 2008 20:58:53 -0700 Subject: [LEAPSECS] Trying a different angle Message-ID: Q: What do GPS and TI (as described in Torino and by Steve) have in common? A: They are both timescales without leap seconds. Q: And? A: ...and no astronomers are complaining about them. Q: Why not? From phk at phk.freebsd.dk Thu Feb 14 03:14:22 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 08:14:22 +0000 Subject: [LEAPSECS] Trying a different angle In-Reply-To: Your message of "Wed, 13 Feb 2008 20:58:53 MST." Message-ID: <22492.1202976862@critter.freebsd.dk> In message , Rob Seaman writes: >Q: What do GPS and TI (as described in Torino and by Steve) have in >common? >A: They are both timescales without leap seconds. > >Q: And? >A: ...and no astronomers are complaining about them. > >Q: Why not? A: because they would not solve the problem the computer people face. GPS and TI would both have to go through several hundreds of parliaments before computers could avoid dealing with leap-seconds. During the timeperiod where this takes place, neighboring countries would face differences in legal time of up to 30 seconds, if previous changes to time and calendar is any guide. One of the worst cases is the Danish parliament which has still not gotten around to adobt UTC, despite the fact that we actually use it. To achive the desired effect, it has to be UTC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Feb 14 03:16:36 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 08:16:36 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Wed, 13 Feb 2008 19:52:28 MST." <1EE6D186-6694-4CCC-B256-CDCAF8449164@noao.edu> Message-ID: <22512.1202976996@critter.freebsd.dk> In message <1EE6D186-6694-4CCC-B256-CDCAF8449164 at noao.edu>, Rob Seaman writes: >> What are your comments to my proposal to announce leap seconds 10 >> years in advance? > >It would require more detail to amount to a proposal... No, that's all there is to it. I don't care how you decide the leapseconds, or who does, as long as we get know when they happen with 10 years notice. If WP7A pushed a proposal that just changed the text to say that DUT1 should be kept minimal and that warnings must be 10 years, would that work ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Thu Feb 14 08:21:15 2008 From: seaman at noao.edu (Rob Seaman) Date: Thu, 14 Feb 2008 06:21:15 -0700 Subject: [LEAPSECS] Trying a different angle In-Reply-To: <22492.1202976862@critter.freebsd.dk> References: <22492.1202976862@critter.freebsd.dk> Message-ID: <7B7E1BCE-5A8B-4E84-A8BC-A4AEE434E571@noao.edu> Um - might I just point out that GPS already exists and it is possible that more people know the brand name "GPS" than "UTC"? Also, I wouldn't have thought it possible, but your description of the parliamentary process almost makes the bicameral legislative model seem preferable :-) The obvious choice to circumvent both public and governmental inertia is GPS. Label it "TI" in prudently drafted proposal documents and create a commissioning schedule that brings the zoneinfo changes in over several decades. Voila! Bicameral civil time layered on unsegmented GPS, but called TI per Torino and that doesn't eviscerate UTC. Don't underestimate the power of a brand name. -- On Feb 14, 2008, at 1:14 AM, Poul-Henning Kamp wrote: > In message , Rob > Seaman writes: >> Q: What do GPS and TI (as described in Torino and by Steve) have in >> common? >> A: They are both timescales without leap seconds. >> >> Q: And? >> A: ...and no astronomers are complaining about them. >> >> Q: Why not? > A: because they would not solve the problem the computer people face. > > GPS and TI would both have to go through several hundreds of > parliaments > before computers could avoid dealing with leap-seconds. > > During the timeperiod where this takes place, neighboring countries > would face differences in legal time of up to 30 seconds, if previous > changes to time and calendar is any guide. One of the worst cases > is the Danish parliament which has still not gotten around to adobt > UTC, despite the fact that we actually use it. > > To achive the desired effect, it has to be UTC. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. > _______________________________________________ > LEAPSECS mailing list > LEAPSECS at leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs From phk at phk.freebsd.dk Thu Feb 14 08:27:30 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 13:27:30 +0000 Subject: [LEAPSECS] Trying a different angle In-Reply-To: Your message of "Thu, 14 Feb 2008 06:21:15 MST." <7B7E1BCE-5A8B-4E84-A8BC-A4AEE434E571@noao.edu> Message-ID: <24620.1202995650@critter.freebsd.dk> In message <7B7E1BCE-5A8B-4E84-A8BC-A4AEE434E571 at noao.edu>, Rob Seaman writes: >Um - might I just point out that GPS already exists and it is possible >that more people know the brand name "GPS" than "UTC"? It's not a matter of brand recognition, it's a matter of national laws defining civil time in terms of UTC (or one of it's many aliases) and a timezone offset. >Also, I wouldn't have thought it possible, but your description of the >parliamentary process almost makes the bicameral legislative model >seem preferable :-) Well, the bad news is that we had a bicmeral system back in 1893 when the civil danish time was fixes as "the mean solar time at 15 east long." and despite several revisions to our constitution and the abolishment of the upper chamber, it is still not seen as important enough to fix it. I've considered suing the citycouncil of Copenhagen for having a tower clock that shows illegal time, just for fun, but the fun sort of disappeared when it transpired that the danish government informed me that they cannot run a NTP server because it violates danish law. >Don't underestimate the power of a brand name. Don't underestimate the combined inertia of all the worlds governmental bureaucrats having to find all the laws that this might affect. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Thu Feb 14 08:33:26 2008 From: seaman at noao.edu (Rob Seaman) Date: Thu, 14 Feb 2008 06:33:26 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <22512.1202976996@critter.freebsd.dk> References: <22512.1202976996@critter.freebsd.dk> Message-ID: <6387E038-8191-4F5D-BA8D-F6D1DEE3596A@noao.edu> You do understand that my comments about proper planning are broader than leap seconds? System engineering is a well understood discipline by this point. If a technical solution is worth pursuing, it can only be aided by a coherent proposal describing - first - the applicable problem space before asserting a solution, no matter how simple. The question isn't how cut-and-dried the solution is, the question is what are the risks - the alternative solutions - the stakeholders - etc and so forth. I'd be interested to see any proposal out of WP7A other than the one they have. A provision for a 10 year rolling schedule, announced every six months, would be better than what's on the table. But as you see, the process has already improved your "10 years notice" notion. That's what the system engineering process is for. Take a half dozen leading notions and develop all of them to the point that they can be scored according to a grid of characteristics arrived at by stakeholders. Combine the scores according to a formula agreed to in advance. See who wins. If aspects of the grid are in conflict, the group argues about these separate from any one proposal, thus abstracting the conversation to a new level. Folks would undoubtedly like to take engineering for civil timekeeping to a new level, n'est-ce pas? -- On Feb 14, 2008, at 1:16 AM, Poul-Henning Kamp wrote: > In message <1EE6D186-6694-4CCC-B256-CDCAF8449164 at noao.edu>, Rob > Seaman writes: > > >>> What are your comments to my proposal to announce leap seconds 10 >>> years in advance? >> >> It would require more detail to amount to a proposal... > > No, that's all there is to it. > > I don't care how you decide the leapseconds, or who does, as long > as we get know when they happen with 10 years notice. > > If WP7A pushed a proposal that just changed the text to say that > DUT1 should be kept minimal and that warnings must be 10 years, > would that work ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by > incompetence. > _______________________________________________ > LEAPSECS mailing list > LEAPSECS at leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs From seaman at noao.edu Thu Feb 14 08:40:05 2008 From: seaman at noao.edu (Rob Seaman) Date: Thu, 14 Feb 2008 06:40:05 -0700 Subject: [LEAPSECS] Trying a different angle In-Reply-To: <24620.1202995650@critter.freebsd.dk> References: <24620.1202995650@critter.freebsd.dk> Message-ID: > civil danish time was fixes as "the mean solar time at 15 east long." Well, I prefer layering civil time directly on mean solar time, since anybody can recover it directly from the sky -- but as I just demonstrated, I'm willing to entertain other possibilities like the two separate ones in the two preceding messages. The problem with the wording above is that it should be two separate assertions, something like "civil time is layered on mean solar time" and "the Danish realization of civil time should reference the meridian 15 east". The interpretation of your civil servant that NTP is disallowed sounds bogus to me since the transport mechanism for realizing the law(s) is (wisely) left as a matter of interpretation. From phk at phk.freebsd.dk Thu Feb 14 08:56:40 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 13:56:40 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Thu, 14 Feb 2008 06:33:26 MST." <6387E038-8191-4F5D-BA8D-F6D1DEE3596A@noao.edu> Message-ID: <24862.1202997400@critter.freebsd.dk> In message <6387E038-8191-4F5D-BA8D-F6D1DEE3596A at noao.edu>, Rob Seaman writes: >You do understand that my comments about proper planning are broader >than leap seconds? System engineering is a well understood discipline >by this point. Being as it is that I live in the business end of it too often, I am not sure emperical evidence support that claim :-) >If a technical solution is worth pursuing, it can only >be aided by a coherent proposal describing - first - the applicable >problem space before asserting a solution, no matter how simple. Again, you need to understand that I have both an *opinion* about this, and my *interpretation* (or *observation*) about this. The former is what I would prefer to happen, the latter what I expect to happen. When I say that USA, through WP7A is going ram this through, come hell or high water, that is an *observation* of what is going on, it is not an endorsement. No matter what, that is the process anyone must contemplate changing, if they want to get a different outcome from what is being steamrolled through. This is a much bigger problem for you than for me, because I can actually live comfortably if they reach their goal, and as I have said, I can also live less comfortably with a proposal that retains leap-seconds but gives us 10 year horizon on them. You on the other hand, have a position where the WP7A proposal is not in any way acceptable, and thus you have a far higher motivation for doing something. Given that I can be persuaded to retain leap seconds, if I see a sensible proposal, I find it surprising that you consider me on the enemy side, rather than a potential allied. When that is said, we get back to the observation of steam-rolling: If you want to have any influence on this, you need to deal with the steam-roller first. Afterwards you can use Roberts Rules of Order to set up a civilized process. But Roberts Rules of Order are not going to stop the steam-roller, so all the talk about which process, scoring rules and all that, is rearranging the deck-chairs on the Titanic if you do not deal with the steam-roller. My *observation* is that you are in for at tough political fight if you want to attempt this. My *opinion* is that I not going to help you at all, if you don't stop pissing on me. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Thu Feb 14 09:04:08 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 14:04:08 +0000 Subject: [LEAPSECS] Trying a different angle In-Reply-To: Your message of "Thu, 14 Feb 2008 06:40:05 MST." Message-ID: <24946.1202997848@critter.freebsd.dk> In message , Rob Seaman writes: >> civil danish time was fixes as "the mean solar time at 15 east long." >The interpretation of your civil servant that NTP >is disallowed sounds bogus to me since the transport mechanism for >realizing the law(s) is (wisely) left as a matter of interpretation. Ahh, but NTP isn't just a mechanism, it mandates UTC timestamps, and thus it would be counter to Danish law. And nobody can appearantly be bothered to change the shortest, simplest and most incorrect law we have on the books in Denmark: https://www.retsinformation.dk/Forms/R0710.aspx?id=83966 (The first 3 lines is the title of the King at the time :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dot at dotat.at Thu Feb 14 09:07:52 2008 From: dot at dotat.at (Tony Finch) Date: Thu, 14 Feb 2008 14:07:52 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <41894EFF-A356-4887-AB85-EB98B0A1754E@noao.edu> References: <19959.1202935669@critter.freebsd.dk> <41894EFF-A356-4887-AB85-EB98B0A1754E@noao.edu> Message-ID: On Wed, 13 Feb 2008, Rob Seaman wrote: > > The "day" is a key concept in our civilization. The "mean solar day" is > the natural way to implement this. Sundials have nothing to do with the > mean solar day, but rather the apparent solar day. How does the mean solar day relate to ephemeris time? Between the period where time signals were based on observing solar transitions and the period where time signals were based on atomic clocks, official time was ephemeris time. ET is more uniform than the Earth's rotation so a second of ET is not 1/86400 day any more than an SI second is - and of course the final definition of the SI second was chosen to match ET. If we can imagine what things might have been like if essens had a different period, can we imagine how astronomers would have handled the discrepancy between ET and UT1 in the absence of atomic clocks? Tony. -- f.a.n.finch http://dotat.at/ WEST VIKING: NORTHEASTERLY VEERING SOUTHERLY 3 OR 4. ROUGH. FAIR. GOOD. From dot at dotat.at Thu Feb 14 09:38:26 2008 From: dot at dotat.at (Tony Finch) Date: Thu, 14 Feb 2008 14:38:26 +0000 Subject: [LEAPSECS] Trying a different angle In-Reply-To: <24946.1202997848@critter.freebsd.dk> References: <24946.1202997848@critter.freebsd.dk> Message-ID: On Thu, 14 Feb 2008, Poul-Henning Kamp wrote: > > Ahh, but NTP isn't just a mechanism, it mandates UTC timestamps, > and thus it would be counter to Danish law. Does Denmark have a national time broadcast service, like MSF or DCF77? Tony. -- f.a.n.finch http://dotat.at/ DOVER WIGHT: NORTHEAST 4 OR 5, OCCASIONALLY 6 IN WIGHT. SLIGHT OR MODERATE. FOG PATCHES. MODERATE TO VERY POOR. From phk at phk.freebsd.dk Thu Feb 14 09:45:33 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 14:45:33 +0000 Subject: [LEAPSECS] Trying a different angle In-Reply-To: Your message of "Thu, 14 Feb 2008 14:38:26 GMT." Message-ID: <25103.1203000333@critter.freebsd.dk> In message , Tony F inch writes: >On Thu, 14 Feb 2008, Poul-Henning Kamp wrote: >> >> Ahh, but NTP isn't just a mechanism, it mandates UTC timestamps, >> and thus it would be counter to Danish law. > >Does Denmark have a national time broadcast service, like MSF or DCF77? No. I have not even been able to locate a single state owned Cesium frequency standard. The closest we ever got was "Miss Clock" on the analog telephone. The agency responsible for spectrum management have made it clear that they would not bother investigating interference on the frequencies of DCF77 and MSF, "as they are not under our jurisdiction." -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Thu Feb 14 10:57:10 2008 From: seaman at noao.edu (Rob Seaman) Date: Thu, 14 Feb 2008 08:57:10 -0700 Subject: [LEAPSECS] Trying a different angle In-Reply-To: <24620.1202995650@critter.freebsd.dk> References: <24620.1202995650@critter.freebsd.dk> Message-ID: <02D6036C-E378-42B4-8D80-DCF0A6FA4A58@noao.edu> > It's not a matter of brand recognition, it's a matter of national > laws defining civil time in terms of UTC (or one of it's many aliases) > and a timezone offset. Then the obvious thing to do is to separate an unsegmented time system, like TI or GPS, required by naive compute clients, from the UTC/mean solar time required by naive governments. Tying the two even more closely together is going to make a joint solution even harder. It is a matter of brand recognition - what do you think the lobbyists deal in? > it is still not seen as important enough to fix it. And are you convinced that it would be better for us if the lawmakers did take notice of our activities? :-) From phk at phk.freebsd.dk Thu Feb 14 11:13:24 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 16:13:24 +0000 Subject: [LEAPSECS] Trying a different angle In-Reply-To: Your message of "Thu, 14 Feb 2008 08:57:10 MST." <02D6036C-E378-42B4-8D80-DCF0A6FA4A58@noao.edu> Message-ID: <25606.1203005604@critter.freebsd.dk> In message <02D6036C-E378-42B4-8D80-DCF0A6FA4A58 at noao.edu>, Rob Seaman writes: >And are you convinced that it would be better for us if the lawmakers >did take notice of our activities? :-) Well, to be honest, If I have the choice between the kind of cockeyed but scientifically valid things time-scientists have come up with in the last 50 years and politicians not getting around to dispell 1800-ish timemeasurement, I think I'll take the latter, at least it is so ridiculous that everybody uniformly ignore it :-) The real culprit here, and one you have to deal with if you succeed in saving leap-seconds, is POSIX. Unfortunately, pretending that leap-seconds do not happen on computers is just indicative of their genius. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Thu Feb 14 11:59:10 2008 From: seaman at noao.edu (Rob Seaman) Date: Thu, 14 Feb 2008 09:59:10 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <24862.1202997400@critter.freebsd.dk> References: <24862.1202997400@critter.freebsd.dk> Message-ID: <6892466D-A98E-4A14-912D-3FBBA567EF1A@noao.edu> Just trying to get caught up before my team meeting in 5 minutes, so the intervening topics come down to: > Given that I can be persuaded to retain leap seconds, if I see a > sensible proposal, I find it surprising that you consider me on the > enemy side, rather than a potential allied. I'm bemused how replying to your messages leads to an inference that I regard you as the former, not the latter. As you can be persuaded to retain leap seconds, I can be persuaded to dispense with them as long as UTC remains a flavor of universal time, that is, of mean solar time. From seaman at noao.edu Thu Feb 14 12:19:54 2008 From: seaman at noao.edu (Rob Seaman) Date: Thu, 14 Feb 2008 10:19:54 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: References: <19959.1202935669@critter.freebsd.dk> <41894EFF-A356-4887-AB85-EB98B0A1754E@noao.edu> Message-ID: <22D98209-A02E-4D46-A4DE-D7D56B48C086@noao.edu> There are a lot of timescales. Astronomers are as heavy users of even interval time as of Earth orientation time. I guess the answer to your question lies in the explanatory supplement to the astronomical almanac. Recent IAU standards changes have yet to appear in a similarly normative form. Steve Allen may also comment. But the issues focus on the requirements of civil timekeeping, not the various precision timekeeping users like astronomers. I won't repeat my argument about why civil time is mean solar time, but I assert that it is. In addition, we all grasp the various issues regarding even interval timekeeping for computing. That adds up to two types of civil time. UTC does a pretty good job of capturing both flavors of time into a single mechanism. It's ok by me, however, if there is a initiative to split them. It is not ok if we try to pretend that one does not exist and I assert this will become obvious to all in the fullness of time. Rob -- On Feb 14, 2008, at 7:07 AM, Tony Finch wrote: > On Wed, 13 Feb 2008, Rob Seaman wrote: >> >> The "day" is a key concept in our civilization. The "mean solar >> day" is >> the natural way to implement this. Sundials have nothing to do with >> the >> mean solar day, but rather the apparent solar day. > > How does the mean solar day relate to ephemeris time? Between the > period > where time signals were based on observing solar transitions and the > period where time signals were based on atomic clocks, official time > was > ephemeris time. ET is more uniform than the Earth's rotation so a > second > of ET is not 1/86400 day any more than an SI second is - and of > course the > final definition of the SI second was chosen to match ET. > > If we can imagine what things might have been like if essens had a > different period, can we imagine how astronomers would have handled > the > discrepancy between ET and UT1 in the absence of atomic clocks? > > Tony. From sla at ucolick.org Thu Feb 14 16:07:54 2008 From: sla at ucolick.org (Steve Allen) Date: Thu, 14 Feb 2008 13:07:54 -0800 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: References: <19959.1202935669@critter.freebsd.dk> <41894EFF-A356-4887-AB85-EB98B0A1754E@noao.edu> Message-ID: <20080214210754.GA19375@ucolick.org> On Thu 2008-02-14T14:07:52 +0000, Tony Finch hath writ: > How does the mean solar day relate to ephemeris time? Again, the interval when the worst chaos reigned as people tried to figure out how to answer that question is covered in this 1966 document by the geodesist trying to explain it all for NASA. http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19660020453_1966020453.pdf The scholarly record in the refereed journals, the long sequence of publications by the BIH, and references in the works by Guinot point to a treasure trove of material by Stoyko that must be in the BIPM and/or Paris Observatory from the interval of history when this was being grokked. For a shorter version see Seidelmann's writeup in Explanatory Supplement to the Astronomical Almanac, University Science Books, 1992 http://www.amazon.com/Explanatory-Supplement-Astronomical-Almanac-Seidelmann/dp/0935702687/ For another short version see the Metrologia paper by Nelson et al. The leap second: its history and possible future, v38, #6, pp509-529, 2001 I think there are aboutt three copies out there on the web. For another insider's view see the book by Audoin & Guinot The Measurement of Time: Time, Frequency and the Atomic Clock Cambridge, 2001 http://www.amazon.com/Measurement-Time-Claude-Audoin/dp/0521800803/ For the long view see all the annual publications of the BIH and the USNO regarding their work with radio signal time sync. Also the triennial publications of the IAU general assemblies with focus on the output from commission 31, especially the proceedings from the late 1950s through early 1970s. For those with access to material not yet available try the book being written by McCarthy and Seidelmann for publication by Wiley. I suspect it will be very good. If anyone knows of any memoirs of this sort penned by Markowitz then I would not be alone in really wanting to learn about them. The words from the 1964-08-28 meeting of IAU commission 31 have remained true over more than 40 years: La distinction entre epoque et intervalle de temps n'est pas claire pour tous. There is a distinction. POSIX zoneinfo and its equivalents in other precison+civil time systems already have the mechanisms to let the distinction be clear. They can handle both a monotonic interval and a conversion to and from various epochs that corresponds to externally mandated standards. The question is whether or not we want to insist on broad cognition of that distinction, or whether we'll dumb down reality for the sake of simplicity. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From phk at phk.freebsd.dk Thu Feb 14 16:53:37 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 21:53:37 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Thu, 14 Feb 2008 13:07:54 PST." <20080214210754.GA19375@ucolick.org> Message-ID: <27777.1203026017@critter.freebsd.dk> In message <20080214210754.GA19375 at ucolick.org>, Steve Allen writes: >There is a distinction. POSIX zoneinfo and its equivalents in other >precison+civil time systems already have the mechanisms to let the >distinction be clear. They can handle both a monotonic interval and a >conversion to and from various epochs that corresponds to externally >mandated standards. This is not true. This is the point where the POSIX people shot us in the feet by ignoring leap-seconds. The time_t type, contains the number of SI seconds since 1970-01-01 00:00:00 UTC *ignoring all leapseconds*. This means that you can find the preceeding UTC midnight from any time_t value by subtracting its modules of 86400: > date +%s 1203025212 <--- time_t integer > date -r 1203025212 Thu Feb 14 21:40:12 UTC 2008 <--- corresponding UTC time > expr 1203025212 % 86400 78012 <--- Modulus (24*60*60) > expr 1203025212 - 78012 1202947200 <--- time_t of preceeding midnight > date -r 1202947200 Thu Feb 14 00:00:00 UTC 2008 <--- As UTC time If time_t had correctly counted leapseconds, that would have been 23.mumle seconds off (leapseconds + rate and phase adjustments in 1970 and 1971). This deficient definition means that you cannot correctly calculate the number of SI seconds between two time_t's if they span a leap-second, unless you have an external table of leapseconds to reference. And down at a hairsbreadth, you cannot by looking at a time_t value, tell the leap second from the second right before it. (In some cases it's the second after, but that's clearly a bug since the leap second is the last second in the preceeding 24 hour UTC period.) What zoneinfo brings to the table, is the information to convert from a time_t to civil time and vice versa, all over the world thoughtout time. But even the zoneinfo leapsecond table can not solve the basic problem telling the two identical time_t values apart. This is of course analogous to the problem when sommertime ends and people don't qualify the timestamp properly. Because the time_t is in "almost UTC", this problem does not exist for time_t -> human conversions but only for human->time_t conversions. But because time_t is not qualified some way to mark leap seconds, they suffer the problem on both directions. There is far too much code and data out there to even contemplate changing the definition of time_t. It would also be a stupid thing to do from a QA point of view, because it would not be readily appearant if the code was using the old time_t or the new time_t definition. So if leapeconds survive, we somehow have to force a new time typedef and representation through POSIX, and get operating systems to implement it. If we just drop leapseconds, time_t is suddenly correct and all the computer software and data files need no attention. Unfortunately, it also means that we either sanction POSIX stupidity or acknowledge their superior farsightedness, neither of which is particularly satisfying to anybody. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From sla at ucolick.org Thu Feb 14 17:10:22 2008 From: sla at ucolick.org (Steve Allen) Date: Thu, 14 Feb 2008 14:10:22 -0800 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <27777.1203026017@critter.freebsd.dk> References: <20080214210754.GA19375@ucolick.org> <27777.1203026017@critter.freebsd.dk> Message-ID: <20080214221022.GA20007@ucolick.org> On Thu 2008-02-14T21:53:37 +0000, Poul-Henning Kamp hath writ: > But even the zoneinfo leapsecond table can not solve the basic > problem telling the two identical time_t values apart. Which is not henceforth troublesome if time_t becomes TI. > There is far too much code and data out there to even contemplate > changing the definition of time_t. That's what they said about changing the conventional longitudes of every observatory on the planet in order to get agreement on the value of UT starting in 1962. But in 1961 the IAU said "do it", and they did -- even in cases where it caused a time step in the sovereign time scale of a nation, and even where it introduced a new, potentially ambiguous notion of origin of longitude for civil mapping. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From phk at phk.freebsd.dk Thu Feb 14 17:16:59 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Feb 2008 22:16:59 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Thu, 14 Feb 2008 14:10:22 PST." <20080214221022.GA20007@ucolick.org> Message-ID: <27896.1203027419@critter.freebsd.dk> In message <20080214221022.GA20007 at ucolick.org>, Steve Allen writes: >That's what they said about changing the conventional longitudes of >every observatory on the planet in order to get agreement on the value >of UT starting in 1962. But in 1961 the IAU said "do it", and they >did -- even in cases where it caused a time step in the sovereign time >scale of a nation, and even where it introduced a new, potentially >ambiguous notion of origin of longitude for civil mapping. This comparison is so bogus that we ought to frame and hang it. In 1961, the task was on a few handfulls of scientific people, most, if not all, of them phd's, and all of them very much at home in the subject domain. Fiddling with time_t today would involves more than a million persons, very few of which can readily tell you what a leap-second is. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From msokolov at ivan.Harhan.ORG Thu Feb 14 17:26:11 2008 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Thu, 14 Feb 2008 22:26:11 GMT Subject: [LEAPSECS] Regarding the ITU's very immodest proposal Message-ID: <0802142226.AA26758@ivan.Harhan.ORG> Poul-Henning Kamp wrote: > But exactly because I'm totally agnostic on solar time, the obvious > follow up question is: why leap seconds at all ? Well, I actually prefer rubber seconds, but I can live with leap seconds too, I just turn them into rubber seconds myself. I use continuous real-number-expressible rubber time on my adamantly non-POSIX UNIX systems (4.3BSD-Quasijarus). > People live up to 5 hours away from solar time already today, so > it cannot be very important to have the sun in south at noon. I am not one of those people and never will be. In fact I feel strongly enough about natural mean solar time that I refuse to obey DST. In less than a month everyone around me is going to move their clocks one hour forward, I will not. I commit civil disobedience for the greater part of every year by running my personal life on natural time instead of DST. Since I already commit civil disobedience by a whole hour for the greater part of every year, it would only be a little extra difference (another few seconds) when UTC is eviscerated and I have to start generating my own rubber time scale anchored to mean solar time. And yes, it is a religious matter to me. > We would have to maintain earth rotatation angle as a scientic > exercise, along with all the other earth rotation parameters. Good, this information will be very useful to me for generating my civil disobedience time scale. And yes, I will make my rebel time scale available to the rest of the world via an NTP-like protocol on a different port number. I hope Hugo Chavez likes it. > We can leave any necessary adjustments to civil time, if/when night > turns into day, to the national governments who already are far too > keen to fiddle timezones for their own economic welfare. And some of us who do not trust those national governments imposed on us against our will shall take the matters into our own hands. > Downside ? People with thing pointing to extraterrestial objects > are going to be cross, but they'll get over it. People with things pointing to ET objects are not the only ones, spiritual people are the other group. I don't have any thing pointing to any object, but I still care. And no, we (the spiritual group, dunno about the astronomers) will NOT get over it, we shall commit civil disobedience instead. > Nothing of any technical nature has any influence on the proposals > chances of getting ratified in ITU, that's purely a matter of > politics, most of it under the radar at civil servant level, and > once the plenum vote approaches, also at ambasador level if USA > feels badly enough for this. Somehow I doubt that *every* nation will comply with this edict. I can just see Venezuela and the Muslim nations saying "no way in hell" and running on their own mean solar time while USA and other "first world" nations run on the eviscerated UTC. Fun times ahead! Note to self: make friends with Hugo Chavez and convince him to adopt my rubber time scale. Goddess Bless, MS From msokolov at ivan.Harhan.ORG Thu Feb 14 17:45:37 2008 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Thu, 14 Feb 2008 22:45:37 GMT Subject: [LEAPSECS] How good could civil timekeeping be? Message-ID: <0802142245.AA26840@ivan.Harhan.ORG> Poul-Henning Kamp wrote: > This is the point where the POSIX people shot us in the feet by > ignoring leap-seconds. Why care about POSIX at all? Why not use a non-POSIX UNIX system then? > The time_t type, contains the number of SI seconds since 1970-01-01 > 00:00:00 UTC *ignoring all leapseconds*. Dunno about POSIX, but in UNIX-in-4-capitals which predates POSIX, time_t does NOT mean what you say. UNIX as opposed to POSIX time_t measures the angle by which the hands of a wall clock have rotated since since they displayed midnight 1970-01-01 in Greenwich. It is a wall clock rotation angle and has absolutely nothing to do with SI seconds or physical time interval. > And down at a hairsbreadth, you cannot by looking at a time_t value, > tell the leap second from the second right before it. (In some > cases it's the second after, but that's clearly a bug since the > leap second is the last second in the preceeding 24 hour UTC period.) Rubber seconds solve this problem. MS From imp at bsdimp.com Thu Feb 14 17:51:57 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu, 14 Feb 2008 15:51:57 -0700 (MST) Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <0802142245.AA26840@ivan.Harhan.ORG> References: <0802142245.AA26840@ivan.Harhan.ORG> Message-ID: <20080214.155157.669296043.imp@bsdimp.com> In message: <0802142245.AA26840 at ivan.Harhan.ORG> msokolov at ivan.Harhan.ORG (Michael Sokolov) writes: : Poul-Henning Kamp wrote: : : > This is the point where the POSIX people shot us in the feet by : > ignoring leap-seconds. : : Why care about POSIX at all? Why not use a non-POSIX UNIX system then? Lots of code cares about many properties that POSIX has. : > The time_t type, contains the number of SI seconds since 1970-01-01 : > 00:00:00 UTC *ignoring all leapseconds*. : : Dunno about POSIX, but in UNIX-in-4-capitals which predates POSIX, : time_t does NOT mean what you say. UNIX as opposed to POSIX time_t : measures the angle by which the hands of a wall clock have rotated since : since they displayed midnight 1970-01-01 in Greenwich. It is a wall : clock rotation angle and has absolutely nothing to do with SI seconds or : physical time interval. You have just described POSIX time. : > And down at a hairsbreadth, you cannot by looking at a time_t value, : > tell the leap second from the second right before it. (In some : > cases it's the second after, but that's clearly a bug since the : > leap second is the last second in the preceeding 24 hour UTC period.) : : Rubber seconds solve this problem. No they don't. Rubber seconds are even more evil than leap seconds. Warner From shep at alum.mit.edu Thu Feb 14 19:00:09 2008 From: shep at alum.mit.edu (Tim Shepard) Date: Thu, 14 Feb 2008 19:00:09 -0500 Subject: [LEAPSECS] Terminology and Requirements (was Re: How good could civil timekeeping be? ) In-Reply-To: Your message of Thu, 14 Feb 2008 15:51:57 -0700. <20080214.155157.669296043.imp@bsdimp.com> Message-ID: > : > And down at a hairsbreadth, you cannot by looking at a time_t value, > : > tell the leap second from the second right before it. (In some > : > cases it's the second after, but that's clearly a bug since the > : > leap second is the last second in the preceeding 24 hour UTC period.) > : > : Rubber seconds solve this problem. > > No they don't. Rubber seconds are even more evil than leap seconds. I think the problem here is one of terminology. We all just don't agree on precisely what these words mean. When we discover that we have different meanings in mind for words, it might help in discussions like this to somehow find a way to agree on terminology. For example, the term "seconds" means different things in different contexts. When we conflate the two contexts without realizing that there may be conflicting requirements in the two different contexts, our discussion isn't likely to produce fruit. I agree that rubber essens would be evil. (Ignoring for a moment that if you just look a few more decimal places to the right, you discover that there's some residual rubberiness that just will never go away.) But rubber seconds are simply a fact of living on this planet. (Sorry I cannot think of a neutral alternative to the word "second" here. Any suggestions?) It is true that if you make 1 essen close enough in value to 1 second, you can pretend there is no difference for many years. And that's essentially what we do for six months at a time (and often longer) in most contexts. I sometimes wonder how sure we can be that the synchronized ticking of UTC and TAI will be maintained without interruption. Yeah, we can be pretty sure, but there may be cases where it's better to base time on something that we can be sure can be recovered no matter what. Maintaining some residual know-how of how to do celestial navigation in case (heaven forbid) we wake up some morning and discover GPS is no longer available is a Good Thing, in my opinion. And I believe civil time scales should be defined in a way such that in case there is ever any dispute or disruption, there is some neutral and objective way to recover it. (A Nautical Almanac, a small telescope, and a timepiece to be set (or logged), and I can recover it.) If the TAI/UTC synchronized ticking were lost for awhile, what would happen then? We should be careful how we make the master dependency diagram for this this ever-increasingly technological world. Independence brings robustness. Too many dependency edges creates brittle infrastructure. There is no faster way to make my eyes glaze over than to suggest we should work on a Requirements Document. It is much more fun to invent technical solutions. But I believe at this point, we have no hope of getting to an agreement about What Should Be Done without carefully documenting what all the applications are that need to be supported, what their requirements for timekeeping are, and then analyzing how the requirements mesh and conflict. When I run that scenario in my head, I see no escaping that we need more than one time scale, and the existance of more than one time scale will need to be somewhat more exposed. We already live in a world with more than one time scale, except that the fact that more than one time scale exists is often papered over and/or neglected. (And that is when problems start to surface.) Perhaps this could be documented (or refuted) more carefully, while avoiding ambiguous language. -Tim Shepard shep at alum.mit.edu From seaman at noao.edu Thu Feb 14 19:07:10 2008 From: seaman at noao.edu (Rob Seaman) Date: Thu, 14 Feb 2008 17:07:10 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <20080214.155157.669296043.imp@bsdimp.com> References: <0802142245.AA26840@ivan.Harhan.ORG> <20080214.155157.669296043.imp@bsdimp.com> Message-ID: <12A2459C-4B55-471E-A43A-9003E0C29184@noao.edu> > Rubber seconds are even more evil than leap seconds. 'They are Man's,' said the Spirit, looking down upon them. 'And they cling to me, appealing from their fathers. This boy is Ignorance. This girl is Want. Beware them both, and all of their degree, but most of all beware this boy, for on his brow I see that written which is Doom, unless the writing be erased.' Where next shall the Timelords turn their baleful glare? 'Deny it.' cried the Spirit, stretching out its hand towards the city. 'Slander those who tell it ye. Admit it for your factious purposes, and make it worse. And abide the end.' From sla at ucolick.org Thu Feb 14 19:07:19 2008 From: sla at ucolick.org (Steve Allen) Date: Thu, 14 Feb 2008 16:07:19 -0800 Subject: [LEAPSECS] Terminology and Requirements (was Re: How good could civil timekeeping be? ) In-Reply-To: References: <20080214.155157.669296043.imp@bsdimp.com> Message-ID: <20080215000719.GA20953@ucolick.org> On Thu 2008-02-14T19:00:09 -0500, Tim Shepard hath writ: > If the TAI/UTC synchronized ticking were lost for awhile, what would > happen then? Audoin & Guinot (2001) p. 252, sect. 7.3.1 "Reliability" ... Imagine for a moment what would happen if, just as a practical joke, someone found a way to stop all atomic clocks, just for a short time. This would cause such a tremendous disturbance in world affairs that the loss of TAI would be a totally insignificant matter. Furthermore, when it came to setting it up again, the phase of TAI could be retrieved to within a few tenths of a microsecond by observations of rapidly rotating pulsars... -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From ch at murgatroid.com Thu Feb 14 20:50:00 2008 From: ch at murgatroid.com (christopher hoover) Date: Thu, 14 Feb 2008 17:50:00 -0800 Subject: [LEAPSECS] Terminology and Requirements (was Re: How good could civil timekeeping be? ) In-Reply-To: <20080215000719.GA20953@ucolick.org> References: <20080214.155157.669296043.imp@bsdimp.com> <20080215000719.GA20953@ucolick.org> Message-ID: <006601c86f75$136daa30$3a48fe90$@com> Steve Allen wrote: > > On Thu 2008-02-14T19:00:09 -0500, Tim Shepard hath writ: > > If the TAI/UTC synchronized ticking were lost for awhile, what would > > happen then? > > Audoin & Guinot (2001) > p. 252, sect. 7.3.1 "Reliability" > > ... Imagine for a moment what would happen if, just as a > practical joke, someone found a way to stop all atomic clocks, > just for a short time. This would cause such a tremendous > disturbance in world affairs that the loss of TAI would be a > totally insignificant matter. Furthermore, when it came to > setting it up again, the phase of TAI could be retrieved to within > a few tenths of a microsecond by observations of rapidly rotating > pulsars... That would be a fun experiment to try, if everyone would agree to play "blind." -ch From sla at ucolick.org Thu Feb 14 21:55:32 2008 From: sla at ucolick.org (Steve Allen) Date: Thu, 14 Feb 2008 18:55:32 -0800 Subject: [LEAPSECS] Terminology and Requirements (was Re: How good could civil timekeeping be? ) In-Reply-To: <006601c86f75$136daa30$3a48fe90$@com> References: <20080214.155157.669296043.imp@bsdimp.com> <20080215000719.GA20953@ucolick.org> <006601c86f75$136daa30$3a48fe90$@com> Message-ID: <20080215025532.GA25792@ucolick.org> On Thu 2008-02-14T17:50:00 -0800, christopher hoover hath writ: > That would be a fun experiment to try, if everyone would agree to play > "blind." No thanks. I love the contrasting sentiments in "without atomic time the world would come to an end, but the astronomers could still save us". Nevertheless, my impression is that the situation will likely occur if one side decides to stop all the clocks of the other side first. In that case both international agreements and the fact that I've hung tapes on a radio telescope that times pulsars seem moot. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99858 University of California Voice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From phk at phk.freebsd.dk Fri Feb 15 02:58:06 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Feb 2008 07:58:06 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Thu, 14 Feb 2008 22:45:37 GMT." <0802142245.AA26840@ivan.Harhan.ORG> Message-ID: <29780.1203062286@critter.freebsd.dk> In message <0802142245.AA26840 at ivan.Harhan.ORG>, Michael Sokolov writes: >Poul-Henning Kamp wrote: > >> This is the point where the POSIX people shot us in the feet by >> ignoring leap-seconds. > >Why care about POSIX at all? Why not use a non-POSIX UNIX system then? Because I live in the real world. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Fri Feb 15 03:45:05 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Feb 2008 01:45:05 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <29780.1203062286@critter.freebsd.dk> References: <29780.1203062286@critter.freebsd.dk> Message-ID: <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> > Because I live in the real world. POSIX is indeed a facet of the world we've built. I might argue that better system engineering practices might have avoided its limitations :-) but we have to deal with the technology we've inherited. Note, however, that the actual real world is part of the real world, too. I'll restrain myself from waxing too poetic here since it seems to drive some people crazy, but facts like weather, and natural resource limits, and all the ideas in Jared Diamond's books, and solar effects on communications, and lightning strikes, and the difficulties facing oceanic cables, and - yes - the fact that we live on a rotating, orbiting platform do indeed continue to impinge on our civilization. One could argue that these effects are increasingly evident. Throw out all the rest of the system engineering best practices that for some reason also seem to be controversial. Might it not be prudent to actually perform a risk analysis of key technologies such as transportation, communication and pipelines to look for failure modes associated with the sought eradication of mean solar time? I mean - like before actually eradicating it? A dearth of imagination as to how such dependencies could possibly exist is not a logical refutation. Whereas we have several decades of evidence that leap seconds are survivable if proper precautions are taken, such as seeking shelter underground every New Year's Eve, stockpiling canned goods, and keeping candles and Y2K certified matches at the ready :-) Rob Seaman NOAO From phk at phk.freebsd.dk Fri Feb 15 04:43:53 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Feb 2008 09:43:53 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Fri, 15 Feb 2008 01:45:05 MST." <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> Message-ID: <46379.1203068633@critter.freebsd.dk> In message <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33 at noao.edu>, Rob Seaman writes: >A dearth of imagination as to how such dependencies could possibly >exist is not a logical refutation. A bloke named Gettys was pretty instrumental in the development of the X11 windows software, and one of the principles of software development he has put in words is applicable to much more than software development: 3.The only thing worse than generalizing from one example is generalizing from no examples at all. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dot at dotat.at Fri Feb 15 07:59:35 2008 From: dot at dotat.at (Tony Finch) Date: Fri, 15 Feb 2008 12:59:35 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <20080214210754.GA19375@ucolick.org> References: <19959.1202935669@critter.freebsd.dk> <41894EFF-A356-4887-AB85-EB98B0A1754E@noao.edu> <20080214210754.GA19375@ucolick.org> Message-ID: On Thu, 14 Feb 2008, Steve Allen wrote: > > http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19660020453_1966020453.pdf Thanks for this link. I was previously a bit put off by its length but I can probably get it into comfortably readable form without killing too many trees :-) > For a shorter version see Seidelmann's writeup in > Explanatory Supplement to the Astronomical Almanac, > University Science Books, 1992 Not the more recent edition? http://www.amazon.com/gp/product/1891389459/ > For another insider's view see the book by Audoin & Guinot > The Measurement of Time: Time, Frequency and the Atomic Clock I have a copy of this. Also "Splitting the Second: The Story of Atomic Timekeeping" by Tony Jones (IoP publising) is a nice accessible overview. http://www.amazon.co.uk/dp/0750306408/ Tony. -- f.a.n.finch http://dotat.at/ MALIN: SOUTHEAST VEERING SOUTHWEST 3 OR 4. MODERATE OR ROUGH. FAIR. MODERATE OR GOOD. From lang at unb.ca Fri Feb 15 08:17:45 2008 From: lang at unb.ca (Richard B. Langley) Date: Fri, 15 Feb 2008 09:17:45 -0400 (AST) Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: References: <19959.1202935669@critter.freebsd.dk> <41894EFF-A356-4887-AB85-EB98B0A1754E@noao.edu> <20080214210754.GA19375@ucolick.org> Message-ID: On Fri, 15 Feb 2008, Tony Finch wrote: >> For a shorter version see Seidelmann's writeup in >> Explanatory Supplement to the Astronomical Almanac, >> University Science Books, 1992 > >Not the more recent edition? >http://www.amazon.com/gp/product/1891389459/ Is that just a paperback version of the 1992 hardcover edition? Any text differences at all? =============================================================================== Richard B. Langley E-mail: lang at unb.ca Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics Engineering Phone: +1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ =============================================================================== From seaman at noao.edu Fri Feb 15 08:35:46 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Feb 2008 06:35:46 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <46379.1203068633@critter.freebsd.dk> References: <46379.1203068633@critter.freebsd.dk> Message-ID: <4F2EE2CE-6061-4786-AD92-7176F8B2E9A0@noao.edu> > 3.The only thing worse than generalizing from one example > is generalizing from no examples at all. Right. Which is why you invest time and money in seeking out (or eliminating) possible examples. I have access to examples of astronomical software (and also have experience from having performed our Y2K inventory). As we've discussed far too many times, changing UTC will definitely require changing astronomical software extensively. Will there be similar extensive changes required to most communities' software or system assets? Unlikely. Will subtle changes (the sort that show up dramatically when least expected) be required? Unknown until an inventory is performed. I don't have access to software systems for air traffic control, or airframe platforms themselves, or for railroads (the ancient poster child for synchronizing time), or pipelines (with similar timezone spanning networks), or communications (the poster child for ooh! those 'orrible leap seconds), or... Has anybody attempted an inventory for any of these classes of systems? Or did the apparent non-event of Y2K wrongly convince managers and technologists that nothing could possibly go wrong? Do the folks agitating to change UTC even know comp.risks exists? What about risks emergent from diverging interpretation of the new standard? Will all carriers and vendors be on the same page regarding UTC as static offset from TAI and the current meaning of UTC as an approximation of mean solar time? A few of us have also been following the NTP saga. NTP should be blind to a cessation of leap seconds. Should be. Has anyone tested a sizable subnetwork of diverse servers? For Y2K I set a server's clock forward by eleven years for several years before the gratifyingly undramatic event. What tests at all have been done to show that modifying the UTC standard behind nearly every clock on the planet (many predating NTP still in operation in industries like - say - nuclear energy) - that making such a modification won't break something, anything. Please don't tell me again how good system engineering practices aren't needed here. Please, with this change looming, please tell me someone, anyone, has grepped for the string "DUT1" in the source for any one of the systems mentioned above. Rob From dot at dotat.at Fri Feb 15 08:58:33 2008 From: dot at dotat.at (Tony Finch) Date: Fri, 15 Feb 2008 13:58:33 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: References: <19959.1202935669@critter.freebsd.dk> <41894EFF-A356-4887-AB85-EB98B0A1754E@noao.edu> <20080214210754.GA19375@ucolick.org> Message-ID: On Fri, 15 Feb 2008, Richard B. Langley wrote: > On Fri, 15 Feb 2008, Tony Finch wrote: > > >> For a shorter version see Seidelmann's writeup in > >> Explanatory Supplement to the Astronomical Almanac, > >> University Science Books, 1992 > > > >Not the more recent edition? > >http://www.amazon.com/gp/product/1891389459/ > > Is that just a paperback version of the 1992 hardcover edition? Any text > differences at all? A friend tells me there have been some revisions: http://fanf.livejournal.com/80822.html?thread=341174#t341174 Tony. -- f.a.n.finch http://dotat.at/ SOUTH UTSIRE: SOUTHERLY 3 OR 4 VEERING WESTERLY 5. MODERATE OR ROUGH. FAIR. GOOD. From phk at phk.freebsd.dk Fri Feb 15 09:01:50 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Feb 2008 14:01:50 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Fri, 15 Feb 2008 06:35:46 MST." <4F2EE2CE-6061-4786-AD92-7176F8B2E9A0@noao.edu> Message-ID: <91404.1203084110@critter.freebsd.dk> In message <4F2EE2CE-6061-4786-AD92-7176F8B2E9A0 at noao.edu>, Rob Seaman writes: >> 3.The only thing worse than generalizing from one example >> is generalizing from no examples at all. > >Right. Which is why you invest time and money in seeking out (or >eliminating) possible examples. I have access to examples of >astronomical software (and also have experience from having performed >our Y2K inventory). As we've discussed far too many times, changing >UTC will definitely require changing astronomical software extensively. There has never been any dispute that astronomy software would need adaptation. It follows from the mechanical physics of the situation. I think I can also safely say, that astronomy software is less than one PPM of all software on the planet, no matter what metric. It is all the non-astronomy software we disagree about. So far I have yet to see one single example of non-astronomy software that needs changed to handle loss of leap-seconds. To my knowledge you have not found any either, or I pressume I would never have heard the end of it :-) Given how much software we have seen between the two of us, that brings the probability of finding any such software well below 1%, quite likely to virtual zero, by which I mean that it will not be found by anybody until it misbehaves. In the other corner, I can point to any and all software that includes as candidate software that needs to be audited for correct leap second handling. Purely from a cost perspective, any reasonable economist will at this point lean heavily towards throwing leap-seconds out. To move the statistics in your favour, heavy-duty evidence will be required. The first thing you have to do, is turn the "virtually zero" into "non-zero" by finding at least one piece of software outside the realm of astronomy, which would be adversely affected by the discontinuation of leap-seconds. If you tasked me with that, I would have no idea where to even look. Absent that pivot for the class, you are generalizing from no example. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From cowan at ccil.org Fri Feb 15 09:48:37 2008 From: cowan at ccil.org (John Cowan) Date: Fri, 15 Feb 2008 09:48:37 -0500 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> References: <29780.1203062286@critter.freebsd.dk> <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> Message-ID: <20080215144837.GF23216@mercury.ccil.org> Rob Seaman scripsit: > POSIX is indeed a facet of the world we've built. I might argue that > better system engineering practices might have avoided its limitations > :-) but we have to deal with the technology we've inherited. Richard P. Gabriel's famous "The Rise of 'Worse Is Better'" essay (online at http://www.jwz.org/doc/worse-is-better.html among other places) may shed some light on just why Posix has become so popular. For that matter, it may shed some light on the whole debate: leap-second guys are from Cambridge, TI guys are from New Jersey. I recommend those of you who haven't read it yet (who are more likely to be from Cambridge and not know it) to do so. Ignore the parochial Lisp-isms. -- Si hoc legere scis, nimium eruditionis habes. From dwmalone at maths.tcd.ie Fri Feb 15 09:54:36 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Fri, 15 Feb 2008 14:54:36 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Fri, 15 Feb 2008 13:58:33 GMT." Message-ID: <200802151454.aa00233@walton.maths.tcd.ie> > > Is that just a paperback version of the 1992 hardcover edition? Any text > > differences at all? > A friend tells me there have been some revisions: > http://fanf.livejournal.com/80822.html?thread=341174#t341174 Someone at the Nautical Almanac Office office told me (in response to a question about ERA and the defintion of mean sun): The Astronomical Almanac 2006 contains these definition and equations. However, I would suggest you wait until the 2007 edition is available (any day now). You should also note that at the IAU in the summer, there will be proposals to adopt a better precession model, ie one that is dynamically consistent and not just an update to Lieskie. This will probably make some end figure changes in the equations! I thought that they were suggesting that there was to be an update to the explainatory suplement in 2006 to explain the ERA stuff, but now I reread it, it seems likely the information is probably in the Almanac, not the suplement. I haven't had a chance to look at the 2006 almanac or suplement to confirm this yet. (I did get to look at some of the almanacs from around 1792 recently, which have some interesting tibits.) David. From seaman at noao.edu Fri Feb 15 11:16:31 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Feb 2008 09:16:31 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <20080215144837.GF23216@mercury.ccil.org> References: <29780.1203062286@critter.freebsd.dk> <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> <20080215144837.GF23216@mercury.ccil.org> Message-ID: <6859FEC7-A6AB-40DD-8CCC-92E04C3F8672@noao.edu> Thanks for the pointer. Sounds like an interesting read, I'll look it up. I suspect I already grasp the gist of the Cambridge versus New Jersey characterization, but note that there is a lot of cross- fertilization and most people have responsibilities in both camps. After all, Princeton is in New Jersey and Watson and Crick reverse engineered DNA (three billion years of design by the ultimate committee) over bitters at the Eagle in Cambridge. Other examples are Zen and the Art of Motorcyle Maintenance, Muir's classic Volkswagen manual - or Burning Man, for that matter. -- On Feb 15, 2008, at 7:48 AM, John Cowan wrote: > Rob Seaman scripsit: > >> POSIX is indeed a facet of the world we've built. I might argue that >> better system engineering practices might have avoided its >> limitations >> :-) but we have to deal with the technology we've inherited. > > Richard P. Gabriel's famous "The Rise of 'Worse Is Better'" essay > (online at http://www.jwz.org/doc/worse-is-better.html among other > places) may shed some light on just why Posix has become so popular. > For that matter, it may shed some light on the whole debate: leap- > second > guys are from Cambridge, TI guys are from New Jersey. > > I recommend those of you who haven't read it yet (who are more likely > to be from Cambridge and not know it) to do so. Ignore the parochial > Lisp-isms. > > -- > Si hoc legere scis, nimium eruditionis habes. > _______________________________________________ > LEAPSECS mailing list > LEAPSECS at leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs From scbarberi at verizon.net Fri Feb 15 11:22:17 2008 From: scbarberi at verizon.net (Barberi) Date: Fri, 15 Feb 2008 11:22:17 -0500 Subject: [LEAPSECS] New Explanatory Supplement & Almanac References: <200802151454.aa00233@walton.maths.tcd.ie> Message-ID: <009301c86fee$f01ad8d0$6400a8c0@DCR6JV31> "David Malone" wrote: > The Astronomical Almanac 2006 contains these definition and > equations. However, I would suggest you wait until the > 2007 edition is available (any day now). You should also > note that at the IAU in the summer, there will be proposals > to adopt a better precession model, ie one that is dynamically > consistent and not just an update to Lieskie. This will > probably make some end figure changes in the equations! > > I thought that they were suggesting that there was to be an update > to the explainatory suplement in 2006 to explain the ERA stuff, but > now I reread it, it seems likely the information is probably in the > Almanac, not the suplement. I haven't had a chance to look at the > 2006 almanac or suplement to confirm this yet. Jim Williams at the USNO has indicated to me that the next edition of the Explanatory Supplement is "moving forward slowly if at all." (He is not the editor, but he and Myles Standish did write one of the chapters.) The 2006 Astro.Almanac has implemented the IAU resolutions up to and including 2003. It indicates that the 2009 edition will implement the P03 precession / ecliptic, and the re-definition of TDB. I don't have a copy of the 2009 edition yet, but it is available now: http://bookstore.gpo.gov/actions/GetPublication.do?stocknumber=008-054-00214-5 See also U.S. Naval Observatory Circular No. 179: http://aa.usno.navy.mil/publications/docs/Circular_179.php Stephen Barberi From clive at demon.net Fri Feb 15 11:32:07 2008 From: clive at demon.net (Clive D.W. Feather) Date: Fri, 15 Feb 2008 16:32:07 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <6859FEC7-A6AB-40DD-8CCC-92E04C3F8672@noao.edu> References: <29780.1203062286@critter.freebsd.dk> <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> <20080215144837.GF23216@mercury.ccil.org> <6859FEC7-A6AB-40DD-8CCC-92E04C3F8672@noao.edu> Message-ID: <20080215163207.GA60338@finch-staff-1.thus.net> Rob Seaman said: > After all, Princeton is in New Jersey and Watson and Crick reverse > engineered DNA (three billion years of design by the ultimate > committee) over bitters at the Eagle in Cambridge. A much over-rated pub, in my opinion. There are better places on King Street. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From seaman at noao.edu Fri Feb 15 11:46:40 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Feb 2008 09:46:40 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <20080215163207.GA60338@finch-staff-1.thus.net> References: <29780.1203062286@critter.freebsd.dk> <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> <20080215144837.GF23216@mercury.ccil.org> <6859FEC7-A6AB-40DD-8CCC-92E04C3F8672@noao.edu> <20080215163207.GA60338@finch-staff-1.thus.net> Message-ID: <48EE1AEE-CA7A-4D50-87DC-39C29EC3D83B@noao.edu> > A much over-rated pub, in my opinion. There are better places on > King Street. Our group (transient response astronomy) had some excellent sessions at the Pickerel last October since we were hiking in from the IoA. On the other hand, the best bars (and pubs) aren't rated at all :-) From seaman at noao.edu Fri Feb 15 12:01:25 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Feb 2008 10:01:25 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: References: <91404.1203084110@critter.freebsd.dk> Message-ID: <841D8957-BBA3-4D7E-B051-F61DAF50B89F@noao.edu> Um - somebody else want to weigh in here on the scientific method? Absence of evidence is not evidence of absence. > So far I have yet to see one single example of non-astronomy software > that needs changed to handle loss of leap-seconds. And you have access to ATC and nuclear control systems? Has anyone at Boeing or GE even been informed of the looming doom of mean solar time? > Given how much software we have seen between the two of us, that > brings the probability of finding any such software well below 1%. Please read Feynman's description of the Challenger investigation. Your statistics are bogus. > In the other corner, I can point to any and all software that > includes as candidate software that needs to be audited > for correct leap second handling. Ok. So that makes two classes of software for the inventory. What classes of software shall we omit? > Purely from a cost perspective, any reasonable economist will at > this point lean heavily towards throwing leap-seconds out. "Reasonable economist"? Thanks for the chuckle. Ask a risk management expert. Here's a scenario. An accident occurs. Lawyers for the plaintiffs or for any of the injured parties (passengers or whoever) find out that no notification was sent following a change to a timekeeping standard. Or perhaps a detailed memo was sent - but the defendant never performed a risk management assessment. Let's imagine the accident had nothing to do with the timekeeping standard. How would this be proved? And who would the lawyers go after? > The first thing you have to do, is turn the "virtually zero" > into "non-zero" by finding at least one piece of software outside > the realm of astronomy, which would be adversely affected by the > discontinuation of leap-seconds. I am (obviously) not the one pushing the initiative for change. The responsibility for making a case falls on the party pressing an issue. A coherent risk analysis is precisely the way to make their case and mitigate future liability. Rob Seaman NOAO From cowan at ccil.org Fri Feb 15 12:12:02 2008 From: cowan at ccil.org (John Cowan) Date: Fri, 15 Feb 2008 12:12:02 -0500 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <6859FEC7-A6AB-40DD-8CCC-92E04C3F8672@noao.edu> References: <29780.1203062286@critter.freebsd.dk> <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> <20080215144837.GF23216@mercury.ccil.org> <6859FEC7-A6AB-40DD-8CCC-92E04C3F8672@noao.edu> Message-ID: <20080215171202.GI23216@mercury.ccil.org> Rob Seaman scripsit: > Thanks for the pointer. Sounds like an interesting read, I'll look > it up. It's pretty short -- it won't take longer than reading (not to mention writing) one of these emails. > After all, Princeton is in New Jersey True, but those of us who are actually from New Jersey (as in, born and raised in) don't like to admit it. My wife (a lady from North Carolina, though not the one in the limerick) never tires of twitting me for saying "Toozdee" rather than "Tyues-day" (though I draw the line at "hoor" and "beauty-full"). > and Watson and Crick reverse engineered DNA (three billion years > of design by the ultimate committee) over bitters at the Eagle in > Cambridge. The relevant Cambridge here is the one containing MIT. > Other examples are Zen and the Art of Motorcyle Maintenance, Muir's > classic Volkswagen manual - or Burning Man, for that matter. I don't think ZAMM quite fits here. This isn't classic vs. romantic beauty, but two schools of thought on what classic beauty actually is. I'm not familiar enough with the other two to comment usefully, except that Burning Man sounds like far too dangerous a place for me -- too many unfamiliar deaths lurking just around the corner. -- John Cowan cowan at ccil.org http://ccil.org/~cowan [R]eversing the apostolic precept to be all things to all men, I usually [before Darwin] defended the tenability of the received doctrines, when I had to do with the [evolution]ists; and stood up for the possibility of [evolution] among the orthodox -- thereby, no doubt, increasing an already current, but quite undeserved, reputation for needless combativeness. --T. H. Huxley From seaman at noao.edu Fri Feb 15 13:20:17 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Feb 2008 11:20:17 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <20080215171202.GI23216@mercury.ccil.org> References: <29780.1203062286@critter.freebsd.dk> <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> <20080215144837.GF23216@mercury.ccil.org> <6859FEC7-A6AB-40DD-8CCC-92E04C3F8672@noao.edu> <20080215171202.GI23216@mercury.ccil.org> Message-ID: <080195C9-02E3-4D25-96E4-09B63FDBF065@noao.edu> > It's pretty short -- it won't take longer than reading (not to mention > writing) one of these emails. Interesting historical take. A lot has happened in software design since the referenced technologies. I don't reject the essence of the story, however. > The relevant Cambridge here is the one containing MIT. Ah, yes - which leads us right to the MIT seal. See: http://web.mit.edu/graphicidentity/symbols/seal.html, but also http://www.freewebs.com/origamipatterns/origami-mit-logo-video.jpg, for instance. I was interpreting Cambridge vs NJ more along the lines of mens et manus. Maybe NJ is manus et mens? > I don't think ZAMM quite fits here. This isn't classic vs. romantic > beauty, but two schools of thought on what classic beauty actually is. Indeed. The "right" answer is alluded to in the essay. What survives the evolutionary process is by definition well designed. A risk analysis is a way to grease the skids of evolution whether systems are designed one way or the other (mind first or hand first) > I'm not familiar enough with the other two to comment usefully, except > that Burning Man sounds like far too dangerous a place for me -- too > many unfamiliar deaths lurking just around the corner. I recommend Stewart Brand's "How Building's Learn" for a discussion of two similar design trends in architecture. In general, software architecture philosophy is rather too self-referential and could do with seeking design paradigms from outside the community. In particular, timekeeping is more than just a question of software. I think we all share a common interest in keeping death unfamiliar. Rob Seaman NOAO From cowan at ccil.org Fri Feb 15 13:49:08 2008 From: cowan at ccil.org (John Cowan) Date: Fri, 15 Feb 2008 13:49:08 -0500 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <080195C9-02E3-4D25-96E4-09B63FDBF065@noao.edu> References: <29780.1203062286@critter.freebsd.dk> <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> <20080215144837.GF23216@mercury.ccil.org> <6859FEC7-A6AB-40DD-8CCC-92E04C3F8672@noao.edu> <20080215171202.GI23216@mercury.ccil.org> <080195C9-02E3-4D25-96E4-09B63FDBF065@noao.edu> Message-ID: <20080215184908.GJ23216@mercury.ccil.org> Rob Seaman scripsit: > I was interpreting Cambridge vs NJ more along the lines of mens et > manus. Maybe NJ is manus et mens? Hacking has been defined as debugging an empty program, so perhaps so. > Indeed. The "right" answer is alluded to in the essay. What survives > the evolutionary process is by definition well designed. I wouldn't say that. "What a book a Devil's Chaplain might write on the clumsy, wasteful, blunderingly low and horridly cruel works of nature." > I recommend Stewart Brand's "How Buildings Learn" for a discussion of > two similar design trends in architecture. In general, software > architecture philosophy is rather too self-referential and could do > with seeking design paradigms from outside the community. Say what? Does the name "Christopher Alexander" mean nothing to you? (You might claim that software designers misread Alexander, but then I point you next to Harold Bloom on strong misreading.) Or is this mere sarcasm? > I think we all share a common interest in keeping death unfamiliar. Yes and no. When you live with an insidious and sneaky chronic disease, you get used to evaluating actions from the point of view of death. -- Dream projects long deferred John Cowan usually bite the wax tadpole. http://www.ccil.org/~cowan --James Lileks From seaman at noao.edu Fri Feb 15 14:23:24 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Feb 2008 12:23:24 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <20080215184908.GJ23216@mercury.ccil.org> References: <29780.1203062286@critter.freebsd.dk> <0C6B2723-C3EE-47FF-AE01-B863DDC6AF33@noao.edu> <20080215144837.GF23216@mercury.ccil.org> <6859FEC7-A6AB-40DD-8CCC-92E04C3F8672@noao.edu> <20080215171202.GI23216@mercury.ccil.org> <080195C9-02E3-4D25-96E4-09B63FDBF065@noao.edu> <20080215184908.GJ23216@mercury.ccil.org> Message-ID: >> I recommend Stewart Brand's "How Buildings Learn" for a discussion of >> two similar design trends in architecture. In general, software >> architecture philosophy is rather too self-referential and could do >> with seeking design paradigms from outside the community. > > Say what? Does the name "Christopher Alexander" mean nothing to you? And I could toss Brenda Laurel and the proscenium arch back at you (well, not literally, but see also http://www.literateprogramming.com). > (You might claim that software designers misread Alexander, but then > I point you next to Harold Bloom on strong misreading.) Or Richard Powers' Galatea 2.2. "Self-referential" may have been the wrong choice of words, but software philosophy tends to be rather self-involved and snarky. There's a lot of world out there that doesn't run on software. > Or is this mere sarcasm? Nothing "mere" about sarcasm, but no, I wasn't attempting to be especially ironic. It's a gift - and a curse. One could do worse than to aim for "simple design, intense content": http://www.sciam.com/article.cfm?id=the-feynman-tufte-princip Rob Seaman NOAO From phk at phk.freebsd.dk Fri Feb 15 18:42:39 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Feb 2008 23:42:39 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Fri, 15 Feb 2008 10:01:25 MST." <841D8957-BBA3-4D7E-B051-F61DAF50B89F@noao.edu> Message-ID: <93755.1203118959@critter.freebsd.dk> In message <841D8957-BBA3-4D7E-B051-F61DAF50B89F at noao.edu>, Rob Seaman writes: >> So far I have yet to see one single example of non-astronomy software >> that needs changed to handle loss of leap-seconds. > >And you have access to ATC and nuclear control systems? Has anyone at >Boeing or GE even been informed of the looming doom of mean solar time? You are deliberately trying very hard to misunderstand what I am telling you. Neither the ATC nor the nuclear control systems care about where the sun or the stars is in the sky. They care about a civil timescale, but it does not have to be connected in any way to any extraterrestial objects. The correct choice of timescale would rightly be TAI, but they were told, by BIPM and others, that TAI was reserved for scientfic use and that it was inappropriate for their needs. >> Given how much software we have seen between the two of us, that >> brings the probability of finding any such software well below 1%. > >Please read Feynman's description of the Challenger investigation. >Your statistics are bogus. No, my statiscs are not bogus. You're just trying to evade the argument by trumping me with an authority who talks about an entirely different subject of statistics. The fact that I have not seen any such software over the course of a quarter of a century is pretty damn well indicative that such software is very rare. The fact that you cannot point at one such piece of software is a guarantee that you don't know of any either. That makes two of us, which reduces the probability of such software existing even further. >> The first thing you have to do, is turn the "virtually zero" >> into "non-zero" by finding at least one piece of software outside >> the realm of astronomy, which would be adversely affected by the >> discontinuation of leap-seconds. > >I am (obviously) not the one pushing the initiative for change. No, but you are obviously they guy who badly needs a killer-argument to stop the change from happening. You dont seriously expect your adversary to deliver you the munitions you need to demolish his position ? You need to show that there is a real chance of a risk, before they are going to consent to carry out a full-blown risk study. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Sat Feb 16 00:11:52 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Feb 2008 22:11:52 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <93755.1203118959@critter.freebsd.dk> References: <93755.1203118959@critter.freebsd.dk> Message-ID: > Neither the ATC nor the nuclear control systems care about where the > sun or the stars is in the sky. They may not care for the same reasons that astronomers care, but let's list a few of the many ways they might care: 1a) Systems may need a table of leap seconds (after all, that's what all the kvetching has been about). Will this be required indefinitely? Maintenance procedures and such? 1b) Or systems might benefit from removing such obsolete dependencies after the UTCng change. Clearly an inventory will be needed to find same. 1c) Say that after UTCng is adopted, it is realized that a mistake was made and the original UTC rules are restored. An inventory distinguishing between class 1a and class 1b systems will be needed. (One might assert that implementing any kind of policy that is designed to be irreversible is unwise.) 2) Systems may be layered on libraries that require DUT1 or other artifacts of the current UTC. 3) Interoperating systems from different countries may rely on civil time as mean solar time (as with Denmark) or alternately as a flavor of unsegmented atomic time. The interpretations may clash. 4) What are the procedures for setting the clocks? Will these change? 5) Many industries predate UTC. Internal interfaces may realize mean solar time, rather than UTC. 6) Airplanes navigate the skies. Software systems to do this surely both predate and postdate GPS. The internal models to realize this likely diverge in their interpretation of UTC. 7) Power plants realize loads that vary diurnally. An insolation model may be required (or a tide model for shipping, etc). 8) Navigational systems need to know the longitude, as may other systems. As with astrometry software, a GIS application will need to convert coordinates back and forth with timelike quantities mimicking spatial transforms. 9) UTC - TAI = DUTC (or delta T or invert the sign) - which is to say that the essence of UTC is to combine atomic time and mean solar time into one tidy package. Which is to say that software may certainly convert one to the other or the inverse (whether or not we think it should have to). 10) It was said that: "any and all software that includes [is] candidate software that needs to be audited for correct leap second handling". A system that needs auditing for some quasi- periodic effect (even if an annoyance) will need auditing when such time tested resets cease. I assert an inventory similar to Y2K is required. For mission or safety critical systems a risk assessment should be performed. One might start with a couple of simple string searches: find . -exec grep -l UTC {} \; find . -exec grep -l DUT1 {} \; (In practice, the list of search terms will be more extensive, as those who performed Y2K inventories will confirm.) "UTC" (and similar) string matching should reveal most modules that (may) care about timekeeping. "DUT1" matching will reveal routines that may suffer a Y2K-like failure when DUT1 exceeds 0.9s. Hits for UTC that are not hits for DUT1 may represent modules that will have to become DUT1 aware. It may well be that code relying on the current civil time standard being mean solar time (as it is and has recently been in many locales) would be better layered on an unsegmented timebase like TAI, TI, GPS or UTCng (even in astronomy). Making that happen would require recoding. Alternately, perhaps mean solar time might have been what was intended (as with astronomy) or it may simply be deemed easier to remain with the old standard. In that case, recoding to support DUT1 > 0.9s may be required. Finally (for this message), a feature of the ITU proposal is to cease transmission of DUT1 signals. One can read between the lines (but really shouldn't have to - that's part of my sermon on planning), and presume that some other system will be commissioned to transmit DUT1. However, any DUT1 aware code will have to be relayered on the new system. Rob Seaman NOAO From phk at phk.freebsd.dk Sat Feb 16 04:07:21 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 16 Feb 2008 09:07:21 +0000 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: Your message of "Fri, 15 Feb 2008 22:11:52 MST." Message-ID: <96211.1203152841@critter.freebsd.dk> In message , Rob Seaman writes: >I assert an inventory similar to Y2K is required. Yes, you have repeatedly made that assertion. Now, move away from the matter of UTCng and all that technical stuff, move up a meta-level and look at the decision making process for this: Convincing people that you are right about the need for an extensive and expensive inventory, will require you to parade a poster boy example of some troubled code the inventory would uncover. Y2K was immediately obvious to any accountant and could be exemplified by three lines of code and two two-line datasets which everybody with a pocket calculator could understand. Leap seconds suffer from no such immediate obviousness, therefore you face a much higher threshold for activation of due dilligence. When you have to explain what leapseconds are for because nobody know anything about them, before you make the case that removing them might invite trouble, you face an uphill battle, because the canonical thought process with the audience in that scenario is: "If I've never noticed them before and I have lived through 23 of them, they can't be very important. They sound like some sort of scout-badge for astronomers which is a lot of trouble for everybody else. Good Riddance I say." To avoid that, you basically need to find a piece of software that will have trouble under UTCng, preferably trouble with significant unwanted side-effects. Then you can instead start your explanation by saying, "If leapseconds are summarily terminated, this is an example of the mayhem we might face...", then you make it sounds like leap seconds are actually of some importance, and people will pay some more attention. Loss of life is the jack-pot for you, but loss of millions will probably do, due to Sarbanes-Oxley regulations. And until you can and do parade such a piece of software, nobody is going to take your claim seriously, and the more and longer you talk, lacking the crucial exhibit A at your side, the more people will assume you are the local village idiot. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Sat Feb 16 18:19:27 2008 From: seaman at noao.edu (Rob Seaman) Date: Sat, 16 Feb 2008 16:19:27 -0700 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: <96211.1203152841@critter.freebsd.dk> References: <96211.1203152841@critter.freebsd.dk> Message-ID: <6E520067-1E98-4ED3-81B2-9BBDA0BF2031@noao.edu> After eight years, this is the message to get me called a village idiot? Bizarre. From paul_j at ste-marie.org Sun Feb 17 02:45:26 2008 From: paul_j at ste-marie.org (Paul J. Ste. Marie) Date: Sat, 16 Feb 2008 23:45:26 -0800 Subject: [LEAPSECS] How good could civil timekeeping be? In-Reply-To: References: <93755.1203118959@critter.freebsd.dk> Message-ID: <47B7E616.7080304@ste-marie.org> On 2/15/2008 9:11 PM, Rob Seaman allegedly wrote: > 1a) Systems may need a table of leap seconds (after all, that's what > all the kvetching has been about). Will this be required > indefinitely? Maintenance procedures and such? IBM mainframes have done this for at least 10-20 years. Their TOD clocks are based on the original Unix definition, not the POSIX nonsense. > 6) Airplanes navigate the skies. Software systems to do this surely > both predate and postdate GPS. The internal models to realize this > likely diverge in their interpretation of UTC. The ATC system ran (runs? did the FAA ever get their act together?) on IBM mainframes. See above. Navigation systems are more varying--the one I've seen details of used three independent implementations on disparate hardware platforms and a voting mechanism to resolve differences. -- --Paul From magnus at rubidium.dyndns.org Sun Feb 17 03:08:15 2008 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sun, 17 Feb 2008 09:08:15 +0100 (CET) Subject: [LEAPSECS] Trying a different angle In-Reply-To: <24946.1202997848@critter.freebsd.dk> References: <24946.1202997848@critter.freebsd.dk> Message-ID: <20080217.090815.152643227461343209.cfmd@bredband.net> From: "Poul-Henning Kamp" Subject: Re: [LEAPSECS] Trying a different angle Date: Thu, 14 Feb 2008 14:04:08 +0000 Message-ID: <24946.1202997848 at critter.freebsd.dk> > In message , Rob Seaman writes: > >> civil danish time was fixes as "the mean solar time at 15 east long." > > >The interpretation of your civil servant that NTP > >is disallowed sounds bogus to me since the transport mechanism for > >realizing the law(s) is (wisely) left as a matter of interpretation. > > Ahh, but NTP isn't just a mechanism, it mandates UTC timestamps, > and thus it would be counter to Danish law. > > And nobody can appearantly be bothered to change the shortest, > simplest and most incorrect law we have on the books in Denmark: > > https://www.retsinformation.dk/Forms/R0710.aspx?id=83966 > > (The first 3 lines is the title of the King at the time :-) Actually, only the first 1.5 lines or so... It is a very simple law, clearly stateing that throughout all of Denmark shall the time be the mean solar time at 15 degree longitude east of Greenwich. This translates to UT1+1h in modern times. This law is now 114 years old. But it seems that the Danish parlament still has very high respect for Christian the ninth, in Gods grace King of Denmark, Venders and Goters, Count of Slesvig, Holstein, Stormarn, Ditmarsken, Lauenborg and Oldenborg. But I am sure the Queen of Denmark (current ruling royalty) could be convinced it is not a great offence to change the law now. An alternative is naturally to use NTP servers providing UT1 time, so that it can be used for legal timing. However, the international committments that Denmark has comitted to, will eventually force Denmark to acknowledge UTC rather than UT1 as the basis for their timekeeping. The current situation is kind of stable, as long as nobody require precission below 1 second. The stop of inserting leap seconds into UTC will cause the UTC-UT1 difference to go beyond one second and all of a sudden a lot of uses will very obviously break the law rater than being a implementational curiosity as it is today. Cheers, Magnus From dot at dotat.at Mon Feb 18 12:10:31 2008 From: dot at dotat.at (Tony Finch) Date: Mon, 18 Feb 2008 17:10:31 +0000 Subject: [LEAPSECS] Trying a different angle In-Reply-To: <20080217.090815.152643227461343209.cfmd@bredband.net> References: <24946.1202997848@critter.freebsd.dk> <20080217.090815.152643227461343209.cfmd@bredband.net> Message-ID: On Sun, 17 Feb 2008, Magnus Danielson wrote: > > It is a very simple law, clearly stateing that throughout all of Denmark shall > the time be the mean solar time at 15 degree longitude east of Greenwich. Including the Faeroes and Greenland? Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE FAEROES: WEST BACKING SOUTH 5 OR 6, DECREASING 4 FOR A TIME. MODERATE OR ROUGH. RAIN AT TIMES. MODERATE OR GOOD, OCCASIONALLY POOR. From paul_j at ste-marie.org Mon Feb 18 13:18:00 2008 From: paul_j at ste-marie.org (Paul J. Ste. Marie) Date: Mon, 18 Feb 2008 10:18:00 -0800 Subject: [LEAPSECS] Trying a different angle In-Reply-To: References: <24946.1202997848@critter.freebsd.dk> <20080217.090815.152643227461343209.cfmd@bredband.net> Message-ID: <47B9CBD8.9040107@ste-marie.org> Tony Finch wrote: > Including the Faeroes and Greenland? Do it really matter /what/ timezone you use in Greenland? From seaman at noao.edu Mon Feb 18 13:40:07 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 18 Feb 2008 11:40:07 -0700 Subject: [LEAPSECS] Trying a different angle In-Reply-To: <47B9CBD8.9040107@ste-marie.org> References: <24946.1202997848@critter.freebsd.dk> <20080217.090815.152643227461343209.cfmd@bredband.net> <47B9CBD8.9040107@ste-marie.org> Message-ID: <5DCBEF46-FBEC-4288-9F08-9A40C0A54FFF@noao.edu> > Do it really matter /what/ timezone you use in Greenland? According to the CIA factbook, it matters enough that the long but narrow Greenland is divided into 4 timezones, with the capital UTC - 3. The 56,000 residents enjoy the many benefits of daylight saving :-) Greenland has a home-rule government. It withdrew from the EU due to a dispute over fishing quotas. As described by Jared Diamond's "Collapse", the economy of the original colony was agrarian. The settlers did not fish, as remarkable as that seems. To the extent that timekeeping was necessary, that timekeeping would have referenced the local sun, whether mean or apparent. From seaman at noao.edu Mon Feb 18 15:43:11 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 18 Feb 2008 13:43:11 -0700 Subject: [LEAPSECS] Happy Birthday Pluto! In-Reply-To: <5AEF796F-0B3B-4B5A-AC82-99DABF06E11E@noao.edu> References: <93755.1203118959@critter.freebsd.dk> <47B7E616.7080304@ste-marie.org> <5424D09C-782F-477D-937F-A64624ABE132@noao.edu> <5AEF796F-0B3B-4B5A-AC82-99DABF06E11E@noao.edu> Message-ID: Surely the generous gifts of the Kofedix Dunark of Kondal upon the planet Osnom: > On his left wrist he wore an Osnomian chronometer. This was an > instrument resembling the odometer of an automobile, whose numerous > revolving segments revealed a large and constantly increasing number? > the date and time of the Osnomian day, expressed in a decimal number > of the karkamo of Kondalian history. > > "Greetings, oh guests from Earth! I feel more like myself, now that > I am again in my trappings and have my weapons at my side. Will you > accompany me to koprat, or are you not hungry?" as he attached the > peculiar timepieces to the wrists of the guests, with bracelets of > the deep-blue metal. > > [...] [T]he chronometer upon his wrist, which, driven by wireless > impulses from the master-clock in the national observatory, was > clicking off the darkamo with an almost inaudible purr of its > smoothly-revolving segments. > - E.E. Smith, The Skylark of Space, http://www.gutenberg.org/etext/20869 ...and of Orlon, the First of Astronomy of the planet Norlamin: > "Welcome to Norlamin, Terrestrials," the deep, calm voice of the > astronomer greeted them, and Orlon in the flesh shook hands > cordially in the American fashion with each of them in turn, and > placed around each neck a crystal chain from which depended a small > Norlaminian chronometer-radiophone. > - Skylark Three, http://www.gutenberg.org/etext/21051 ...testify to the key role that timekeeping plays throughout our busy galaxy. Remarkably, Hubble's settling of the Shapley-Curtis debate on the nature of the galaxy (and the universe) was roughly contemporaneous with "Doc" Smith's imaginative (if leaden) fiction. Closer to home, on the question of the scale of our solar system, Pluto was not discovered until 18 February 1930. Happy Birthday Pluto! Not only does a clock make a thoughtful gift upon landing on a new planet, but we have examples of thoughtfully diurnal timekeeping on another planet in the real universe - `namely the two rovers on Mars. As I type this, it is 23:09 local mean Martian time (http://www.giss.nasa.gov/tools/mars24/help/notes.html ) for Spirit and 11:08 for Opportunity. Nearing midnight for one and noon for the other. ` Moreover, to resolve any doubt of the intent, Spirit is depicted on a darkened landscape, Opportunity in daylight (marsrover.nasa.gov). It is noted that the rovers are each 1350+ sols past their design life. (One doubts the distinctive name for a Martian day, "sol", derives from a type of flatfish.) It is possible that the highly evolved Kondalians and Norlaminians handed their terrestrial visitors the equivalent of pure atomic clocks, unsullied by the vagaries of the local sun (or suns). Smith doesn't say. I think it more likely, however, that our spacefarers were graced with a watch set to local time precisely to permit them to keep track of the unfamiliar cadence of the daylight hours. A clock is a rate, not just a zero point (and UTCng breaks both). Sputnik was launched on 4 October 1957. Nine months later to the day, I was born. Likelihood of causal connection? Low (although "baby boom" in Russia is the "Sputnik Generation"). Sputnik was launched. Ten months later, NASA was founded with the signing of the National Aeronautics and Space Act of 1958. Likelihood of connection? Quite high. For the sake of avoiding conflict, I've learned my lesson and will stay away from more fanciful speculations. For instance, I won't strain credulity by trying to tie the fact that the Mars Rover mission has been extended by a factor of 16 beyond its design life, to some silly musings over whether system engineering best practices were followed. What was I thinking? Rob Seaman National Optical Astronomy Observatory -- "To know where the other person makes a mistake is of little value. It only becomes interesting when you know where you make the mistake, for then you can do something about it. What we can improve in others is of doubtful utility as a rule, if, indeed, it has any effect at all." - Jung From mgy1912 at cox.net Mon Feb 18 16:20:59 2008 From: mgy1912 at cox.net (Brian Garrett) Date: Mon, 18 Feb 2008 13:20:59 -0800 Subject: [LEAPSECS] Happy Birthday Pluto! References: <93755.1203118959@critter.freebsd.dk><47B7E616.7080304@ste-marie.org><5424D09C-782F-477D-937F-A64624ABE132@noao.edu><5AEF796F-0B3B-4B5A-AC82-99DABF06E11E@noao.edu> Message-ID: <001b01c87274$28353e90$de86db48@Fnord> ----- Original Message ----- From: "Rob Seaman" To: "Leap Second Discussion List" Sent: Monday, February 18, 2008 12:43 PM Subject: [LEAPSECS] Happy Birthday Pluto! Surely the generous gifts of the Kofedix Dunark of Kondal upon the planet Osnom: > [...] [T]he chronometer upon his wrist, which, driven by wireless > impulses from the master-clock in the national observatory, was clicking > off the darkamo with an almost inaudible purr of its smoothly-revolving > segments. > - E.E. Smith, The Skylark of Space, http://www.gutenberg.org/etext/20869 Thus anticipating modern radio-controlled clocks and watches by 60+ years. The guy's writing style may have sucked rubidium, but he knew his horology. ----- Remarkably, Hubble's settling of the Shapley-Curtis debate on the nature of the galaxy (and the universe) was roughly contemporaneous with "Doc" Smith's imaginative (if leaden) fiction. Closer to home, on the question of the scale of our solar system, Pluto was not discovered until 18 February 1930. Happy Birthday Pluto! ----- Now that Pluto has been evicted from the realm of Real Planets, and banished to the drug-infested back alleys of the Kuiper Belt, relegated to gangbanging with the likes of Quauoar, Sedna and Eris (and all for not cleaning his room, uh, neighborhood) I'm not sure this is cause for celebration as much as it used to be. Not only does a clock make a thoughtful gift upon landing on a new planet, but we have examples of thoughtfully diurnal timekeeping on another planet in the real universe - `namely the two rovers on Mars. As I type this, it is 23:09 local mean Martian time (http://www.giss.nasa.gov/tools/mars24/help/notes.html ) for Spirit and 11:08 for Opportunity. Nearing midnight for one and noon for the other. ` Moreover, to resolve any doubt of the intent, Spirit is depicted on a darkened landscape, Opportunity in daylight (marsrover.nasa.gov). It is noted that the rovers are each 1350+ sols past their design life. (One doubts the distinctive name for a Martian day, "sol", derives from a type of flatfish.) It is possible that the highly evolved Kondalians and Norlaminians handed their terrestrial visitors the equivalent of pure atomic clocks, unsullied by the vagaries of the local sun (or suns). Smith doesn't say. I think it more likely, however, that our spacefarers were graced with a watch set to local time precisely to permit them to keep track of the unfamiliar cadence of the daylight hours. A clock is a rate, not just a zero point (and UTCng breaks both). Sputnik was launched on 4 October 1957. Nine months later to the day, I was born. Likelihood of causal connection? Low (although "baby boom" in Russia is the "Sputnik Generation"). ------ Looks like the Russians weren't the only ones seeing rockets that night... Sputnik was launched. Ten months later, NASA was founded with the signing of the National Aeronautics and Space Act of 1958. Likelihood of connection? Quite high. For the sake of avoiding conflict, I've learned my lesson and will stay away from more fanciful speculations. For instance, I won't strain credulity by trying to tie the fact that the Mars Rover mission has been extended by a factor of 16 beyond its design life, to some silly musings over whether system engineering best practices were followed. What was I thinking? ----- You don't suppose that overpriced piece of crap that's falling to earth that the Pentagon's talking about shooting down (no, not Britney Spears' career, the OTHER one) was done in by leap seconds or DUT1 differences, do you? Brian Garrett trying desperately to keep this caffeine-driven bit of silliness on topic From phk at phk.freebsd.dk Mon Feb 18 17:10:14 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Feb 2008 22:10:14 +0000 Subject: [LEAPSECS] Happy Birthday Pluto! In-Reply-To: Your message of "Mon, 18 Feb 2008 13:20:59 PST." <001b01c87274$28353e90$de86db48@Fnord> Message-ID: <48088.1203372614@critter.freebsd.dk> >One doubts the distinctive name for a >Martian day, "sol", derives from a type of flatfish. Have you ever wondered about the origin of words like "Solarium", your latin teacher would be disappointed. And the flatfish is "sole" btw. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Mon Feb 18 19:02:41 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 18 Feb 2008 17:02:41 -0700 Subject: [LEAPSECS] Happy Birthday Pluto! In-Reply-To: <48088.1203372614@critter.freebsd.dk> References: <48088.1203372614@critter.freebsd.dk> Message-ID: > Have you ever wondered about the origin of words like "Solarium", I'm not sure how productive this discussion will be. The history of a word in English versus a similar word in another language may be quite divergent. For English, the dictionary has an origin for "solarium" in the early nineteenth century from the latin for balcony or terrace, but with those in turn deriving from the obvious reference to the sun. In Arizona (or southern Italy) any south facing balcony is a solarium. This may not hold in Denmark :-) The Indo-european roots conflate "sun" and "flat" (as in a sandal or a fish shaped like one) and "alone" and words like that. Any brief syllable is going to have numerous root meanings. I doubt it was what the Rover team was thinking when they chose "sol", but if you want to wander well off the beaten path try googling "Martian Latin". > And the flatfish is "sole" btw. No crappie. We're starting to flounder here and it's giving me a haddock. From mgy1912 at cox.net Mon Feb 18 22:16:51 2008 From: mgy1912 at cox.net (Brian Garrett) Date: Mon, 18 Feb 2008 19:16:51 -0800 Subject: [LEAPSECS] Happy Birthday Pluto! References: <48088.1203372614@critter.freebsd.dk> Message-ID: <000401c872a5$df579b50$de86db48@Fnord> ----- Original Message ----- From: "Rob Seaman" To: "Leap Second Discussion List" Sent: Monday, February 18, 2008 4:02 PM Subject: Re: [LEAPSECS] Happy Birthday Pluto! >> And the flatfish is "sole" btw. > > No crappie. We're starting to flounder here and it's giving me a > haddock. > You're trying to bait us just for the halibut, and we're not gonna hake it. Brian From clive at demon.net Wed Feb 20 03:39:03 2008 From: clive at demon.net (Clive D.W. Feather) Date: Wed, 20 Feb 2008 08:39:03 +0000 Subject: [LEAPSECS] Happy Birthday Pluto! In-Reply-To: <000401c872a5$df579b50$de86db48@Fnord> References: <48088.1203372614@critter.freebsd.dk> <000401c872a5$df579b50$de86db48@Fnord> Message-ID: <20080220083903.GI78000@finch-staff-1.thus.net> Brian Garrett said: >> No crappie. We're starting to flounder here and it's giving me a >> haddock. > You're trying to bait us just for the halibut, and we're not gonna hake it. Rather than casting any more barbs, cod we please return this discussion to its proper plaice? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | |