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. MS
Re: Hippocratic humours
Steve Allen <[EMAIL PROTECTED]> wrote: > I'll offer a crude paraphrase of the viewpoints on the issue of > knowing the interval to a date a year in the future: You would have a much easier time (pun) predicting the interval in SI seconds to a calendar date a year in the future if you use the Republic of Terra Calendar instead of the Gregorian one: http://ivan.Harhan.ORG/RT/calendar/spec.txt While the focus of this list has been on the inherent incongruence between Earth's diurnal rotation and atomic time and the fundamental problems in the various schemes to paste over it, the focus of my calendrical work has been on the inherent incongruence between Earth's diurnal rotation and Earth's orbit around the Sun, and the fundamental problems in the various schemes to paste over it. Just like some people here assert that interval time and time of day are two different things (and I would go even further and say that the SI second and the civil second should be two different things, allowing the latter to be elastic), I assert that a day and a date should be two different things: days are timed by the diurnal rotation, dates are subdivisions of the tropical year and are supposed to indicate where Earth is in its orbit relative to the vernal equinox irrespective of whether it rotates or not at all. My solution is rather complex and is detailed in the RT Calendar Specification pointed to above. The relevant answer here however is that the RT Calendar assigns dates based strictly on the cycle of tropical years completely irrespective of Earth's rotation, and Earth's orbital motion is much more stable and predictable than its rotation about its axis. MS
Re: 2006 WP-7A meeting summary
Daniel R. Tobias <[EMAIL PROTECTED]> wrote: > Why people always feel compelled to use proprietary Microsoftism file > formats for things that could be epressed perfectly fine in plain > ASCII text I have no idea. Would you or anyone else on the list be so kind as to provide an ASCII translation of that application/msword attachment for those of us who have absolutely no ability to read proprietary formats? TIA, 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: building consensus
John Cowan <[EMAIL PROTECTED]> wrote: > All your points are correct, but it doesn't change the fact that > there was no 1845-12-31 in Manila, any more than there was a > second labeled 2006-04-02T00:02:30 in New York. Perhaps you meant 2006-04-02T02:30:00? 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: 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: 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 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
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
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
>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 ; 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 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 Allen wrote: > On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ: > > >>http://iva
The real problem with leap seconds
Hello, I am a new entrant into the leap second debate and I have just written a paper in which I have outlined what I think is the real problem with UTC and leap seconds as they are currently implemented and a proposed solution. I have put the article on my web page: http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt The short summary is that I believe the root problem is not the adjustments made to the civil time scale to match Earth's rotation, but the fact that UTC is not expressible as a real number. Read the article for a detailed explanation of what I mean by that. I encourage both pro- and anti-leap second advocates on this list to read my article since there is that slight possibility that the problem I point out (which I haven't seen anyone else point out so far) and the solution I propose might just be the breath of fresh air that both sides of the debate need, and my proposal would allow civil time to be well anchored to Earth's rotation without causing grief for computer systems like leap seconds currently do. (Hey Poul -- I'm the maintainer of 4.3BSD-Quasijarus, so I guess our operating systems are distant cousins :) BB, MS