Thanks to all for the excellent discussion - over the past five years
I've seen much less diplomatic discussions on the issues. It has
never bothered me that folks hold a diversity of opinions on UTC -
time is a deeply interesting subject worthy of our best efforts. Any
solution(s) worth implementing must be able to withstand
confrontation with withering criticism. Here is another discussion
as to why the proposal to simply halt leap seconds is failing to
survive such criticism:
http://www.cl.cam.ac.uk/~mgk25/time/leap
Markus Kuhn also has a proposal for how to handle leap seconds cleanly:
http://www.cl.cam.ac.uk/~mgk25/uts.txt
Others (here also) have proposed similar time-slicing mechanisms.
It is inevitable that time standards will remain a perpetual focus
for international discussion. This does not worry me. What worries
me is an attempt to sweep time once-and-for-all under the rug. This
cannot possibly succeed and we will regret it - sooner, rather than
later. I have my own suggestion for how to handle civil time - since
rare events are harder to handle or to test, make them occur more
frequently:
http://iraf.noao.edu/~seaman/leap
Comments on specific issues raised:
I said:
Straightforward algorithms (a few lines of C) can convert
standard time to local time and mean time to apparent time.
Robert Lutwak replies:
It ain't "...a few lines." Properly dealing with timezones,
daylight savings, and leapseconds can easily run into thousands of
lines of code, by the time you include of of the oddball
irregularities around the world.
Note that I said LST -> LMT and LMT -> LAT. The boundaries of
timezones and the varying rules of daylight saving weren't
mentioned. On the other hand, on any given date, TZ and DS could be
expressed in a few tens or hundreds of kbytes worldwide. The biggest
complication is that particular nations, provinces or states can
change these rules at any time. You want to lobby to simplify time
handling procedures, work to implement an international standard for
these, don't muck with leap seconds.
As far as LST -> LMT -> LAT, the proposed abandonment of time-of-day
means that these currently simple closed form algorithms will become
as complicated and subject to error as timezone/DS handling is
currently.
Poul-Henning Kamp says:
"Ignore this planet".
No comment.
Bill Hawkins says:
Yes, the Arabians have 15 minute increments for local time jumps.
I don't see thousands of lines of code to do that.
Arizona (where I'm located) has no daylight saving (the last thing we
need to save is daylight) - except that the Navajo's do have DS (the
reservation overlaps Utah and New Mexico and presumably they want to
keep synchronized) - except that the Hopi reservation (completely
surrounded by the Navajo) do not have DS.
Just a reminder that 21st century time standards must continue to
support a wide cultural diversity.
M. Warner Losh says:
(2) Leap seconds can be both positive and negative
We don't have leap seconds because the Earth is spinning down. We
have leap seconds because the Earth has already spun down relative to
the 19th century epoch when the length of the second was codified.
(The definition of the second has changed, but not its size.) This
is precisely why leap seconds are quadratic over long periods of
time. And this is why a negative leap second is extremely unlikely
(and becoming less so) - not only would the Earth have to spin up, it
would have to spin up enough in a year or two to counteract more than
a century of accumulated slowing.
Robert Lutwak says:
I'd say y'all are underestimating the power of adaptive evolution.
No comment.
M. Warner Losh says:
I forgot to add that in between 1200 and 2100 years the current
interneational standard of one leap second per month will be
insufficient to accomidate the drift. So talking about what
happens in 10,000 years is already well beyond the current
standards, so something *HAS* to change before then...
Yes, over the long term we have a worthy challenge to address - I
hesitate to say "solve" because I don't think a simple solution will
suffice. We should be addressing a viable long term time handling
strategy, not looking for an easy way out. And the current standard
provides hundreds of years to discuss the issues.
Poul-Henning Kamp says:
I just don't see how anything should break because of missing leap
seconds.
Absence of imagination is not evidence of absence.
The only way this can happen is if you use your time against an
object which is not terrestial: Ie: you are an astronomer.
Many programmers are troglodytes - but that doesn't mean that the Sun
doesn't exist. Time-of-day is solar time. There are many natural
and man-made solar system objects that we depend on every day. The
orientation of those objects with respect to locations on Earth is
often important. The orientation of objects on Earth with respect to
solar system objects is often important. (Often can be defined in
terms of how frequently leap seconds are likely to adversely affect
other systems.) Forget about those pesky stars, galaxies, quasars
and other cosmic chaff.
But the most cost efficient solution is to redefine UTC, rather
than trying to reeducate people who have already ones failed to
understand the topic.
If the failure is educational, the solution must be educational.
Cost is not the only parameter that must be optimized. Trying to
optimize cost without handling performance and schedule (to name two
other parameters) is likely to ultimately result in the cost
ballooning out of control.
Bill Hawkins says:
The Moon does not cause leap seconds. That effect is measured in
milliseconds per century.
The Moon *caused* leap seconds (was the largest effect in the
lengthening the day since the 19th century). Let's see - back of the
envelope: lunar tides cause the day to lengthen 20 seconds every
million years. This angular momentum is transferred to the moon's
orbit. Laser reflectors left by Apollo show the orbit will grow 20
miles in a million years. Every second's increase in the length of
the day is bought by moving the moon a mile farther from Earth. On
the other hand, leap seconds are the result of aggregating
millisecond differences in the length of the day over several hundred
days.
Chris (O'Byrne?) says:
Not even the venerable NTP will cause my computer to say "23:59:60".
I workon a widely used astronomical image processing package (http://
iraf.noao.edu). IRAF defines a sexigesimal value as a floating point
number (typically a double). Wherever a floating point value can be
supplied, a sexigesimal value is acceptable. We have a %h printf
directive that provides the reverse conversion. As with similar
situations, the rule is to be strictly compliant when writing a value
(printf minute and second fields are bounded less than 60), but
loosely compliant on reading. These are perfectly legal values on
input: 25:00:00, 23:60:00, 23:00:60, etc. Just thought you might
find this technique useful.
Bottom line:
Every year or two (or seven) we have the opportunity to tweak civil
time to more accurately reflect time-of-day. During the intervening
months, civil time provides an excellent standard equalling TAI
+offset. If a project requires time-of-day, it can currently simply
use civil time. This is very handy. If a project requires
unsegmented interval time, it can use TAI directly - or it can
correct UTC at the end points. Your choice.
The proposal on the table does not eliminate the underlying
requirement for civil time to track time-of-day. Rather, it simply
denies the roughly annual (or strictly monthly as I argue at my link
above) *opportunity* to resynchronize civil time and time-of-day. If
we continue leap seconds past 2007-12-21, we will have another chance
to revisit that decision within a year or two (or maybe seven). On
the other hand, if we switch to a scheme absurdly claiming to
correspond to "leap hours" - we will have no opportunity to cleanly
revisit the decision for hundreds of years.
Time requires our best efforts - not those deemed by a few to be most
expedient.
Rob Seaman
National Optical Astronomy Observatory
_______________________________________________
time-nuts mailing list
[email protected]
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
