Re: civil time = solar time

[John Cowan]

Rob Seaman scripsit:

> Rather, the often repeated canard that civilians don't give a fig for
> the actual position of the sun in the sky implies that it is
> precisely apparent solar time that only queer ducks like astronomers
> care about.  Mean solar time is what civilians DO care about.

Most civilians, with some exceptions like Orthodox Jews, Muslims, and
farmers, care about LCT, and LCT only has to meet PHK's criteria.

--
Do NOT stray from the path! John Cowan <[EMAIL PROTECTED]>
--Gandalf   http://www.ccil.org/~cowan

Re: civil time = solar time

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Rob Seaman writes:

>I said:
>
>> all parties must certainly agree that civil time (as we know it) IS
>> mean solar time.
>
>Ed says:
>
>> saying that it "IS" civil time is probably a bit strong.
>
>"Probably a bit strong" is not precisely a staunch denial.
>
>[...]
>
>This is simply a classic exercise in applying epsilon constraints.

Yes, another inappropriate method used to sell your bogus argument.

It's bogus because neither "local time" nor "civil time" is a
continous variable but a quantified variable (because of the timezones)

The minimum epsilon constraint which is valid for a quantified
variable is the unit of quantum.  That is why all digital measurements
by definition have an uncertainty of at least +/- 1 digit.

The longitude conference defined the unit of quantum as 1 hour but
despite this I belive a few localities (.au ?) have opted for a
30minute quantum.

>>  1. local civil time matches apparent solar time roughly

Because local civil time have chosen timezones appropriate for
this purpose.

>>  2. the relationship between local civil time and apparent solar
>> time is constant enough in any one place

Uhm no.  Politicians have decided to make it flip 15 degrees forth
and back with summertime regulations.

>>  3. the rate of local civil time is constant at least to the
>> precision of most clocks and watches.

This is a rather empty statement because most clocks and watches
are built, sold, bought and adjusted to show civil time.

>>  4. the relationship between local civil time and international
>> civil time should be predicatable and easy to calculate with

Which is why the longitude conference decided on a 1 hour quantum.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Re: Longer leap second notice

[John Cowan]

Ed Davies scripsit:

> The main requirements for local civil time for the bulk of its
> users are that:

Agreed.

>  1. local civil time matches apparent solar time roughly (e.g., the
> sun is pretty high in the sky at 12:00 and it's dark at 00:00).

I think the last is the important point, or more specifically that the
bulk of the population not begin work on one day and end on another
(astronomers excepted, of course).  This would be a bookkeeping nightmare.

--
Barry gules and argent of seven and six,John Cowan
on a canton azure fifty molets of the second.   [EMAIL PROTECTED]
--blazoning the U.S. flag   http://www.ccil.org/~cowan

Re: Double 59; 60; or double 00?

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
"Tom Van Baak" <[EMAIL PROTECTED]> writes:
: With the surge of leap second captures this time
: around, are there any concerns over the growing(?)
: use of double :59 second or double :00 second
: instead of :59:60 for a positive leap second?
:
: Although not technically correct, they do seem a
: practical, perhaps even clever, alternative -- in some
: cases -- to the upstream parsing trouble that the
: exceptional :59:60 causes.
:
: Given a choice I would vote for double :59 over
: double :00 since :59 is still in the previous day
: (where the leap second occurs). Also, :59 offers
: more symmetry between positive and negative
: leap seconds (58 and 00 are constant; 59 is
: double or nothing depending on leap type).

ntp implements the double 59, and that works well when one can't
represent the number as :60 (which is impossible to do in POSIX
time_t).

POSIX, interestingly enough, doesn't define what happens at the
leapsecond very well.  On the one hand, they officially don't exist.
On the other, if you convert 23:59:60 to a time_t using mktime, you
get 0:00:00 due to normalization that happens in mktime (a more or
less accidental effect).  This leads some to conclude that the proper
POSIX sequence is with two 0's in a row.  While this is a conclusion
from reading POSIX, it isn't the only conclusion.

Warner

Re: Longer leap second notice

[Ed Davies]

Rob Seaman wrote:


Little support - and again, to a certain level of precision (easily
better than a second per day), all parties must certainly agree that
civil time (as we know it) IS mean solar time. 


We've got a bunch of time scales here:

 - apparent solar time.
 - mean solar time.
 - local civil time.
 - international civil time.

The main requirements for local civil time for the bulk of its
users are that:

 1. local civil time matches apparent solar time roughly (e.g., the
sun is pretty high in the sky at 12:00 and it's dark at 00:00).

 2. the relationship between local civil time and apparent solar
time is constant enough in any one place (e.g., if it's
sometimes noon at 10:45 local somewhere in eastern China then
it should be noon around 10:45 every day there, +/- half an
hour or so).

 3. the rate of local civil time is constant at least to the
precision of most clocks and watches.

 4. the relationship between local civil time and international
civil time should be predicatable and easy to calculate with
(e.g., round numbers of hours or, if somebody insists, minutes).

Points 1 and 2 are similar but not quite the same.  If, for
example, the whole world used GMT then 2 would be true everywhere
but 1 would only be true around the prime meridian.

Mean solar time isn't really of much interest to anybody, except
indirectly.  It acts as a more or less constant rate approximation
to apparent solar time (requirements 2 and 3).

If we lived on a planet with an equation of time which gave much
wider swings in the difference between apparent and mean solar
time we might have clocks with variable rates - like they had for
the stage coaches in Britain before GMT except you'd use the
different rates in spring and autumn or whenever, not when you're
going east or west.  We'd do that if we thought requirements 1
and 2 trumped 3.

In summary - it is convenient to have a civil timescale which
is both constant rate and a reasonable approximation of apparent
solar time.  Mean solar time fits that bill if you don't look
too closely at the constant rate aspects but saying that it "IS"
civil time is probably a bit strong.

Ed.

Re: Diagram of CHU Leap-Second Recording and "Atomic" Clock

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, "Tom Van Baak" writes:
>> The majority of such clocks only run the receiver for some part of
>> the day to save power.
>>
>> One particular kind I examined ran the receiver until it had sync,
>> then powered the receiver down for 23 hours and repeated the cycle.
>
>Yes, but the LS bit stays lit for the entire month (at
>least for WWVB) so the RC clock has plenty of notice
>to insert a leap second at the end of the month if it
>wanted to, regardless of reception quality the day
>of the leap second.
>
>Unfortunately, this is not the case with the DST bits.
>Users routinely complain that WWVB RC clocks do
>not handle DST correctly. This is because there is
>less than one day advance notice of a DST change.

DCF77 lights the bit for only one hour prior to the leap-second :-(


--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

25 o'clock, we'll be together 'til the end of time (was Re: [LEAPSECS] Longer leap second notice)

[Rob Seaman]

(Extra credit for those who recognize the quote.)

Tom Van Baak wrote:


A more apt comparison would be to the leap year rules that we
have.  We know the rules going
forward a thousand years or so.


Apt indeed.  Leap seconds are scheduled at least six months in
advance.  That's about one part in 15 million.  A thousand year
horizon for scheduling leap days is one part in 365,250.  So we're
already doing 50 times better than Julius Caesar and Gregory XIII.


I'm glad someone else came to this conclusion too.
But be careful, though, that this line of thought isn't
used to justify leap hours over leap seconds. One
leap hour predicted for a fixed date of, say, the year
2600 is about one part in 5 million; still 15x better
than the Gregorian calendar.


One of the more disquieting aspects of the leap hour
"proposal" (really a "notional position") is the tolerance for slop
in our clocks.  If you don't give a rat's ass for enforcing any kind
of limit on the amplitude of the excursion that is more precise than
"an hour", you can indeed schedule a leap hour for any particular
decade or century that you care to name.  This is especially true if
you don't even bother to discuss *how* the leap hour will be
implemented other than by loose analogy with daylight saving time.

On the other hand, if an explicit leap hour trigger condition were
specified (i.e., "issue a leap hour on the next December 31 after |
DUT1| exceeds 31 minutes"), it would be at least as difficult to
predictively schedule leap hours as leap seconds.  One expects there
would be strong pressure to issue the leap hour (singular and unique
because I'm convinced one would be more than enough for civilization
to bear) - strong pressure, that is, to issue the leap hour at some
round dut1 boundary - 30, 40, 50 minutes.  (I think some have been
thinking, "count up to 60:00 and subtract it off again".)  In point
of fact, one might expect that the prospect of undergoing a leap hour
during a particular lifetime would be so daunting that the leap hour
would be delayed as long a possible.  (That's the whole driving
motivation, after all.)  This is directly counter to the evident
policy for issuing leap seconds that has historically resulted in
each leap second occurring as soon as practical (presumably to allow
"slack" the next time).

Also, a leap second is not implemented using the same method as
daylight saving time.  A leap second is not a "fall back" second, but
rather a "do it twice" second - precisely to preserve the historical
flow of time.  This would be a much more critical issue for leap hours.

There appears to be an assumption that a leap hour would be
implemented as an extra "fall back" hour inserted into the stream of
daylight saving.  Let's ignore the fact that many localities do not
currently observer daylight saving and have no infrastructure for
implementing such.  Let's also ignore the question of whether anybody
at all will observe daylight saving centuries hence.  Rather let's
focus on how to maintain the historical flow of time across this
factor of 3600X higher temporal cliff.  The reason daylight saving
can ignore this issue is precisely that all localities observe an
underlying standard time for which no discontinuity occurs.  A
contract, for instance, can be specified with respect to standard
time and the implications of that contract are coherently
understandable to all parties even *during* a "spring forward" or
"fall back" jump.

But a leap hour is an adjustment of the underlying standard time.
Again, let's ignore the very real question of how all localities
might be convinced to implement a leap hour simultaneously.  Without
a stable underlying reference clock, a standard time zone undergoing
a "fall back" leap hour would experience a colossal crack in time.  I
assert that our mutated, gill-breathing, Christmas-hating great-
great-...-great-grandchildren would clearly not choose to implement a
leap hour as a "fall back" hour.  Rather, they would adopt the "do it
twice" algorithm currently used for leap seconds.  One speculates
that the day in question would simply be declared to be 25 hours
long.  This would preserve the "historical record".  (GalaxyQuest
anyone?)

Note however, how much more prominent a leap hour becomes.  Nobody
has surely expected it to be something that virtually all of
civilization can ignore - like, say - a leap second.  But unlike the
naive notion of simply "falling back" twice one year, this becomes
not just a big deal on the day in question - not just a big deal
during the year in question - not just a big deal during the century
in question - but would be a unique occurrence in all of recorded
human history.  It would henceforth be the "25 Hour Day".

More than four centuries later, historians still have to keep track
of the calendar change.  The English speaking world conflated the
trouble by delaying implementation for 170 years.  How much more
confusing should some locales delay - perhaps guided by lo

Double 59; 60; or double 00?

[Tom Van Baak]

With the surge of leap second captures this time
around, are there any concerns over the growing(?)
use of double :59 second or double :00 second
instead of :59:60 for a positive leap second?

Although not technically correct, they do seem a
practical, perhaps even clever, alternative -- in some
cases -- to the upstream parsing trouble that the
exceptional :59:60 causes.

Given a choice I would vote for double :59 over
double :00 since :59 is still in the previous day
(where the leap second occurs). Also, :59 offers
more symmetry between positive and negative
leap seconds (58 and 00 are constant; 59 is
double or nothing depending on leap type).

/tvb
http://www.LeapSecond.com

Re: Longer leap second notice

[Tom Van Baak]

> > A more apt comparison would be to the leap year rules that we
> > have.  We know the rules going
> > forward a thousand years or so.
>
> Apt indeed.  Leap seconds are scheduled at least six months in
> advance.  That's about one part in 15 million.  A thousand year
> horizon for scheduling leap days is one part in 365,250.  So we're
> already doing 50 times better than Julius Caesar and Gregory XIII.

I'm glad someone else came to this conclusion too.
But be careful, though, that this line of thought isn't
used to justify leap hours over leap seconds. One
leap hour predicted for a fixed date of, say, the year
2600 is about one part in 5 million; still 15x better
than the Gregorian calendar.

/tvb

Re: Diagram of CHU Leap-Second Recording and "Atomic" Clock

[Tom Van Baak]

> The majority of such clocks only run the receiver for some part of
> the day to save power.
>
> One particular kind I examined ran the receiver until it had sync,
> then powered the receiver down for 23 hours and repeated the cycle.

Yes, but the LS bit stays lit for the entire month (at
least for WWVB) so the RC clock has plenty of notice
to insert a leap second at the end of the month if it
wanted to, regardless of reception quality the day
of the leap second.

Unfortunately, this is not the case with the DST bits.
Users routinely complain that WWVB RC clocks do
not handle DST correctly. This is because there is
less than one day advance notice of a DST change.

Given that most RC clocks only tune in late at night
(e.g., 11 PM), unless one has perfect reception in the
few hour window between 11 PM and 2 AM, a WWVB
RC clock won't make the DST switch in time.

To me this is a broken design, but I can't see it being
fixed anytime soon. The right way is something like a
DST count-down field (perhaps at least 3 bits wide).

Are there some LF broadcasts that announce DST  far
enough (many days or weeks) in advance that the time
change can be done reliably?

/tvb

Re: Diagram of CHU Leap-Second Recording and "Atomic" Clock

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Tom Van Baak writes:

>As for your Skyscan clock, I have several dozen
>similar consumer RC clocks here and none has
>ever adjusted itself for a leap second in real-time

The majority of such clocks only run the receiver for some part of
the day to save power.

One particular kind I examined ran the receiver until it had sync,
then powered the receiver down for 23 hours and repeated the cycle.

My local clockaholic told me that some of the more modern ones
sleep based on battery voltage:  As the voltage drops, the chance
of slips in the mechanism increases and the receiver will turn on
more often to make sure it is still in sync.

In the case of DCF77, that means that you'd have to be rather lucky
for your clock to do the leapsecond in real time.

Poul-Henning

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Re: Longer leap second notice

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Rob Seaman writes:
>Hi Warner,
>
>> A more apt comparison would be to the leap year rules that we
>> have.  We know the rules going
>> forward a thousand years or so.
>
>Apt indeed.  Leap seconds are scheduled at least six months in
>advance.  That's about one part in 15 million.  A thousand year
>horizon for scheduling leap days is one part in 365,250.  So we're
>already doing 50 times better than Julius Caesar and Gregory XIII.

This comparison is utter rubbish, and you know it.

>Little support - and again, to a certain level of precision (easily
>better than a second per day), all parties must certainly agree that
>civil time (as we know it) IS mean solar time.

Since you keep repeating this "Nixon cannot have won, nobody I know
voted for him" falsehood let me express myself in very simple terms:

No, I do *NOT* agree that civil time is mean solar time.

Got it ?

Civil time is at best local solar time +/- up to several hours in
either direction depending who you are and where you are.

Seveal geographical/political regions have actively chosen to
increase the distance between mean solar time and local time during
various stretches of time, often in periodic fasion and sometimes
with far too little thought before the decision.

We keep hearing "use an appropriate timescale" and in the same emails
we hear "UTC is a convenient approximation of UT1".

Sounds to me like that argument should be backfired:  If you need UT1,
then use an appropriate timescale: UT1, don't force the majority
of UTC users to suffer because you use the wrong timescale.

>Can't argue with that - although ultimately a single well tied knot
>is stronger than a tangle of slip knots and Grannies.

We're not talking about knots here, this is not cryptography,
we are talking about byzantine decision scenarios (I have three
references, one say leap second, one says no leap second and one
says nothing, what should I do ?)

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Re: Longer leap second notice

[jcowan]

Rob Seaman scripsit:

> Little support - and again, to a certain level of precision (easily
> better than a second per day), all parties must certainly agree that
> civil time (as we know it)

Why do you persist in claiming that "all parties must certainly agree"
on something that is precisely the point most in dispute?

No communication with you is possible until you accept that there *is*
a controversy over this.

--
Deshil Holles eamus.  Deshil Holles eamus.  Deshil Holles eamus.
Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!
  -- Joyce, Ulysses, "Oxen of the Sun"   [EMAIL PROTECTED]

ITU Request for Leap Second Experiences

[Ed Mirmak]

Those who have submitted data, plots, or descriptions of system response to
the leap second addition may want to forward those messages to ITU WP-7A.

Related to the Nov 2005 U.S. proposal to the ITU to redefine UTC and
abandon leap seconds, they are soliciting information from various sources
on both positive and negative experiences.

See:

http://www.bipm.fr/en/scientific/tai/future_utc.html

http://www.bipm.fr/utils/en/pdf/ITU-R_leapseconds_letter.pdf

They give two different e-mail addresses.  From the first web page:
"Responses can be sent before 13 February 2006 to [EMAIL PROTECTED],
indicating 'UTC consultation' in the subject of the message."

>From the letter, e-mail address is:
[EMAIL PROTECTED]

Re: Diagram of CHU Leap-Second Recording and "Atomic" Clock

[Tom Van Baak]

It is correct that DUT1 changes by +1.0 across a
positive leap second; going from a negative value
(e.g., -0.6) to a positive value (e.g., +0.4).

You would see the inverse in the case of a negative
leap second (DUT1 will, by definition, be positive
before the negative leap second and go negative
after the leap).

As for the delay in implementing IERS bulletin D 92;
I was always under the impression that national
time institutions could implement this at their
convenience and, unlike leap seconds, did not
have to change the DUT1 bits at the precise day
and hour that IERS dictated.

Perhaps someone on the list from NIST or USNO
can clarify how this has been done in the past?

When you think of it; with DUT1 being broadcast
with a low precision of 0.1 seconds; there doesn't
seem to be any reason to expect every national or
local IRIG broadcast of DUT1 to make the change
with 1 minute, or 1 day, or even 1 month precision.

As for your Skyscan clock, I have several dozen
similar consumer RC clocks here and none has
ever adjusted itself for a leap second in real-time
(also try displaying :59:60 on an analog clock!).
They all get back in sync eventually, though.

That's a nice CHU capture. Thanks for sharing it.

/tvb
http://www.LeapSecond.com

- Original Message -
From: "Richard Langley" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, January 04, 2006 08:04
Subject: [LEAPSECS] Diagram of CHU Leap-Second Recording and "Atomic" Clock


> I recorded the audio of the 3330 kHz signal of the National Research
Council
> of Canada's time signal station CHU from a few minutes before, until a
couple
> of minutes after, midnight UTC on New Years' Eve. A PDF of the annotated
> sampled-signal time series between 23:59:00 and 0:00:01 can be found here:
> . The leap second
was
> correctly inserted. However, starting one minute after UTC midnight, DUT1
> became +0.4 seconds rather than +0.3 seconds as prescribed by IERS. The
+0.4
> second value continued to be transmitted until some time on 3 January
2006.
> According to an NRC staff member, the problem arose because the IERS
Bulletin
> D announcing the +0.3 second value was not sent out until 28 December and
> was not seen until people returned to work on 3 January after the
holidays.
> This problem seems to have occurred with some other time signal stations
too.
>
> Simultaneous with the audio recording of CHU, I videotaped the display of
a
> SkyScan "atomic" clock, model 31981, marketed by Equity Time U.S.A., which
> receives the WWVB signal. It did not account for the leap second at UTC
> midnight. Likely it continued that way until it next tried to receive the
WWVB
> signal.
>
>

===
>  Richard B. LangleyE-mail: [EMAIL PROTECTED]
>  Geodetic Research Laboratory  Web: http://www.unb.ca/GGE/
>  Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142
>  University of New Brunswick   Fax:  +1 506 453-4943
>  Fredericton, N.B., Canada  E3B 5A3
>  Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
>

===

Re: Longer leap second notice

[Rob Seaman]

Hi Warner,


A more apt comparison would be to the leap year rules that we
have.  We know the rules going
forward a thousand years or so.


Apt indeed.  Leap seconds are scheduled at least six months in
advance.  That's about one part in 15 million.  A thousand year
horizon for scheduling leap days is one part in 365,250.  So we're
already doing 50 times better than Julius Caesar and Gregory XIII.


These too represent the fact that the oribit arount the earth is
not exactly 365.25 days.  We add leap seconds because the rotation
of the earth isn't exactly 86400s.


As the solar day lengthens, of course, it will influence calendrical
issues as well.  As has been asserted in the past, changing UTC to
eliminate leap seconds also changes the definition of the "day".


Daylight savings time is something else entirely.  It is a
political decision that sunlight is better used in the evening than
the morning.


These effects are all connected in the generation of a civil date and
time at any given moment in any given location on (or "near") the
Earth's surface.


Twenty years is an example number.  Ideally, as predictive science
gets better, we can do it for longer periods of time.  One would
hope to eventually have a schedule that's published 50 or 100 years
in advance.


Look at Steve Allen's plots (http://www.ucolick.org/~sla/leapsecs/
dutc.html).  The scatter is implicit in the geophysics.  The real
world is inconvenient for some purposes, but that's what makes
science fun.


If we can extend the horizon from 6 months, then that would lead to
better predictibilty of leap seconds, and also allow for better
testing.

Of course, a rule that eliminates them entirely would also fit
these needs, but appears to have little support...


Little support - and again, to a certain level of precision (easily
better than a second per day), all parties must certainly agree that
civil time (as we know it) IS mean solar time.  I think we're all
willing to entertain off-the-wall suggestions - but that's what they
are - entertainment.

That said, the geophysicists have done a remarkable job improving
their predictions - look at a plot of the residuals between predicted
and observed UT1:  http://iraf.noao.edu/~seaman/leap/images/
BminusA.gif.  Would be delighted if that improvement were reflected
in better policies for UTC and civil time handling.


Multiple sources of information about leap seconds leads to a more
robust system.  GPS can tell us about it, ntpd can tell us about
it, and having a table of known leap seconds can inform us.  These
redundant sources of information act as a sanity check.


Can't argue with that - although ultimately a single well tied knot
is stronger than a tangle of slip knots and Grannies.  And even a
well built system - a supremely constructed knot - is subject to the
Alexander factor.  His sword violated the assumptions made by Midas'
father Gordius in tying the knot.


In brief, we have a leap second table.  This table can be populated
from a number of different sources, usually via a table we've hard
coded into our products.  As the products run and discover new leap
seconds, these are added to the table and the table is updated.
Since we parse a number of different data formats to get leap
second information (4 different GPS data types, peeking at the leap
indicator on ntpd, and recovering it from time signal such as
Loran), the system is expandable to allow any source of leap seconds.


Seems reasonable for a wide range of applications.  As I've said in
the past, I'm not driven by a love of leap seconds, per se, but by
the identification of civil time with solar time.  The issue of
triggering on a particular scheduled event is actually quite familiar
from other projects.  One that I'm working on at the moment is a
mechanism for conveying sky transient alerts (http://ivoa.net/twiki/
bin/view/IVOA/VoeventWorkshop2).  Another was a way to trigger an
even sun centered cadence of CCD exposures attached to a
spectrograph.  This consisted of taking >10,000 individual spectra of
a particular star (Procyon) on an even temporal grid extending over
several months.  The gimmick was that the clock had to be adjusted
for the changing light travel time across the Earth's orbit.  I won't
belabor the point (much), but it certainly is easier to build trust
in the correctness of such a trigger if the cadence is rapid, rather
than glacially slow.

Rob Seaman
National Optical Astronomy Observatory

Re: Longer leap second notice

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Rob Seaman <[EMAIL PROTECTED]> writes:
: On Jan 3, 2006, at 5:46 PM, Warner Losh wrote:
:
: > As someone who has fought the battles, I can tell you that a simple
: > table is 10x or 100x easier to implement than dealing with parsing
: > the data from N streams.  Sure, it limits the lifetime of the
: > device, but a 20 year limit is very reasonable.
:
: Simpler is indeed better - if it satisfies the requirements.  While
: we're at it - how about a table to describe worldwide daylight saving
: rules?  Oh right - we already have that :-)  What we don't have is a
: mechanism to force the U.S. Congress not to change the rules out from
: under us.  Retaining the flexibility to easily change the rules is
: one of our requirements.

You are comparing two dissimilar things.  A more apt comparison would
be to the leap year rules that we have.  We know the rules going
forward a thousand years or so.  These too represent the fact that the
oribit arount the earth is not exactly 365.25 days.  We add leap
seconds because the rotation of the earth isn't exactly 86400s.  The
difference between them is that the earth's rotation around the sun is
more stable than its rotation on its axis.

Daylight savings time is something else entirely.  It is a political
decision that sunlight is better used in the evening than the morning.

: Twenty years does seem reasonable.  Would suggest this might be
: marketed as an extended cadence maintenance requirement, rather than
: as an expiration date - suspect astronomers aren't the only ones to
: rely on 30 year old computers on occasion.  I would heartily agree
: with the notion that a twenty year horizon is about appropriate for
: expecting to reach any decision on the future of UTC.  We'd be a lot
: further ahead on this if a closed door decision hadn't been rushed
: for the imagined benefit of the few.  In the mean time, there are
: many members of the astronomical software community who would be
: happy to contribute to an effort to improve time handling
: infrastructure and standards, rather than spending their own precious
: time fending off ill conceived political machinations.

Twenty years is an example number.  Ideally, as predictive science
gets better, we can do it for longer periods of time.  One would hope
to eventually have a schedule that's published 50 or 100 years in
advance.  Leap years have been published far in advanced for thousands
of years now, with only one correction to the rule about 700 years ago
as the measurement of the year was refined.  As we've refined it
further in the last few hundred years, we know, with a very high
degree of confidence, that the rule is good for at least a thousand
years.  The rule isn't perfect, as almost a full day of error can
accumulate in 400 years (requiring an extra leap day), but it does
bound the error nicely.

If we can extend the horizon from 6 months, then that would lead to
better predictibilty of leap seconds, and also allow for better
testing.

Of course, a rule that eliminates them entirely would also fit these
needs, but appears to have little support...

: > If we could have a table for the next 20 years, there'd be no need
: > to even write the code to get from the GPS stream :-)
:
: And if latitude and longitude were engraved on every street corner,
: there would be no need for GPS at all :-)  Transport of time signals
: to remote locations is the whole point.

I think it would have been better if I'd stated my point more
directly: Multiple sources of information about leap seconds leads to
a more robust system.  GPS can tell us about it, ntpd can tell us
about it, and having a table of known leap seconds can inform us.
These redundant sources of information act as a sanity check.  In the
development box that did do the leap second correctly, a backup source
of infomration allowed it to perform correctly over the leap second
despite its development not being complete.

: But should any of us be open to persuasion by a "political tool to
: make the proposal go through without commiting anybody to anything
: for the next couple of hundred of years"?

There are a number of politically expedient quick fixes.  Foisting it
off on future generations is a time honored political solution :-(.

: > I find your dismissive attitude towards software professionals that
: > have implemented a complete leap second handling infrastructure,
: > with pluggable sources for leap second rather annoying :-(
:
: Indeed, I'm sure I've exhausted my scant store of good will again.

My statement was born of frustration.  It was a little uncalled for.
I regret sending it as it was a cheap shot.

: Would be delighted to hear more about your leap second infrastructure.

In brief, we have a leap second table.  This table can be populated
from a number of different sources, usually via a table we've hard
coded into our products.  As the products run and discover new leap
seconds, these are added to the t

Fwd: [LEAPSECS] Longer leap second notice

[Rob Seaman]

On Jan 3, 2006, at 5:46 PM, Warner Losh wrote:


As someone who has fought the battles, I can tell you that a simple
table is 10x or 100x easier to implement than dealing with parsing
the data from N streams.  Sure, it limits the lifetime of the
device, but a 20 year limit is very reasonable.


Simpler is indeed better - if it satisfies the requirements.  While
we're at it - how about a table to describe worldwide daylight saving
rules?  Oh right - we already have that :-)  What we don't have is a
mechanism to force the U.S. Congress not to change the rules out from
under us.  Retaining the flexibility to easily change the rules is
one of our requirements.

Twenty years does seem reasonable.  Would suggest this might be
marketed as an extended cadence maintenance requirement, rather than
as an expiration date - suspect astronomers aren't the only ones to
rely on 30 year old computers on occasion.  I would heartily agree
with the notion that a twenty year horizon is about appropriate for
expecting to reach any decision on the future of UTC.  We'd be a lot
further ahead on this if a closed door decision hadn't been rushed
for the imagined benefit of the few.  In the mean time, there are
many members of the astronomical software community who would be
happy to contribute to an effort to improve time handling
infrastructure and standards, rather than spending their own precious
time fending off ill conceived political machinations.


If we could have a table for the next 20 years, there'd be no need
to even write the code to get from the GPS stream :-)


And if latitude and longitude were engraved on every street corner,
there would be no need for GPS at all :-)  Transport of time signals
to remote locations is the whole point.


I know you aren't pursuaded by such arguements.


I'm prepared to be persuaded by complete, coherent proposals based on
real world (and real economic) concerns.

But should any of us be open to persuasion by a "political tool to
make the proposal go through without commiting anybody to anything
for the next couple of hundred of years"?


I find your dismissive attitude towards software professionals that
have implemented a complete leap second handling infrastructure,
with pluggable sources for leap second rather annoying :-(


Indeed, I'm sure I've exhausted my scant store of good will again.
It must be obvious that my intent was to come out swinging after the
leap second - just as the obvious intent of the folks pushing the
proposal is to use any reports of systems failing to appropriately
handle the leap second as fodder for renewing their efforts.  That
said, if there are such reports, let's hear them and get to work
together (for once).  (Some might consider me a software professional
as well - am not particularly annoyed if you do not.)

Would be delighted to hear more about your leap second infrastructure.

Rob Seaman
National Optical Astronomy Observatory

Diagram of CHU Leap-Second Recording and "Atomic" Clock

[Richard Langley]

I recorded the audio of the 3330 kHz signal of the National Research Council
of Canada's time signal station CHU from a few minutes before, until a couple
of minutes after, midnight UTC on New Years' Eve. A PDF of the annotated
sampled-signal time series between 23:59:00 and 0:00:01 can be found here:
. The leap second was
correctly inserted. However, starting one minute after UTC midnight, DUT1
became +0.4 seconds rather than +0.3 seconds as prescribed by IERS. The +0.4
second value continued to be transmitted until some time on 3 January 2006.
According to an NRC staff member, the problem arose because the IERS Bulletin
D announcing the +0.3 second value was not sent out until 28 December and
was not seen until people returned to work on 3 January after the holidays.
This problem seems to have occurred with some other time signal stations too.

Simultaneous with the audio recording of CHU, I videotaped the display of a
SkyScan "atomic" clock, model 31981, marketed by Equity Time U.S.A., which
receives the WWVB signal. It did not account for the leap second at UTC
midnight. Likely it continued that way until it next tried to receive the WWVB
signal.

===
 Richard B. LangleyE-mail: [EMAIL PROTECTED]
 Geodetic Research Laboratory  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142
 University of New Brunswick   Fax:  +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
 Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===