Re: [LEAPSECS] What problems do leap seconds *really* create?

From: Steve Allen <>
Date: Wed, 29 Jan 2003 12:53:44 -0800

On Wed 2003-01-29T15:05:59 -0500, John Cowan hath writ:
> > > > Who needs to know about a leap second more than half a year in advance
> > > > but has no access to a time signal broadcasting service (the better ones
> > > > of which all carry leap second announcement information today)?
> > >
> > > Any isolated system that it isn't practical to upgrade every six months.
> >
> > Please explain why this requirement is not confounded every time your
> > legislature decides to mess with the start and stop of summer time
> > (with a year's notice because of the olympics, or with a week's notice
> > because the war effort is going badly, or whatever).
> I was a little too clipped. If you know all the leap seconds, you can
> convert a Unix-style timestamp to UTC reliably; if you further know all
> the timezone changes, you can convert UTC to LCT reliably.

I remain confused about why this "isolated system" cares whether it
keeps time as UTC or TAI. How does its time get set? How does its
time stay locked to SI seconds?

Are you supposing that the system is able to keep SI seconds because
it has some sort of unshielded PLL which is tracking the carrier
signal from something like the US Navy's high powered VERDIN VLF
transmissions for submarines? (With their 50 baud message that
basically says "We're still here so don't launch" and if your clock
stops ticking, nothing really matters much anymore.)

If not, why does it not just count time as crystal oscillations since
the POST phase of its motherboard and not bother with names like

Is there really any system such as this?

Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064      Voice: +1 831 459 3046
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
Received on Wed Jan 29 2003 - 12:53:57 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT