Re: UTC - A Cautionary Tale
Those of you on the LEAPSECS mailing list will aready have seen this,
but I think its worth a read -
http://www.startribune.com/stories/404/5508732.html
I'm responding to Rob and Mike in this email.
First, Rob said
And if your software reports eclipses later than 2007, it may need to
be updated again. Where is the surprise in this? You have built a
program that makes certain assumptions about time - those assumptions
are invalid. Your program could have been layered on TAI. Your
program could have referenced one of the online sources of leap
second tables (ftp://maia.usno.navy.mil/ser7/tai-utc.dat). Your
program could have permitted input of an explicit leap second
schedule at a later date. Your program could have done a lot of
things to be responsive to the standard. If a standard exists and
you ignore the standard, you can't blame the folks who designed the
standard for your problems. For example, what does your program do
to correct for DUT1? DUT1 will be growing without bound if the
proposal is adopted. It will become a larger and larger effect to
compensate for.
Leap seconds exist now. UTC uses them now. You chose to ignore an
international standard that applies now. I'm glad to see you were
perceptive enough to manually correct the problem, but it sure looks
like it's your problem to me, no matter what you think of leap
seconds.
First of all, there is no surprise. Second of all, my program could not
be layered on TAI - why? Because TAI is not available to the average
user! The average user only has access to UTC, and so that is what I had
to use. (Internally, I use TDT, but I need to know the number of leap
seconds to convert TDT to UTC). Third, I could not access online sources
of information - many mobile phones don't have the infrastructural
capability to access and parse on-line sources of information. Forth, of
course DUT1 is also a problem for me, but it is a problem that is
significantly less important than leap seconds. A 0.9 second error in
DUT1 corresponds to a 0.1 second error in the observed time of an
eclipse on the equator (the worst-case scenario). Finally, of course I
could have implemented something whereby the users of the program had to
manually insert the number of leap seconds, but I SHOULDN'T HAVE TO!
As a general citizen of the world, I am APPAULED that astronomers can
tell when an astronomical event years from now will occur to within a
fraction of a second, but they cannot tell me what time will be on my
watch at that time!
There is interval time and there is time-of-day. There are a number
of other timescales as well. What is difficult to forecast is the
relationship between TAI and UT1.
And, between TAI and the time that is on my watch. This is, IMO, insane!
Jean Meeus's discussion:
http://www.ucolick.org/~sla/leapsecs/onlinebib.html#Event2005-07-08
(I'm sure anybody with your avocation is familiar with Meeus.)
I am indeed very familiar with Meeus. However, Meeus seems to have set
his sights a bit low. If I'm reading him correctly, Meeus wants to
publish his predictions in UT, saying that its close enough to UTC and
hence the time people keep on their watches. However, no-one can predict
UT into the far future. If, on the other hand, civil time were to be
based on a quadratic equation in TAI, it could be predicted far into the
future, and hence Meeus and others would be able to publish PRECISE
lists of astronomical events far into the future safe in the knowledge
that if there are no changes to the quadratic equation, their
predictions would show PRECISE clock time for those events.
On the other hand, what you are saying doesn't remove the need for
lookup tables. Either the lookup tables are needed to move from a
civil time based on UT1 to TAI or they will be needed to move from a
civil time based on TAI to UT1.
There is no solution that can simultaneously eliminate lookup tables AND
involve UT1. My solution isn't interested in UT1 - it is interested in
an approximation of UT1 that is accurate over the long term (hundreds
of years, maybe thousands), though may drift (possibly horribly) over
the short term. The vast majority of people are not that worried about
drifts that would (apparently) horrify the subscribers to this list!
My fundamental assertion is that at
the end of the day it will be proven that most usages of civil time
depend on its nature approximating time-of-day rather than
unsegmented interval time.
Agreed! But my approach achieves both! (At least, to within many parts
per million - which is far more accuracy than most people are interested
in).
So I may have to update my eclipse-predicting program within a
month of
the eclipse? I don't think so.
But that is the international standard already in effect.
Unfortunately.
Nothing
stops the IERS from issuing a leap second the month before any
eclipse you care to reference. We should emphasize this by making it
the rule, not the exception.
I strongly disagree. As I said, I'm appauled that I have to depend on
some bureaucratic scientists in France before I can issue useful,
accurate eclipse predictions. (By "useful", I mean predictions that are
based on the time people have on their wristwatches).
And we and other interested parties
should spend our time developing systems that provide the APIs and
services you need to embed in your application.
I can see where you are going with this. Unfortunately, I cannot see
such APIs working on mobile phones, or on electromechanical clocks for
that matter.
By attempting to ignore an intrinsic reality, we are making such
issues more likely, not less. How about an extension to ISO 8601
that would permit distinguishing timescales, something like:
2005-07-18T12:34:56Z (UTC)
2005-07-18T12:35:28A (TAI - same instant)
I would be very much in favour of that if TAI were made as easily
available to the general public as UTC. Unfortunately, most broadcast
time services are set up to broadcast just one timescale, and pretty
much all clocks display just one timescale, and that timescale is UTC,
and is unlikely to change!
Multiple timescales will always exist. We should acknowledge that
fact and move on.
leap hours are 3,600 times more absurd!
Common ground has been reached.
Phew! :)
Mike said
Please be consistent. You said:
[...]
Which means either the interval calculation is based on TAI, and is
exact, or it is an estimate based on solving quadratic equations.
Since you very specifically referred to it as an estimate, it must be
the latter.
OK - let's go through this step-by-step (and apologies to the rest of
the list).
The problem is to determine the time interval, in SI seconds, between
two instances in time (a very common problem). And we are comparing the
results of doing that calculation using two different timescales.
The rules are those of "simple arithmetic". You are not allowed to use
lookup tables, and you are not allowed to use quadratic equations. You
are in a hotel, without access to your normal sources of reference,
without access to a calculator, sitting down with someone, doing a
calculation on the back of an envelope.
The first timescale is UTC. A UTC second is of the same duration as an
SI second, but it has leap seconds. The time interval you are required
to calculate is from 2005 Dec 31 23:59:59.9 and 2006 Jan 01 00:00:00.1.
Under the rules, you come up with an answer of 0.2 seconds. The actual
answer is 1.2 seconds. You are out by a factor of 6.
The second timescale is one that is tied to TAI by a quadratic equation.
It has no leap seconds, but the duration of its second varies in
relation to the SI second. At present, its second differs from the SI
second by about one part in 30 million. The time interval you are
required to calculate is a different one from the one above, even though
it looks the same - namely from 2005 Dec 31 23:59:59.9 and 2006 Jan 01
00:00:00.1. Why is it actually a different time interval? Because it is
in a different timescale. The answer you come up with is 0.2 seconds.
You are out by about 1 part in 30 million. You have an answer that is 8
orders of magnitude better than the UTC one.
Of course, this example brings out the worst in UTC - most calculations
involving time periods of less than a year will generate the precisely
correct answer in UTC, and an answer that is always wrong by 1 part in
many millions in the other timescale. My point is that most people are
not interested in precision of 1 part in many millions (see the article
linked-to above), and the benefit of not having to use lookup tables is,
I think, worth the cost of one part in many millions precision.
And, from the point of view of programming, quadratic equations are
much easier to implement than look-up tables.
That depends entirely on the platform. That would not be the case on a
microcontroller lacking hardware floating point.
Not true - floating point can be implemented in software. Also, to the
precision of the numbers you are using, it is not that difficult to do
quadratic equations using integer arithmetic.
Not if you have mislaid the piece of paper that has the damn lookup
table on it.
Myself, I would store such information in electronic form so it was
directly accessible to the program, but suit yourself.
Myself, I like not to depend on electronic equipment that needs
power/batteries/costs lots of money/can get stolen/can get mislaid.
Yes. Leap seconds are absurd enough, leap hours are 3,600 times more
absurd!
You forgot to extrapolate that statement to leap days.
Leap days are extrapolatable for the next 1,000 years at least. There
are very simple, precise, integer arithmetic algorithms for dealing with
leap days. There are no such algorithms, and cannot be any such
algorithms, for leap seconds.
At 05:56 AM 7/19/2005, Chris O'Byrne wrote...
The rules are those of "simple arithmetic". You are not allowed to use
lookup tables, and you are not allowed to use quadratic equations. You
are in a hotel, without access to your normal sources of reference,
without access to a calculator, sitting down with someone, doing a
calculation on the back of an envelope.
How is it you happen to be in a hotel during a leap second, have access to precision time but no calculator, yet have to calculate a time interval by hand to 1 second precision with no reference materials, and for what purpose?
It wasn't clear you had based your argument on a bunch of unnatural, unstated qualifications. It's always possible to argue a manufactured exception, but it's the generalized case which applies most broadly.
In message: 20050719105613.47749a7a.obyrne@iol.ie
"Chris O'Byrne" obyrne@iol.ie writes:
: > >Yes. Leap seconds are absurd enough, leap hours are 3,600 times more
: > >absurd!
: >
: > You forgot to extrapolate that statement to leap days.
:
: Leap days are extrapolatable for the next 1,000 years at least. There
: are very simple, precise, integer arithmetic algorithms for dealing with
: leap days. There are no such algorithms, and cannot be any such
: algorithms, for leap seconds.
OK. For leap years, we know from 1500ish until ~4000 (assuming they
change it) the rule will be:
if (y % 4 == 0) && (y % 100 != 0 || y % 400 == 0))
leap-year
else
not-leap-year
This gives a mean year that's very close to the actual mean year. By
not having a leap year in the year 4000, 8000, etc, I believe that it
arrives at an even close answer, but that hasn't been promulgated as a
standard.
Give me something like that for leap seconds and I'll be happy.
Note, we don't try to constantly adjust each year by having 1/4 of a
leap day every year to keep things within a 1/2 of day. By the forth
year, we're almsot a full day off, and we accept this as the cost of
doing business without so much as a second thought. We don't worry
that each year we accumulate a little bit of error that means 1 year
in a hundered (typically) we have to omit a day. We should do
something similar with leap seconds. The number of people that care
that DUT1 is off by more than 0.5 is tiny. DUT1 can be as much as a
half minute off and lots of people won't know and won't care.
Astronomers are already applying offsets in lookup form, so they can
easily cope with a larger variation. If we can predict what the
earth's rotation will do over the next 10 or 100 years, we should
schedule leap seconds NOW so that we come up with the right answer
at the end of that time. Sure, DUT1 may wander more than a second
off, but I can't believe that we don't possess the ability to be
within 10s during the next 100 years. That's a lot better than just
letting it drift, and it gives good determanism to those programs that
might not have access to leap second information once they are
deployed. It also bounds DUT1 to a value that is still somewhat
useful to all but the most demanding of users with the benefit that
most users won't care and will be able to implement their time systems
more cheaply. Compromise is necessary here, and extremists on both
sides are likely to be disappointed.
As someone who has actually implemented many systems based on TAI, I
can tell you that you MUST know about ALL leap seconds in order to
implement things using TAI correctly. Nobody directly distributes
TAI, and users want times displayed in UTC. Leap seconds cause lots
of problems, especially when devices are turned off for long periods
of time and leap seconds happen in the interrum (think spares that sit
on the shelf for years). Their randomness needlessly complicates
things. Having them gone, or replaced by a schedule announced years
in advance will help greatly.
Most people can easily tolerate standard midnight being as much as 30
minutes off from local midnight and not have it bother them. Surely
most people can tolerate a world where DUT1 is bounded to 10s rather
than 1s, and those that can't can get corrections.
Warner
In message 20050719.085848.10965548.imp@bsdimp.com, "M. Warner Losh" writes:
In message: 20050719105613.47749a7a.obyrne@iol.ie
OK. For leap years, we know from 1500ish until ~4000 (assuming they
change it) the rule will be:
if (y % 4 == 0) && (y % 100 != 0 || y % 400 == 0))
leap-year
else
not-leap-year
This gives a mean year that's very close to the actual mean year. By
not having a leap year in the year 4000, 8000, etc, I believe that it
arrives at an even close answer, but that hasn't been promulgated as a
standard.
I was actually wondering about that -- does the pope still "own"
that standard/definition ?
DUT1 can be as much as a
half minute off and lots of people won't know and won't care.
Experience with daylight savings time and timezones indicate that
it can be two hours off and people still survive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
At 06:38 AM 7/20/2005, Poul-Henning Kamp wrote...
Experience with daylight savings time and timezones indicate that
it can be two hours off and people still survive.
That's a red herring.
DST isn't applied to UTC.
DST and timezones offset time by a fixed, well defined amounts. As long as a time properly labeled, the same information exists as if UTC were used.
I suppose you believe that DST makes the day longer, too.
In message 6.2.3.4.0.20050720070453.034a3eb8@mjs.alientech.net, Mike S writes:
I suppose you believe that DST makes the day longer, too.
No Mike, but I belive some crania are to thick to make it
worth arguing with the inhabitant.
Welcome to my kill file.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
At 07:39 AM 7/20/2005, Poul-Henning Kamp wrote...
In message 6.2.3.4.0.20050720070453.034a3eb8@mjs.alientech.net, Mike S writes:
I suppose you believe that DST makes the day longer, too.
No Mike, but I belive some crania are to thick to make it
worth arguing with the inhabitant.
You misspelled the word "too" in your self-referential statement. HTH! HAND!
In message: 6.2.3.4.0.20050720070453.034a3eb8@mjs.alientech.net
mikes@flatsurface.com (Mike S) writes:
: I suppose you believe that DST makes the day longer, too.
Clearly, the extra hour of daylight will burn up the crops!
Warner