End of the Leap Second

davefoc said:
I am a little surprised nobody has proposed the obvious solution.

Speed up (or slow down if necessary) the rotation rate of the earth to keep it in sync with the atomic clocks. This will make everybody happy.

We can speed up the earth by dumping mountains into the ocean.

Probably some of you are thinking this is an impractical idea because what happens when we run out of mountains to dump into the ocean. Well at that point we might try nuclear bomb fueled rockets located at the equator to accelerate the earth.

Slowing down the earth is even easier. We can do it by building large wind farms or large dams to increase the friction from tidal forces.

Please, please send that suggestion to your senator or congressmen... :)
 
Palimpsest said:
Ah. So would another solution be to have every Chinese person jump up and down at exactly the same time?

Alas, I am afraid not. That whole conservation of momentum thing you know.

ETA: But if they all climbed a ladder and stayed there that would slow the earth down a bit.

Best though would be for them to leave Tibet where their mass is suspended high above the earth on the Tibetan plane and live in lower parts of China. I think the Dalai Lama would like this idea also.
 
But adding these ad hoc "leap seconds" -- the last one was tacked on in 1998 -- can be a big hassle for computers operating with software programs that never allowed for a 61-second minute, leading to glitches when the extra second passes. "It's a huge deal," said John Yuzdepski, an executive at Symmetricom Inc., of San Jose, Calif., which makes ultraprecise clocks for telecommunications, space and military use.

Hang on a mo, why does any software have to deal with a "61 second minute"? All that is required is to reset the clock with the correct time - isn't it?
 
Darat said:
Hang on a mo, why does any software have to deal with a "61 second minute"? All that is required is to reset the clock with the correct time - isn't it?
Because it's apparently easier to alter the way the entire world (i.e. the US) measures time than it is to compensate for shoddy programming, and the ignorance of programmers.:D

Cheers,
Rat.
 
Darat said:
Hang on a mo, why does any software have to deal with a "61 second minute"? All that is required is to reset the clock with the correct time - isn't it?
A clock that goes backwards can confuse a program that expects it to go only forward.

The program will think that less time has elapsed than actually has elapsed. That could cause problems.
 
This issue seems like much ado about very little.

The overwhelming number of computer clocks in the world are used in non-critical applications. So there is no effect on keeping the current system or changing to a different system on these systems. I can live with my computer being off by a second or two and I am perfectly happy with a microwave clock that is even several seconds off.

Of the remaining clocks that might be involved in critical applications most are used for time stamping financial transactions. Resetting the clock every few years if it is even judged a worthwhile thing to do seems to be of very little risk and not worth worrying about. If a glitch occurs when the time is reset the software can be patched and nobody is hurt. In addition finding out about the software weakness could have some value.

A lot of the critical clocks are in scientific applications and a lot of those are in astronomy where they seem to be happy with leap seconds.

This leaves very few clocks of the total that are involved in life critical applications. These are mostly in navigation type applications some of which conceivably could have risk issues associated with resetting the time. The straightforward solution there is to never reset the clocks. Just maintain a different time standard that can be translated into the accepted standard.
 
davefoc said:
This leaves very few clocks of the total that are involved in life critical applications. These are mostly in navigation type applications some of which conceivably could have risk issues associated with resetting the time. The straightforward solution there is to never reset the clocks. Just maintain a different time standard that can be translated into the accepted standard.
I work with these (navigation systems). They get their time from GPS. I don't really deal with the GPS communications protocols, but your suggestion would require that it transmit at least 2 times.

With that said, however, the flight computer I use also need to deal with the fact that GPS time may not be available. For example, let's say the GPS was removed for maintainance. When reinstalled, it no longer knows the correct time and location, so it takes it a long time to sweep the sky and find the satellites. Or, in highly dynamic flight the GPS can lose tracking for a few seconds. Or, a bus error or internal error can render the GPS temporarily or permanantly unavailable. The upshot of all those failure scenerios is that the flight computer allows you to manually type in the time when GPS time is not available. You can type in any time at all. The software handles it. So the timekeeping software is already pretty robust.

That doesn't mean that it will necessarily handle a change in the leap second, as the flight computer recognizes when time is manually entered through the keypad, and may specifically call routines to ensure consistant navigation. It may very well not have software in place to deal with the GPS reporting a different time while all BIT (built in test) returns nominal conditions.

I'd have to dig through a lot of code to determine the case for the specific flight computers I deal with. Understandably, I'm not going to do that for a JREF thread :)
 
If you ask me, its not quite software which will have a hard time with a 61 second minute, but firmware. Or even low level electronics IC chips that rely on those little crystals to calculate time.

Daylight savings doesnt seem to worry banks much and thats what we're talking here. Setting the clocks forward/back a second or so.

I like the idea of nuclear bombs though. Nuclear bombs can fix everything.
 
69dodge said:
A clock that goes backwards can confuse a program that expects it to go only forward.

The program will think that less time has elapsed than actually has elapsed. That could cause problems.

But they're not hard to fix. I'm liking the proposal more and more.

Keep Zulu time standard, 60 seconds in a minute, always.

Put any second corrections in the time zone calculations, which already have to deal with minutes.

Do all elapsed time calculations in Zulu time.
 
Roger wrote:
I work with these (navigation systems). They get their time from GPS. I don't really deal with the GPS communications protocols, but your suggestion would require that it transmit at least 2 times.

What I was trying to suggest was that GPS maintain a GPS standard time. GPS standard time doesn't have leap seconds, time zones, daylight savings time, etc. It just counts time. If somebody wants to use GPS time for determining his local time he needs to account for leap seconds, time zone and daylight savings. Therefore GPS would transmit only one time code, the GPS time code, and the receiving device would use it for location determination and time determinination using the appropriate algorythms.

I think this might be what epepke was suggesting with his zulu time idea.
 
Originally posted by davefoc
What I was trying to suggest was that GPS maintain a GPS standard time. GPS standard time doesn't have leap seconds, time zones, daylight savings time, etc. It just counts time. If somebody wants to use GPS time for determining his local time he needs to account for leap seconds, time zone and daylight savings. Therefore GPS would transmit only one time code, the GPS time code, and the receiving device would use it for location determination and time determinination using the appropriate algorythms.

I think this might be what epepke was suggesting with his zulu time idea.
That's pretty much how GPS currently works.

http://www.seis.com.au/TechNotes/TN199901A_GPS_UTC.html

But, GPS satellites do transmit, in addition to GPS time, the difference between GPS time and UTC, so that GPS receivers don't have to find out the difference themselves some other way.
 
'Business' software certainly works on 'normal' time. Any change to time calculation would have more downside effects on IT than upside. Corporate computers are already aligned with the human perception of time.
 
As far as I know, time keeping is always analgoue. Computers & other digital equiptment use quartz crystals yeah? Well I wonder if its possible to adjust the times at the exteme low level of the IC chips.

Sounds akward I know, and you'd have to do it in sync but if you only had to do it on one computer, the time could drift several seconds either way & the computer would know otherwise cos its method of timekeeping would be off.

Maybe?? :confused:
 
DavoMan said:
As far as I know, time keeping is always analgoue. Computers & other digital equiptment use quartz crystals yeah? Well I wonder if its possible to adjust the times at the exteme low level of the IC chips.

Not hard at all. You just put a variable capacitor in parallel with or in series with the crystal. I used to do this with my digital watch to synchronize it with WWV.

The problem is that a second has to be defined as something for time-critical applications.
 

Back
Top Bottom