Re: [LEAPSECS] Calendrical Calculations

[Tony Finch]

On Sun, 28 Dec 2008, Zefram wrote:
>
> The numerical algorithms are correct, as far as I can see, but the
> descriptions of the underlying theory are often muddled, riddled with
> errors and critical omissions. (Count how many different quantities go
> by the name "RD".)  Rather importantly for our purposes, CC ignores the
> existence of timezones (or, for that matter, longitude).

A lot of the book is only concerned with labelling days, so it's a
legitimate simplification to ignore time of day. However they do take some
care to explain the simplification and how it relates to the way different
calendars choose different times of day to change their dates.

The rest of the book is concerned with modelling observational calendars,
and for those it does require a more detailed idea of time of day and
location, including longitude. There is also a brief discussion of time
zones, which are mostly used when converting civil time at a place to
universal time for use by the algorithms.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
FITZROY SOLE: SOUTHEASTERLY 5 TO 7, OCCASIONALLY GALE 8. MODERATE OR ROUGH.
RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Cheating means more planning, not less

[Tony Finch]

On Sun, 28 Dec 2008, Rob Seaman wrote:
>
> And I really will spare folks my other screed on civil timekeeping
> having nothing to do with local apparent solar time.  Since everybody
> seems to agree on this point, I'm not sure why it keeps coming up.

I don't agree. I think the sun in the sky is what people actually care
about, and the astronomical details are irrelevant for practical purposes.
Civil time needs to be within a couple of hours of local solar time. The
differences between mean solar time and apparent solar time are too small
to matter - in fact the variation of sunrise matters much more than the
variation of midday.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
SOUTHEAST ICELAND: SOUTHWESTERLY 4 OR 5, OCCASIONALLY 6 IN NORTH, VEERING
NORTHERLY 6 LATER IN NORTH. MODERATE, BECOMING ROUGH AT TIMES. SHOWERS, SNOW
LATER IN NORTH. MODERATE OR GOOD, OCCASIONALLY POOR LATER IN NORTH.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

[LEAPSECS] And now, your moment of FAIL

[Brian Garrett]

Let's hope your cesium clock's nine-digit display isn't showing what this 
banner does come Dec. 31:

http://www.nytimes.com/2008/12/28/weekinreview/28vinciguerra.html


Brian___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Cheating means more planning, not less

[Tony Finch]

On Sun, 28 Dec 2008, Poul-Henning Kamp wrote:
>
> In contrast to this, nobody, including you, seem to be willing to
> even hazard a guess what level of presision is required or sufficient
> for the "earth orientation clock".

Well we obviously need to know earth orientation to quite high precision
in order for satellite navigation to work, which implies that we know UT0
to fairly high precision - the surface rotates about 1m every 2ms. However
I doubt we need this information for setting our clocks.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
ROCKALL MALIN: SOUTHEASTERLY 4 OR 5, INCREASING 5 OR 6, OCCASIONALLY 7 IN
ROCKALL. SLIGHT OR MODERATE, OCCASIONALLY ROUGH IN SOUTH ROCKALL. RAIN OR
SHOWERS. MODERATE OR GOOD.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Schedule for success

[Nero Imhard]

Late reaction. Was still in my outbox. The current discussions are  
sufficiently annoying to send it anyway:


On 2008-12-23, at 09:43, Poul-Henning Kamp wrote:


The rest of us have no trouble with a tolerance of up to (at least)
one hour, because that's what is already the reality for 99.9..%
of the population.



I'm still looking for the "poster boy" reason for your 1sec tolerance
claim.


You don't need such a reason. It's up to the people (ITU?) who want to  
change an existing definition to make their case. "Although we hear  
protests, we don't see any objection we deem valid" doesn't quite cut  
it, does it?


I still don't get why you are insisting that UTC could be changed. To  
get rid of leap seconds in broadcast time scales, switching to  
something like TI would buy you your solution AND will not upset  
anyone using UTC. As for civil time, it's up to *legislators* to  
decide what civil time should be. Most have chosen (a derivative of)  
UTC, quite probably because it follows UT. Overriding such a decision  
by changing the reference frame is foul play.


What keeps bothering me is that the prospect of *changing a  
definition* (of UTC) doesn't seem to make you (phk) blink at all. A  
stated property of UTC is that it follows UT to within one second, and  
changing UTC in this respect is an insult to its users. It is  
betrayal, and undermines the timescale's authority.


If leap seconds are bugging you, then change you choice of time scale.

N___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Cheating means more planning, not less

[John Hein]

Poul-Henning Kamp wrote at 22:30 + on Dec 29, 2008:
 > http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm

Love that site.  Steve's and Tom's sites (among others) come in handy,
but that one made me laugh.

John - lurker
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] rubber seconds in Japan!

[Tom Van Baak]

100 of them, just before the leap


This is essentially the same technique as Markus Kuhn's UTC-SLS (UTC
with Smoothed Leap Seconds), but over a shorter period.  One might well
suppose that if they'd heard of UTC-SLS then they'd have used it, and so


I think we covered this back when we debated UTS.

The idea of speeding up and slowing down ticks to handle leap
seconds (or other timing discontinuities) is not new. It is one of
several practical ways to avoid a clock reading :59:60. It's also
not unlike how a PLL works.

The problem with UTC-SLS, last I read it, was that it demanded
a smoothing factor of 1000. This rate change is unnecessarily
high for many applications and unacceptably low for others.

One can imagine perfectly workable smoothed leap second
solutions using not just 1000, but instead 100, or 1024, or 60,
or 30, or 10, or 2, or 1/2. Or if you're perverse, 86400.

In every case it is simply a trade-off between the magnitude of
frequency excursion and the duration of smoothed leaping event.
Some systems have frequency limits; others may have time limits.
There is no one solution, nor should there be. There may also be
hardware considerations. For example, if a 32 kHz-based clock
were to re-synchronize smoothly it would be more convenient to
use a binary factor like 16 or 1024 rather than a decimal factor
like 100 or 1000.

I like their centisecond solution. Do we have anyone from Japan
on the list -- it would be nice to add a recording of this event to
my leapsecond collection.

/tvb
http://www.LeapSecond.com




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Cheating means more planning, not less

[Poul-Henning Kamp]

In message <3326254a-dd7a-40e6-a014-3958344aa...@noao.edu>, Rob Seaman writes:

>My apologies for the long reply.

No apologies for the short reply.

http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] rubber seconds in Japan!

[M. Warner Losh]

In message: <20081229200904.gq2...@fysh.org>
Zefram  writes:
: Steve Allen wrote:
: >100 of them, just before the leap
: 
: This is essentially the same technique as Markus Kuhn's UTC-SLS (UTC
: with Smoothed Leap Seconds), but over a shorter period.  One might well
: suppose that if they'd heard of UTC-SLS then they'd have used it, and so
: this is probably an independent invention.  Presumably they're working
: with the same objective: to provide a timescale that usually matches UTC
: exactly but also does not violate the fixed 60-seconds-per-minute model.
: 
: Interesting that they're only doing that for some users (those connecting
: by copper, apparently).  Users connecting by fibre get a visible (well,
: audible) leap.  Assumptions about the precision required by different
: classes of user?

I imagine that the fiber folks derive their clock from the fiber
carrier frequency, which can't be off by 1e-2.  The usual specs for
those start closer to 1e-12...

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] rubber seconds in Japan!

[Zefram]

Steve Allen wrote:
>100 of them, just before the leap

This is essentially the same technique as Markus Kuhn's UTC-SLS (UTC
with Smoothed Leap Seconds), but over a shorter period.  One might well
suppose that if they'd heard of UTC-SLS then they'd have used it, and so
this is probably an independent invention.  Presumably they're working
with the same objective: to provide a timescale that usually matches UTC
exactly but also does not violate the fixed 60-seconds-per-minute model.

Interesting that they're only doing that for some users (those connecting
by copper, apparently).  Users connecting by fibre get a visible (well,
audible) leap.  Assumptions about the precision required by different
classes of user?

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

[LEAPSECS] CHU frequency change

[Brian Garrett]

This may be old news, but anyone listening for the leap second (or using CHU as 
a time reference) needs to be aware that the transmission on 7335kHz is going 
away as of 2009-01-01.  Apparently, the leap second will be 7335's last.

They will still be broadcasting on three frequencies, but 7850 kHz will replace 
7335.  If receiving the leap second broadcast over CHU is important to you or 
your boxen, you'll want to choolse 3335 kHz or 14670 kHz instead.

Source: 
http://inms-ienm.nrc-cnrc.gc.ca/time_services/shortwave_broadcasts_e.html


Happy leaping,
Brian Garrett___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

[LEAPSECS] rubber seconds in Japan!

[Steve Allen]

100 of them, just before the leap

http://www.yomiuri.co.jp/dy/national/20081230TDY03104.htm

--
Steve Allen WGS-84 (GPS)
UCO/Lick ObservatoryNatural Sciences II, Room 165Lat  +36.99855
University of CaliforniaVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Cheating means more planning, not less

[M. Warner Losh]

In message: <20081229165202.gp2...@fysh.org>
Zefram  writes:
: Richard B. Langley wrote:
: >How accurate
: >are the predictions (especially the long-term ones) really?
: >One would have to compare
: >one of the historical empirical functions with actual UT1 data.
: 
: We discussed this in 2007-01 in a thread titled "UT1 confidence".
: No firm answers were forthcoming regarding present IERS capability.
: 
: PHK noted that the accuracy estimation formula in Bulletin A gives
: unbelievable results if applied to periods of decades.  We don't know
: how far out that formula, or the DUT1 estimation formula, are intended
: to be applied.

Yes.  I think he said that they worked well out about 10 years, but
that we should graph the actual vs historical predictions to make
sure...

: Steve Allen pointed at some interesting papers, of which the most relevant
: was .  This paper
: looks at (retrospectively) predicting UT1-TAI two and three years ahead,
: and how well those predictions match reality.  These predictions were
: made with a fairly naive algorithm, which in the short term performs
: much more poorly than what IERS does.  The three year predictions were
: all correct to within 1.0 s.

I'd note that Bullitin A data is available, and one could graph the
performance of different time lines vs actual over a period of the
last few years.  I was thinking of doing this data crunching myself,
but time has gotten away from me...

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Cheating means more planning, not less

[Zefram]

Richard B. Langley wrote:
>How accurate
>are the predictions (especially the long-term ones) really?
>One would have to compare
>one of the historical empirical functions with actual UT1 data.

We discussed this in 2007-01 in a thread titled "UT1 confidence".
No firm answers were forthcoming regarding present IERS capability.

PHK noted that the accuracy estimation formula in Bulletin A gives
unbelievable results if applied to periods of decades.  We don't know
how far out that formula, or the DUT1 estimation formula, are intended
to be applied.

Steve Allen pointed at some interesting papers, of which the most relevant
was .  This paper
looks at (retrospectively) predicting UT1-TAI two and three years ahead,
and how well those predictions match reality.  These predictions were
made with a fairly naive algorithm, which in the short term performs
much more poorly than what IERS does.  The three year predictions were
all correct to within 1.0 s.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Cheating means more planning, not less

[Richard B. Langley]

I think IERS Bulletin A might represent the current state of the art for 
predicting
Earth orientation. It is produced by USNO. Latest bulletin is here:
.
It provides a table of UT1-UTC values to the end of 2009. It also provides an 
estimated
function and its standard deviation that can be used to extend the table. How 
accurate
are the predictions (especially the long-term ones) really? One would have to 
compare
one of the historical empirical functions with actual UT1 data. Not sure if 
anyone has
done that recently. Perhaps Demetrios knows?
-- Richard Langley
P.S. For those wanting to refresh their memories on the details of the history 
of the
leap-second business, have a look at .

Quoting Rob Seaman :

> What exactly is the current state of the  
> art for predicting Earth orientation?  It is a shame that there are no  
> lurkers here who could answer that question.
===
 Richard B. LangleyE-mail: l...@unb.ca
 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/
===


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Cheating means more planning, not less

[Rob Seaman]

My apologies for the long reply.  The personal attacks reached a  
tipping point.  Others should feel free to skip this (as I'm sure they  
do all my messages :-)


Poul-Henning Kamp wrote:


Rob Seaman writes:

Just one comment.  The requirements for "timing applications" (of  
whatever precision) are distinct from the requirements for civil  
clock applications.


You seem to think "civil clock applications" is little old ladies  
walking to church once a week.


My parenthetical remark about precision seems to have been  
insufficient disclaimer.  Apologies for yet another Strother Martin  
moment.


That is one use case, yes.

But the real point I'm failing to communicate is simply the  
distinction between clocks and timers.  Since it is a truism that  
every thread on leapsecs has been discussed previously, you can find  
some insightful comments from folks like Steve Allen in the archives  
on this topic.  The two different types of timekeepers may previously  
have been referred to as clocks and chronometers.


A timer keeps interval time - highly precise, but perhaps only  
accurate in a relative sense.


A clock keeps Earth orientation time (or other fundamental reference)  
- accurate in an absolute sense, but not necessarily very precise.


The point is system engineering again.  The requirements for an  
interval timer are simply distinct from the requirements for a clock.   
They may overlap, they may not.  One or the other set of requirements  
may be more important for a particular application.


As all within reach of my keyboard surely know, I believe civil  
timekeeping to be fundamentally dependent on requirements pertaining  
to Earth orientation.  I am well aware that others here (where "here"  
is a place to be understood metaphorically, see Steven Pinker),  
believe that interval timekeeping requirements are more critical, at  
least since the invention of the computer.


In the statement above I was trying to separate the two in a  
noncontroversial way.  Apparently I failed.  Let's see.  Is the  
distinction clearer if I say that an egg timer and the "clock drive"  
of a telescope have different requirements?


Anyway, to resolve the requirements for such divergent applications, I  
have been recommending that well-known system engineering techniques  
be followed.  Techniques that are eminently applicable to situations  
in which diverse entrenched positions have been taken.  On the other  
hand, Warner, for instance, has simply suggested that one or another  
party steel themselves to lose.  If we assume somebody has to lose,  
then perhaps that will become a self-fulfilling prophesy.  I don't  
assume anybody has to lose.


In any event, UTC has always provided access to interval time much  
more precisely (milliseconds or better via radio signals, microseconds  
or better via NTP) than to Earth orientation time (0.9s uncorrected,  
0.1s corrected).  At any point have I suggested that interval time  
should be degraded?


Rather, the ITU is unilaterally proposing to dramatically degrade  
access to the Earth orientation related features of clocks worldwide.   
As I believe you should know by now, I don't appreciate this and have  
been trying to argue against it.  For some reason, this appears to  
upset you.  For some reason, the subject of the discussion keeps being  
changed.


Leap seconds are simply a facet of an engineering solution.  A  
different solution could involve other engineering choices.  The ITU  
is not pursuing a different solution, they have been relentlessly  
pursuing the destruction of the current solution.  I believe they have  
taken this path because they have skipped important steps of standard  
system engineering methodology.  Central to this is a rush to  
judgement, the familiar human quality of failing to explore the  
problem space sufficiently before seizing on a specific solution.   
Perhaps there is an evolutionary argument for this human behavior -  
something about fleeing lions on the savannah.  How do you say "look  
before you leap" in Danish?


Each problem has many solutions.  If we didn't have to keep fending  
off the ITU's "deliberations", we could flesh out some high priority  
use cases (on all sides), utilize these to discover the underlying  
requirements shared by those use cases, and dispassionately consider  
alternative solutions that have the likelihood of making everybody  
happier with the ultimate consensus.


This is not only a better decision pathway, it is most assuredly a  
pathway that will be traversed much quicker than the nine years that  
the ITU has squandered.


A modern passengerplane moves approximately 300 meters per second.   
Are you willing to to accept a +/- 300 meter tolerance on the radar  
track during final approach in Cat3 conditions, if you are on the  
plane ?


How much havoc do you think a one second difference makes in a  
modern robotic car-production facility ?  Have you ever wondered why  

Re: [LEAPSECS] Cheating means more planning, not less

[Poul-Henning Kamp]

In message <67c8553c-1504-495b-ac99-6e006e0cc...@noao.edu>, Rob Seaman writes:

>Just one comment.  The requirements for "timing applications" (of  
>whatever precision) are distinct from the requirements for civil clock  
>applications.

You seem to think "civil clock applications" is little old ladies
walking to church once a week.

A modern passengerplane moves approximately 300 meters per second.
Are you willing to to accept a +/- 300 meter tolerance on the radar
track during final approach in Cat3 conditions, if you are on the
plane ?

How much havoc do you think a one second difference makes in a
modern robotic car-production facility ?  Have you ever wondered
why the car industry is so interested in IEEE-1588 ?

Having to classify applications into "timing" and "civil" in the
first place is what brought us here.

A lot of people didn't know that their applications were "timing"
so they didn't add code for the leap-second-polka.

>The key issue is the stability of the civil timescale, not its  
>precision.  However, degrading the precision by 5 orders of magnitude  
>in one gulp seems rather...excessive.

Rob, we could take you a whole lot more serious if you didn't spew
bull-shit like this.

The earth is not going to jump 15 degrees of rotation on jan 2nd
2018, so any talk about "degrading precision by 5 orders of magnitude"
is disinginuous and deliberately misleading.

As has been well documented, it will take several hundred years
before the difference approaches an hour.

Second, the ITU proposal decentralizes the time-of-day vs. solar
position tolerance to national issue.

I think is very proper, considering the very different policies
adopted with respect to timezones (EU vs China for instance)
and different durations of sunrise/sunset (Van Mayen vs. Congo for
instance).

> Rather, the nine years spent ankle-biting at the ponderous  
> machinations of the ITU could have been better spent actually  
> discovering a full set of requirements for civil timekeeping.   

So Rob, why didn't you ?

Ankle-biting is the best description for your disinformation
campaign I have seen yet.

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs