Re: The real problem with leap seconds
From [EMAIL PROTECTED] Sat Jan 7 08:03:04 2006 Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by ivan.Harhan.ORG (5.61.1.3/1.36) id AA14507; Sat, 7 Jan 06 08:03:03 GMT Received: from rom.usno.navy.mil by [198.116.61.253] via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006 08:10:46 UT Received: from ROM (rom.usno.navy.mil [10.1.4.27]) by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k077o0kU019926; Sat, 7 Jan 2006 08:02:52 GMT Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release 1.8e) with spool id 0549 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 08:02:52 + Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k0782pkM019980 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 08:02:52 GMT Received: from santo.ucolick.org ([128.114.23.204]) by TS-FW.usno.navy.mil via smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006 08:10:36 UT Received: from localhost (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 475575D715 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:51 -0800 (PST) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id D9F7C11419 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:50 -0800 (PST) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (8.13.1/8.12.10) with ESMTP id k0782ofC025400 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:50 -0800 Received: (from [EMAIL PROTECTED]) by geneva.ucolick.org (8.13.1/8.13.1/Submit) id k0782oFP025399 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:50 -0800 Date: Sat, 7 Jan 2006 00:02:50 -0800 From: Steve Allen [EMAIL PROTECTED] To: Leap Second Discussion List LEAPSECS@ROM.USNO.NAVY.MIL Subject: Re: The real problem with leap seconds Message-Id: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.4.2.1i Sender: [EMAIL PROTECTED] Precedence: list Status: RO On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ: http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt If I read it right you have reinvented Markus Kuhn's UTS as seen in http://www.cl.cam.ac.uk/~mgk25/uts.txt http://www.cl.cam.ac.uk/~mgk25/time/leap/ http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m From [EMAIL PROTECTED] Sat Jan 7 12:28:40 2006 Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by ivan.Harhan.ORG (5.61.1.3/1.36) id AA14637; Sat, 7 Jan 06 12:28:38 GMT Received: from rom.usno.navy.mil by [198.116.61.253] via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006 12:36:23 UT Received: from ROM (rom.usno.navy.mil [10.1.4.27]) by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k07BLaki031306; Sat, 7 Jan 2006 12:28:29 GMT Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release 1.8e) with spool id 0583 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 12:28:28 + Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k07CSRkM032500 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 12:28:28 GMT Received: from mail.metronet.co.uk ([213.162.97.75]) by TS-FW.usno.navy.mil via smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006 12:36:12 UT Received: from [192.168.26.3] (213-162-103-78.edmund434.adsl.metronet.co.uk [213.162.103.78]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id 72B0F408240 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 12:28:18 + (GMT) Message-Id: [EMAIL PROTECTED] Date: Sat, 07 Jan 2006 12:28:20 + From: Ed Davies [EMAIL PROTECTED] User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en Mime-Version: 1.0 To: Leap Seconds Issues LEAPSECS@ROM.USNO.NAVY.MIL Subject: Re: [LEAPSECS] The real problem with leap seconds References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: [EMAIL PROTECTED] Precedence: list Status: RO Steve
Re: The real problem with leap seconds
Please ignore this post. It got away because I was connected to my UNIX host from my girlfriend's PC over her cable Internet connection which is probably the crappiest in the world as I was composing a reply to some posts on this list, and as it crapped out on me, the mail process on the UNIX host terminated and sent out whatever garbage was in its compose buffer. MS
Re: The real problem with leap seconds
Steve Allen [EMAIL PROTECTED] wrote: If I read it right you have reinvented Markus Kuhn's UTS [...] Close to it, but... Ed Davies [EMAIL PROTECTED] followed up: Also, Markus wasn't proposing UTS as a civil timescale but just for use within computer systems, etc. Therein lies the key difference. I have strived to make my argument as independent of computers as I could. To me the need for a real number time scale is necessitated more by philosophy than computer science, which is why I have resorted so much to the mathematical abstraction of a real number in my paper. My central argument still stands that current UTC is unsuitable for the *philosophical* application of defining the abstract ideal scale of civil time since it is not a scale in the mathematical definition of this term (a real number). I believe that the scale of civil time needs to be a scale. Furthermore, I believe that it should be related to the cycle of day and night rather than completely decoupled from it, so I won't support freezing the leap seconds for the next few centuries as a solution. That leaves me with my current position of arguing for a coordinated time scale with elongated and shortened seconds. MS
Re: The real problem with leap seconds
Poul-Henning Kamp [EMAIL PROTECTED] wrote: In this rather humorous document you have managed to say that POSIX screwed up badly. We already knew that :-) What does this have to do with POSIX? The word POSIX does not appear in my article. MS
Re: The real problem with leap seconds
Ed Davies [EMAIL PROTECTED] wrote: UTC is expressible as a real number in just the same way that Gregorian dates (with months with different lengths and leap days) can be with the Julian calendar. There's no difference in principle between converting from a TAI time in seconds since some epoch to a UTC date/time in days, hours, minutes, seconds and fractions of a second [...] You have dodged the problem so conveniently! Of course I know how to convert UTC to TAI or vice-versa, but that is not the problem statement at hand. The problem statement at hand is to express UTC *itself* as a real number, rather than convert it to some other time scale. For UTC itself must be expressible as a real number in order to be called a time *scale*. If you admit that this cannot be done, then you should revise TF.460-6 to remove all use of the word scale and openly admit to UTC being a time non-scale. Then no one will use UTC as the civil time scale since it'll be obvious that as a non-scale it is not suitable as a scale of any kind. I stand by my assertion that the current ITU-R spec for UTC (and its previous CCIR versions) is a clever scam, a parlor trick designed to sell a non-scale to civil philosophers wanting a SCALE of civil time. The manner in which it was adopted in 1970 by CCIR, a shove-down-the- throat move reminiscent of the current leap hour scheme, does not help them look any better. MS
Re: the tail wags the dog
Steve Allen [EMAIL PROTECTED] wrote: The CGPM recommendation on the timescale everyone should use says UTC. UTC(insert your national time service here) is available in real time. TAI is the mathematical (really the political or diplomatic) entity upon which UTC is ostensibly based, but the practical and legal reality is the other way around. Has it occurred to any of you that *THIS* is the very root of the problem, that *THIS* is what we need to change? Also, isn't TAI readily available in real time from GPS? (How difficult can it be for the routine parsing the data stream from the GPS receiver to add 19?) OK, OK, it'll be TAI(GPS) rather than true TAI, but then your UTC is really UTC(NIST) or UTC(USNO) or UTC(PTB) or whatever rather than true UTC. MS
Re: Risks of change to UTC
John Cowan [EMAIL PROTECTED] wrote: Once we have accomplished the former [changing the basis of civil time], I don't give a hoot about the latter [hobbling UTC]. Keep UTC if you want. Then what are you doing here? Why don't you go to your elected representatives in whatever country you call yours and lobby them to pass a law changing the basis of civil time in your country from UTC to TAI-33s? I'm equally baffled by those people who keep trying to make ITU hobble UTC. Those people are from the US government, aren't they? Then if they are the US government, the all-powerful government that doesn't give a flying rat's ass about anybody but themselves, why do they bother with ITU, why don't they just pass a law changing the US legal time to TAI-05:00:33 on the East Coast, TAI-06:00:33 Central, etc. Surely the all-powerful government could do this any moment without asking anyone, certainly not the common citizens? MS
Re: independence day
Rob Seaman [EMAIL PROTECTED] wrote: The point is, however, that nothing - absolutely nothing - would then protect legal timekeeping in the U.S. or elsewhere from the whims of future timekeepers at the ITU. Say we go with leap hours. UTC isn't therefore less malleable than currently - but rather more so in the only sense that matters for legal timekeeping. That is, a small entrenched committee would be able to vote arbitrary changes to international time precisely because the standard would no longer be tied to any physical phenomena. One might wonder why changes might be made. I'll only point out - why not? What in practice would stop these individuals from leaping the clock forward or backward at will, or from changing the rate of UTC, or for that matter from making the clocks run backwards? We already have a historical precedent for this kind of manipulation -- corrupt Roman calendar keeper priests who adjusted the calendar to extend or shorten the term of office of various elected officials. MS
Re: A lurker surfaces
Ashley Yakeley [EMAIL PROTECTED] wrote: I'd like to see an elastic civil second to which SI nanoseconds are added or removed. Ditto! I have always been in favor of rubber seconds, and specifically civil second. I believe that the *CIVIL* second should have its own definition completely and totally independent of the SI second. Civil time independent of physical time would solve all problems. The scale of civil time should be defined as a continuous real number scale of *angle*, not physical time. It would solve the problem of needing to measure time intervals while at the same time synchronising with the civil calendar. Civil time interval is defined as the clock on the Kremlin tower turning by a given angle. Define one second of civil time as the hour hand turning by 30 seconds of arc. The people who complain about leap seconds screwing up their interval time computations are usually told to use TAI. They retort that they need interval time *between civil timestamps*. To me that seems like what they are really measuring as interval time is not physical interval time, but how much time has elapsed *in civil society*. Hence my idea of civil interval time that's completely decoupled from physical time and is instead defined as the turning angle of the clock on the Kremlin tower. Flame deflector up MS
