It seems to me that there are two sides to this argument.
Those who want to keep broadcast UTC pretty closely in sync
with the various flavours of UT and those who don't want to
deal with leap seconds for day-to-day applications which
don't care about that link.
We could drop leap-seconds from UTC, thereby fixing the offset
between UTC and TAI. This would mean that UTC would slowly
drift away from UT. It has been suggested that this would
result in people having to get up in the middle of the night
or whatever but another way of looking at it would be to say
that the meridian of UTC slowly drifts round the world.
Therefore, it would be necessary to change the offsets of
LCT (local civil time) from UTC. Most of the world already
does this anyway twice a year for daylight saving time. The
effect of dropping leap seconds from UTC would be that every
few thousand years it would not be necessary to apply one of
the daylight saving time switches - thereby permanently
changing the offset between UTC and LCT by an hour. This
doesn't seem like a big deal.
On the other hand, if leap seconds were dropped from UTC then
it would be necessary to define a new time scale which
approximates UT1, or perhaps better in the long run, make
widely available accurate differences between UTC and UT1.
This would require some re-engineering which might be a bit
of a problem.
Since dropping leap seconds would result in short term
engineering problems and a long term drift of local civil times
vs local solar times I think we ought to think carefully before
making such a change.
When writing day-to-day software we don't want to be worried by
leap seconds. For example, I am about to add a time stamping
feature to transactions in a specialized accounting package. It
would be ridiculous over engineering for me to put in special
code to worry about being in second 60 of a minute.
Therefore, I'd like to add my support for Markus Kuhn's UTS
suggestion:
http://www.cl.cam.ac.uk/~mgk25/uts.txt
For most applications setting the computer's clock from the
operator's watch every week or two is just fine. So long as,
as far as the application is concerned, the clock runs at
roughly one second per real second (however defined) and is
monotonically non decreasing it's good enough.
It doesn't even matter if the clock goes backwards for an
hour (end of daylight saving time) as long as the application
system is not running at the time. If that does matter then
you'd better use UTC or UTS rather than local civil time.
Sometimes you want the clock more accurately set - say to a
second or two. In that case you'd set it using NTP or
whatever. If this can't be done when the application
system is not running (e.g., because it needs to run all
the time) then you want to make sure that the corrections
are applied smoothly - speeding the clock up or slowing it
down as required.
If you really need multiple systems to be in sync to the second
or better then I think Markus's idea is an excellent solution -
effectively it standardizes this smooth correction. For most
applications for which UTC is currently used (e.g., most amateur
astronomy) UTS will do just as well as UTC (after all, if you
don't care about the difference between UT1 and UTC then you
probably don't care about that between UTC and UTS. Calculating
UT1 from UTS is only slightly harder than calculating it from
UTC).
UTS is particularly useful for systems where points in time
are stored as a number of seconds since some epoch. Not
having to worry about leap seconds means that minutes are
always multiples of 60 seconds, hours 3600 and days 86400,
etc. Very helpful for quick formatting.
Occasionally, you really need to know how long something
took in proper SI seconds. Then you need a suitable function
to find this - taking into account the history of leap seconds
over the interval. This is needed for either UTC or UTS,
just the details change slightly between them.
What this function would need is an easily accessible list of
all past, present and so-far-defined future leap second
date/times.
It should be in a very distributed database with local
servers well known to all networked computers and accessible
via a very lightweight protocol, ideally a single UDP
interrogation packet and a single UDP response packet.
The database system should have a mechanism whereby it is
possible to ensure that local servers get up-to-date
information from the central server when their current
data could be out-of-date. I wonder if the Domain Name
System can be {ab}used for this purpose.
I'm not familiar enough with DNS to work out the details
but something on the following lines might work. Define
a new top level domain "time" with the following sub-
domains:
count.leapsecond.utc.time
1.leapsecond.utc.time
2.leapsecond.utc.time
....
where "count" contains a record giving the count of the number
of leap seconds which have so-far been defined in UTC and 1, 2,
3, etc contain records giving the UTC date (and possibly time)
of the leap second, whether the leap second is inserted or
deleted and, ideally, the UTC-TAI offset following that leap
second.
Use of a new TLD isn't essential, of course. This little
zone could sit in any suitable existing domain. Maybe the
.arpa domain which currently contains the .inaddr sub-domain
for reverse IP address lookup. Or maybe simply usno.navy.
mil or some other suitable host. The record type could be a
specially defined one or the existing TXT record could be used.
Perhaps there should be sub-domains in the leapsecond domain
for each year or each decade to avoid having to make too many
queries if information for a specific interval is required.
DNS records have a TTL (time to live) field which indicates
how long they can be cached. Obviously, the individual defined
leapsecond records can be cached forever. The TTL on the count
record should be set as far ahead as it is known that the
next leapsecond will not be defined. As the decision date
gets closer the TTL should be decremented until an announcement
is made (i.e., IERS Bulletin issued).
Other information like historical and planned civil time offsets
from UTC (for daylight saving time) could also be stored.
Any thoughts?
Ed Davies
Received on Wed Dec 04 2002 - 14:46:26 PST