Slashdot Mirror
US DoD Poll On Leap Seconds
@10u8 writes "For time scales to leap, or not to leap, has been the question here before. The ITU-R will be considering leap seconds again in a few weeks. This week the USNO posted a survey about leap seconds by the US DoD. The issue has civil implications as well as technical ones, and there is a demonstrated way to respect the history, remove leaps from navigation and POSIX time, yet keep the sun overhead at noon."
No there isn't, but you can make it culminate at noon.
rj
Leap seconds correct for the rotation of the earth to keep the sun above at noon.
If we dispense with leap seconds then this relationship will slowly change and noon will eventually be dark.
Engineering is the art of compromise.
> There should be a planned algorithm that kicks in, and the simplest one that actually
> does the job should be used.
There is none. The rate of rotation of the Earth is slightly irregular in a not entirely predictable way.
> I don't think I even own a time keep device where this level of accuracy matters.
> Perhaps my GPS?
Definitely your GPS. It cares about nanoseconds.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
That's exactly the point. Changing software in military or even space systems isn't exactly trivial, maybe not even possible, plus you need a method to constantly provide (UT1-UTC) to the systems that rely on UT1 (astronomical time) being equal to UTC by less than a second. Like the radio controlled clock in your home. Or the time signal transmitters would have to be redefined not to transmit UTC but some new time scale, which would be a mess for GPS.
UTC without leap seconds is basically TAI (international atomic time) - a strictly linear SI second timescale as precise as we can reproduce it.
Just distribute (TAI-UTC) and (UT1-UTC) together with the usual time signals, leave UTC alone (with leap seconds) and you're all set and can use what you need. There is no one time scale; Einstein told us so. Better accept it.
thegodmovie.com - watch it
That's correct, because correcting the epoch for leap seconds would cause glitches in positioning as the corrections were applied. Instead, GPS broadcasts a UTC correction so the receiver can convert to UTC if required: ahref=http://www.navcen.uscg.gov/pubs/gps/sigspec/gpssps1.pdfrel=url2html-16574http://www.navcen.uscg.gov/pubs/gps/sigspec/gpssps1.pdf>
Quidnam Latine loqui modo coepi?
Navigation depends on time. The Navy is very interested in navigation. That's why they established the Naval Observatory in 1830.
USNO employs some of the formost experts on the subject. They are soliciting the opinions of some of the other stakeholders.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
The problem being, the need for a leap second is not predefinable, unlike a leap day. Leap seconds are needed to compensate for slight (millisecond range) variations in the length of each day, due to the earth's rotation speed not being constant. We currently cannot predict those variations, and as such, the leap seconds are determined based on astronomical observation and applied as needed.
upon the advice of my lawyer, i have no sig at this time
No they don't. If you'll look at the chart in the Wikipedia article, you'll see that since they started using them in 1972, they've never had to subtract a second. Either no change, or +1 second.
Good, inexpensive web hosting
Definitely your GPS. It cares about nanoseconds.
But so long as all the satellites are in sync with their atomic clocks showing the same time, does it matter??? Even without them being in sync, doesn't the GPS use time and rough location to locate the satellites (unitil it's logged on) and then isn't it the round trip time taken by signal that's being measured? Is there any dependancy on leap seconds?
GPS doesn't use UTC for its measurements; it uses its own system of GPS time for its measurements, and then calculates UTC using a correction value transmitted by the satellites in order to be able to display UTC (or any other UTC-derived time) for the user.
Also, it doesn't "log in" in any usual sense, as the communication is purely one-way, from the satellite broadcasts to the receiver. Thus, it also doesn't measure round trip time, because there is no round trip. What it does is to receive the signals from multiple satellites, each of which essentially transmits a signal saying "I'm satellite number A, my location is B, and the time is C", and then solve a system of equations to figure out what time it was when it received the signals from each satellite, and thus how long each one-way trip took. Then it can do the geometry to figure out where it must be. The actual mechanism of accomplishing this is a whole lot more complicated, but on a very simple level, that's what's being done.
The reason it takes at least four visible satellites to produce a 3D fix is because it needs to solve a system of at least four equations with four unknowns: X, Y and Z spatial coordinates, and time. More than four satellites are normally needed for good accuracy, since the each measurement is usually a lot more noisy and less precise than is desired. Additional measurements let the receiver do more math to try and filter out the noise.
Not surprised, there is really no need to. Your GPSr doesn't care what time it is in human terms... I would be more surprised if they acutally didupdate GPS satellites with leap second fixes.
Actually that is one of the jobs of the US Naval Observatory. They constantly update the GPS satelights time and position information. If you have a hand held gps receiver you have an atomic accuracy clock in your hand. The USNO mission is to: 2 Provide astronomical and timing data required by the Navy and other components of the Department of Defense for navigation, precise positioning, and command, control, and communications. http://www.usno.navy.mil/mission.shtml If you have one clock you know the time but as soon as you have two clocks time becomes relative.
No, they don't. The Earth's rotation rate is slowing due to tidal friction (and slowly pushing the moon away in the process, since angular momentum doesn't just vanish). The SI second was set based off of the average solar day back in the 1700's or so, and the Earth's average rotational period has slowed measurably since then. We have only added leap seconds, never subtracted them, and likely never will, despite a significant variation in the rate of slowing.
The problem is that we want to measure different periodic processes via the same unit - the second. The second was originally based off of the average length of the solar day, but then was redefined in terms of atomic standards. The average solar day, according to atomic standards, has been lengthening somewhat erratically. Either we give up using the second as a fundamental unit in the SI system, suitable for meausring times vast and small, or we give up having our clocks based on the second but choose some other 'variable' unit, synced to the sun (such as UT1 time), or we compromise and stick a leap second in from time to time to assure that UTC and UT1 remain within a second of each other - which is what is currently done. There really isn't an easy way out since the periodic processes of nature that matter to us are not neatly in ratios. Do we really want a 'science' time, and a 'civilian' time?
As you say, one day, programmers will wrap these difficulties up in libraries nicely and neatly so that it just 'works', but it will be based on an arbitrary table of leap seconds, much like we have an arbitrary table of time zone rules in our zoneinfo files. Part of the problem was due to the POSIX standard for time NOT being done properly. UTC actually specifies that the 'extra' second means that there are 61 seconds in a particular minute - i.e. 23:59:60 is a valid UTC time when a leap second is inserted. Unfortunately, POSIX time 'repeats' a second instead. POSIX time goes.... 23:59:57....23:59:58.... 23:59:59.....(zip! leap second!) 23:59:59.... 00:00:00.... 00:00:01... etc.
There are some complex tradeoffs associated with this. It simplifies the numerical calculation of traslating POSIX time (since POSIX time really is represented as the integer number of seconds since 1970-Jan-01 00:00:00, and the leap seconds are ignored) to 'clockface' time (i.e. The year, month, date, hour, minute and second). On the other hand, it yields incorrect answers when two POSIX times are naively subtracted to figure out the time delta between the time marks; one has to modify the 'obvious' subtraction algorithm with a somewhat complex lookup table procedure to get an accurate delta. UTC is more complex because the occassional 61 second minute requires that you consult a lookup table to translate UTC seconds to year-month-date-hour-minute-second form, but subtraction easily yields the correct delta between the time marks. If we want to stick with SI seconds and schedule ourselves with the sun, there will always be some messiness!