Avoiding the Leap Second

wrote in message
oups.com...
: On May 30, 5:51 pm, Quadibloc wrote:
: [...]
: Since I'm proposing changing the length of a second, though, by an
: approximation, rather than the *exact* proportion that adding an extra
: second would make, this would not lead to TAI minus civil time being
: an integer number of seconds at least at the start of each new year.
: There are two possible cures: use the exact proportion instead
: (adjusted in leap years!), or switch from a longer second to a regular
: one before the end of the year (for example, splitting the leap second
: up among all the seconds of the first 360 days of the year would lead
: to an "even" lengthening of the second in some senses).
:
: John Savard
:
: Why not simultaneously go decimal for time?
:
: For example: 100 new seconds to a new minute, 100 new minutes to a
: new hour, and, say, 10 new hours in a standard day. The present use
: of 60/60/24 is archaic.
:
: Gawd only knows what that'd do to RA and Dec. :-)

Simple: make pi = 3 and use radians.

I get the impression "Quadibloc" may have calluses on his knuckles
and an opposable big toe, making 14Hex rather than 12 base 8 better
for him, it fairly obvious what is being counted on he
http://www.seaworld.org/animal-info/...le-big-toe.jpg

On May 31, 8:38 am, Andrew Smallshaw wrote:
ISTR that according to international agreements UTC must remain
within one second of GMT.

UTC is under the control of the ITU-R. There is no reason to believe
that the ITU-R currently believes this, and lots of reason to believe
that they do not. In part this is due to the fact that there really
is no such thing as GMT anymore, at least not as any kind of precision
entity. The IAU 2000 reforms for earth rotation pretty much abolished
the concept. The reformulations which allow re-creation of the
previous entities for earth rotation are now given the name
"classical" in order to distinguish them from the currently official
conventions.

From memory even a one
second difference between UTC and GMT equates to a quarter mile on
the ground. At 30 minute difference would make traditional navigation
impossible.

If "traditional navigation" means using some sort of almanac, then
this is not the case. It is straightforward to predict earth rotation
to within one second with a five year lookahead, and the pre-
publication lead time even for printed almanacs is less than this.
Therefore, with or without leap seconds, the almanacs used for
"traditional navigation" can easily change their tabulations such that
the users of such traditional methods won't notice the change.

Androcles wrote:
"Quadibloc" wrote in message

: and about 365 days in a year.

About? What's this "about"? We have leap days every 4 years
exactly, except every 400 years, and you want to talk of "about"?

Almost right - do you want to try again ?

"Tee Lion" wrote in message
...
: Androcles wrote:
: "Quadibloc" wrote in message
:
: : and about 365 days in a year.
:
: About? What's this "about"? We have leap days every 4 years
: exactly, except every 400 years, and you want to talk of "about"?
:
: [snip] right [snip].

I know I am. No need for you to try again, I can snip better than you.

Androcles wrote:
"Tee Lion" wrote in message
...
: Androcles wrote:
: "Quadibloc" wrote in message
:
: : and about 365 days in a year.
:
: About? What's this "about"? We have leap days every 4 years
: exactly, except every 400 years, and you want to talk of "about"?
:
: [snip] right [snip].

I know I am.

Tee hee! Too old to learn

Androcles wrote:
"Tee Lion" wrote in message
...
: Androcles wrote:
: "Quadibloc" wrote in message
:
: : and about 365 days in a year.
:
: About? What's this "about"? We have leap days every 4 years
: exactly, except every 400 years, and you want to talk of "about"?
:
: [snip] right [snip].

I know I am. No need for you to try again, I can snip better than you.

For the record
Years divisible by 100 are NOT leap years, except when they are
divisible by 400.
Hence 1900 was not a leap year but 2000 was one.

wrote:
On May 31, 2:36 pm, Steve Willner wrote:
..
Let's consider a new time scale... call it UTx. On days with no leap
second, UTx = UTC. On days having a leap second, UTx uses a second
86401/86400 times longer than the SI second with no leap second added.
..
This evokes the Sydney Harris cartoon with the blackboard full of
equations, in the middle reading "then a miracle occurs". How exactly
is this scheme going to be implemented? How is this communicated to
systems which can tolerate that much frequency variance, and how is it
prevented from affecting systems which cannot?
..
His idea is very much like mine, except I suggest that on *years*
having a leap second, use a second (365*86400)+1/(365*86400) times
longer than the SI second. And then I suggest it could be made more
complicated (besides using the SI second on February 29, come what
may) so that the "longer" second would be easy to generate from
appropriate clocks.

Here, the frequency variance is 365 times smaller, and it will affect
very few systems. Systems intolerant of frequency variance *usually*
don't have to worry about epoch. Systems that are involved in
timekeeping usually use quartz oscillators at best, and it is
difficult to make them accurate to one second a year.

So, basically, the "real" time is communicated to such systems as it
is now: check them against WWV once in a while.

John Savard

Andrew Smallshaw wrote:
To elaborate on this, now the metre is defined as the distance
light travels in 1/299,792,458 s in a vacuum. So even the metre
would change with a new second and then there's the Newton, amp[1],
Pascal, and countless other derived units. That's obviously a
non-starter.
..
And I do not propose to change the definition of the SI second.

If the second, as used in measurement of frequency, remained shorter
than the second used in civil time all the way from 1900 to 1972, at
which point civil time was 42.184 seconds ahead of Ephemeris Time, the
two starting out even in 1900, then presumably the second of civil
time can be different from the second used for measurement in the
future as well.

John Savard

Guy Macon wrote:
Many networks have far better accuracy than a quartz crystal
timer does. This is from one of the many available network
time server boxes, specifying holdover accuracy during GPS
outages:

== start of quote ==
|
| "NetClock NTP servers are designed to maintain accuracy in the
| event of loss of the GPS signal due to severe weather (lightning
| strikes, high winds, etc.), physical damage to the antenna, GPS
| signal jamming and electromagnetic pulse (EMP), and even if the
| federal government disables the GPS signal. Internal oscillators
| ensure seamless operation if the GPS signal is lost by maintaining
| synchronization accuracy until the GPS signal is restored.
|
| "A choice of 3 oscillators are available depending on the needs
| of the application. A temperature controlled crystal oscillator
| (TCXO) is standard. Optional oven-controlled crystal oscillators
| (OCXO) and Rubidium-stabilized (Rb) oscillators offer extended
| 'holdover' accuracy.
|
| Oscillator Drift Rate Holdover Accuracy Recommended
| (nanosec/sec) (millsec/day) Holdover
|
| TCXO 2,000 172.8 days
| OCXO 20 1.728 months
| Rb 0.05 0.1296 years
|
== end of quote ==

In many network applications, having two computers be off by up
to a second (as in one using SI time and the other using Civil
time can be a Very Bad Thing.

Consider a computer that falsely concludes that another computer
has a newer version of some data and thus overwrites new data
with old data. Or a computer that falsely concludes that another
computer has an older version of the data and thus refuses to
update it's copy.

OCXO is accurate to 20 nanoseconds per second, and my proposal
involves altering the length of a second by about 32 nanoseconds. So
it's a near thing there, but certainly the people with *Rubidium*
oscillators are going to have trouble - they will need to retrofit
their equipment.

Actually, in this case, though, since the stuff is being updated by
GPS time instead of WWV, it's *already* in trouble. GPS time is keyed
to plain atomic time - no leap seconds, and nothing in the GPS signal
tells you about leap seconds. You have to key that in by hand, I
suppose.

So GPS time has to be converted to UTC based on leap second
information, and only the software conversion would change. If you're
using timestamps in milliseconds, for example, your software would
just insert leap milliseconds at a uniform rate during years with long
seconds.

John Savard

Androcles wrote:
"Quadibloc" wrote in message
oups.com...

: There are 86,400 seconds in a day,

Not in a sidereal day there are not, althought the "mass of humanity"
has never heard of a sidereal day. They see sun, astronomers look
at the night sky.

Yes, but in one way this hardly has anything to do with timekeeping.
Of course, in determining the time from the Earth's motions, it *is*
the sidereal day that is the uniform one you need to use. But even
astronomers need to know when it is night, because some forms of
visual observation are hard to do in the day time.

: and about 365 days in a year.

About? What's this "about"? We have leap days every 4 years
exactly, except every 400 years, and you want to talk of "about"?

Yes, that's 365.2425 days by the Gregorian calendar, and of course the
real tropical year is about 365.2422 days - there are a few more
digits we know after the decimal point.

: If we
: add one second to a year, then, that lengthens the year by one part in
: 365 times 86,400.

I was cautious in warning you, but you were right, you don't think.

You're starting to become as annoying as Sherlock Holmes was...

John Savard