>>simple arithmetic with a timescale with a variable second would give an >>order of magnitude better estimate of the amount of time between 2005 Dec 31 >>23:59:59.9 and 2006 Jan 01 00:00:00.1 than UTC does! > >UTC will tell you that there is EXACTLY 1.2 seconds between those two points.
The kind of "simple arithmetic" that I was thinking about precludes the use of look-up tables. >No estimation needed, so it would be infinitely better than some loosely >defined variable second. My suggestion does not call for a "loosely defined" second - it calls for a variable second, PRECISELY tied to TAI. In other words, time = a + b*TAI + c*TAI^2, where a, b and c are fixed constants chosen in such a way that "time" follows UT in the long term, though drifts against it in the short term (the constant "a" would approximate the difference between UTC and TAI at the time of introduction, "b" would essentially be unity, and "c" would be quite small). All time systems would keep TAI internally, and convert it to "time" for presentation to the user as needed. >One must understand that UTC does not follow the _convention_ that all >minutes have 60 seconds. This is where I have a real problem. Who is UTC meant to serve? Because if it is meant to serve the general public, I think you will find that the general public defines a minute as a period of 60 seconds - no more, and no less. If UTC isn't meant to serve the general public - if it is instead meant to serve astronomers and/or time purists, then I think we need a timescale that IS meant to serve the general public. >If one claims that leap seconds make UTC "discontinuous" by some other >definition, one must then admit that leap days make most other time scales >discontinuous also, for they are logically equivalent, differing only in >the amount of time before irregular corrections need to be applied (years >for leap seconds/UTC, millenia for leap days/Gregorian). OK - "discontinuous" was a bad choice of word on my part. >The people/organizations which are complaining about leap seconds have had >33 years to work this out, but haven't for the most part. After 33 years I think it's time to say - UTC has failed. It was a bad idea IMO. >Now they want to fundamentally change UTC (breaking systems which DO use >UTC as intended) to make up for their inaction. Laziness isn't the reason for the lack of action IMO - the reason for the lack of action is that it is a difficult thing to do right! It looks easy, it sounds easy, but it's actually not. There doesn't seem to be any argument between us that the non-forecastability of leap seconds is a major part of the problem but, actually, the leap seconds themselves are also a problem. Why? Because a 60-second minute is ingrained. For instance, what should analogue clocks do this December? How can I write a java-based analogue clock that is UTC-compliant? You mention that this will break systems that DO use UTC as intended. The only such systems that I'm aware of are GPS receivers (many of which will output 23:59:60 this coming December). Not even the venerable NTP will cause my computer to say "23:59:60". Out of curiosity, what other systems are leap second aware? Are there any systems with high public visibility that are leap second aware? Given that I'll be in the "GMT" timezone, is there anywhere I can bring my friends this new years eve where we can simultaneously sit down and have a nice beer AND witness the extra second before the start of 2006? >>Finally, over 400 years >>ago, there was a change made to our calendar that is still in use today, >>and that looks like it will still be in use 1,000 years from now (an >>impressive achievement by our forebearers) - I think we should aim for >>such a long-term solution for the measurement of the time of day. > >The Gregorian system slips about 1 day every 4000 years. Considering that is >shorter than recorded history, and very much less than human existance, I >consider that less than "long term." I did say "aim for...". Also, 4,000 years is a lot longer than the 1,200 years or so that the current definition of UTC can possibly work for. Chris. _______________________________________________ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts