In message E1DpRhd-0000xo-4o@febo.com, "Doug Hogarth" writes:

It also means that the attempt to prevent leapseconds before they
do more damage failed...

It even means we get to see how much damage they'll make...

--
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.

From: "Poul-Henning Kamp" phk@phk.freebsd.dk
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Mon, 04 Jul 2005 20:09:26 +0200
Message-ID: 30913.1120500566@phk.freebsd.dk

Hej Poul-Henning,

Would the alternative be much better?

Considering how "off" some systems are in time, a leapsecond more or less will
not make much of a difference.

Cheers,
Magnus

In message 20050704.201627.95841762.cfmd@bredband.net, Magnus Danielson write
s:

Lets not restart that discussion :-)

--
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.

From: "Poul-Henning Kamp" phk@phk.freebsd.dk
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Mon, 04 Jul 2005 20:19:28 +0200
Message-ID: 31000.1120501168@phk.freebsd.dk

Hej Poul-Henning,

I kindly asked for your opinion. I know there have been debates on this, but I
haven't followed them and whatever solutions I have seen all have downsides
that I don't think is an improvement. In the end, I think this might be a
bicycle-stand discussion in which there is no real right answer, we just need
to select one of them and stick with it for better or worse.

I think there is a bigger problem that people have not got used to UTC
coordination of system events than the problem of leap-second insertion.
When I come to think of it, people can't even write dates in a fashion that
you know what they mean (not saying that there is only one format, but when
they get mixed...).

Cheers,
Magnus

bought

The way I figure it if Lance Armstrong can have
one more shot at the Tour de France before he
retires then we can have one more leap second
before they are retired. ;-)

The most recent leap second (1/1/99) occurred
in the middle of the Y2K, telecom, dot-com, and
internet bubble and didn't bother anything. But as
we have discussed elsewhere, a lot of technology
has since been built that has never seen a leap
second. Then again, most of that technology doesn't
care. When in the future something like an iPod
needs to know UTC to a fraction of a second, then
we really don't want to have leap seconds.

/tvb

View a Leap Second - December 31, 1998
http://www.leapsecond.com/notes/ls-wwvb-98.htm

In message 20050704.204026.56945047.cfmd@bredband.net, Magnus Danielson write
s:

My opinion was rather forth and back, until I read (yet another) article
about colonizing Mars.

It just doesn't make any sense for an astronaut on Mars to adjust
leap-seconds.

And btw, it probably would not even be a leap-second for him, since
general relativity would take its toll.  I'm not sure my grasp of the
math is good enough to figure out how long his leap-second would be.

Instead, if we abandon leap-seconds, then we finally have a truly
universal timescale.

It will not be locked to any more or less random piece of geophysics,
anyone with a cesium clock and a set of gen-rel coordinates will be
able to figure out what time it is, and time intervals can be measured
and compared without weird gottchas.

Yet it would still be a good enough approximation for the 99% of
the population to not notice any difference for the next half
millenium and if we find out we want to keep the sun "near south
at noon" we can jump timezones to do so with 100 years of advance
notice.

The other half is that leap-seconds are just not testable in a computer
setting, and therefore I am sure that any cost of dropping them will
be totally offset by the savings in the IT industry.

Poul-Henning

--
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.

From: "Poul-Henning Kamp" phk@phk.freebsd.dk
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Mon, 04 Jul 2005 21:02:35 +0200
Message-ID: 31556.1120503755@phk.freebsd.dk

No. You are missing a detailed refinement in the definition of a second, it is
assumed that the Cesium clock is at sea-level. The reason being that due to
Einsteins relativistic theory, the gravity potential will also pull the speed
of the clock, and this have indeed been verified with Cesium clocks. For
instance, the GPS satellites have their clocks set slightly low before launch,
since when they reach orbit their frequency as we view it will be different.
So in this context the leap-second doesn't really add much trouble. It is
already adapted to the world we live in and matches many sigmas of our needs.

Also, the Cesium atoms is assumed to be at 0K, so anything but that is an
approximation.

Considering how time-zones is set, I start to wonder. Look at the time zones
in South America and you see what I mean.

I am not even sure that the IT industry is really spending a whole lot on this
issue. Most of them is to the best of my knowledge fairly ignorant to this
among other problems. Just having charging systems track UTC through NTP would
be a huge step forward IMHO.

Cheers,
Magnus

At 03:02 PM 7/4/2005, Poul-Henning Kamp wrote...

If that is to be the case, then we should move to decimal time, instead of the awkward 60/60/24/365.x we have now, for the same reasons the metric system has been applied to other measurements.

What sense does it make for an astronaut on mars to keep 24 hour days? Why not make the second 10^9 Cs transitions, instead of 9,192,631,770?

Fact is, time measurement is based on geophysics, and the absence of leap seconds wouldn't make it "universal" in any way. That being the case, it is not unreasonable to keep it properly aligned. Leap seconds have been around long enough that any IT system which can't accommodate them is poorly designed.

You've clearly not dealt with many such system then if you are going
to make such sweeping statements.  It is HARD to design systems to
be perfect around leap seconds.  I'd grant you that most systems
likely operate correctly given that leap seconds exist, but I'm less
sure they all work perfectly when a leap second happens.  It has been
5 years since the last one and even well written systems haven't been
tested by fire.

Leap second complicate things in hundreds of little ways.  As someone
who has to write software that deals with leap seconds on a daily
basis, I can tell you it makes it more expensive to write and debug
and more prone to weird failure cases.  phk's point isn't that the IT
industry can cope.  It is that if they didn't have to cope, things
would be a lot cheaper.  He's right about that given the number of
hours that I see devoted to designing for leap seconds; arguing about
how, exactly, they work; understanding the subtle implications of such
simple rules; setting up expensive simulators to test the leap
seconds; etc, etc, etc.  The truth of the matter is that there's a
very real cost to leap seconds.

Warner

At 04:42 PM 7/4/2005, Warner Losh wrote...

Your sweeping statement is wrong.

There are many costs to keeping accurate time, this is just one of them. If it's not worth the cost, than the value isn't there, so don't bother. There's obviously no cost if the system doesn't need one second accurate time (i.e. an alarm clock).

Much the same can be said of leap years (or more correctly, days).  The mechanics are similar Feb 28>Feb 29>Mar 1 is fundamentally no different than 23:59:59>23:59:60>00:00:00, it's just adding to the appropriate count on an exception basis. The only difficulty is communicating the need and keeping track, since they occur "randomly." There is a mechanism in place for the former, and the latter isn't particularly difficult.

If leap seconds were to be done away with, at what point do things get re-synchronized, if at all? When we're off a minute? hour? day?, and how is accommodating for that "randomness" any different?

Sounds like asking for the Julian calendar problems all over again.

At 05:16 PM 7/4/2005, M. Warner Losh wrote...

Which I didn't deny and in fact pointed out. (Although the current system of leap years has been around less than 500 years, not thousands.)

You would apparently delay the issue for someone in the future to deal with, at which point they would curse you, just as we in the late 1990's cursed those who thought 2 digit years were sufficient. There were significant numbers of systems that were fortunate that the year 2000 followed a meta-meta-exception to the "4 year" leap year rules, and therefore did things "correctly," despite doing so for the wrong reason.

Civil time (i.e. the time most people actually use) is more valuable in every sense than any/all analytical timekeeping. There is a very real need to keep civil time in proper order. Those who keep analytical time chose to base their measure on civil time. It therefore behooves them to adapt and not demand that the tail wag the dog.

At some point, civil necessity demands that the "randomness" be addressed, whether the systems are allowed to slip 1 second, 1 minute or 1 hour (I note you DID NOT answer the very real question of how large that slip should be allowed to be). Eliminating leap seconds does absolutely nothing to resolve the real issue, it only postpones the need to deal with it. I submit it's better to do it now, correctly, than simply postpone the issue for someone else to deal with. Having once created systems which can handle leap seconds at arbitrary times (not even limited to twice yearly as is current convention), the problem is resolved, "forever."

From: "M. Warner Losh" imp@bsdimp.com
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Mon, 04 Jul 2005 15:16:26 -0600 (MDT)
Message-ID: 20050704.151626.55342255.imp@bsdimp.com

Actually, the Gregorian calender (with leap-days) was introduced in 1603, so we
have (just) 400 years of experience with it. Also, the leap-days have been
predictable so far, but the frequency correction is not quite right, and the
long term frequency drift will require a change in the system eventually.
But, for the near-term future (expected lifetime of software we write now), you
are most probably right. There was a great article PTTI a few years back on the
earth rotation issue if I recall correctly.

There are a number of systems which do have the flaw that they are unable to
give UTC-TAI or for that matter UTC-systemtime (such as GPS) which is indeed a
flaw in the system and anyone implementing anything relating to it will suffer
(as you do). Some systems or signals do not even support leap seconds, some
have changed and indicate them. In a general sense it is a mess.

Cheers,
Magnus

In message 20050704.212118.87245102.cfmd@bredband.net, Magnus Danielson write
s:

Sea-level on this planet, yes.

If you are on a different planet in a different orbit and a differnet
rotation period (and axis!), general relativity takes a toll.

If you bring a HP5071A to Mars, it will give you a wrong length of
seconds.

Just look at Europe :-)

Well, I think the disruption is obscured by the lack of implementation.
As more systems implement leapseconds (through NTP or otherwise) we will
see more applications which didn't do it quite right.

--
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.

In message 6.2.3.4.0.20050704161512.03eb37b8@mjs.alientech.net, Mike S writes
:

See, that on the other hand would benefit anybody at all.  Scientists
already have the JMD decimal timescale for such needs, and most people
are able to implement the conversion correctly.

Because 10^9 is no less a magic number than 9,192,631,770.

And remember, the human circadian rythm is roughly 24 hours, (Mars'
rotational rate is close enough btw) you really don't want to
mess with that.

If we took a vote, then there would be 100 times more badly implemented
IT systems than systems which needed the alignment, and the average IQ
of the people doing the alignment requiring systems would be 20 points
or more higher than the people who mess up the IT implementations.

It just doesn't make sense to put the hard problem to the less bright
and larger population.

--
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.

In message 6.2.3.4.0.20050704164921.03e4bc68@mjs.alientech.net, Mike S writes
:

The very very very real difference is that I know centuries ahead
that feb29 3004 will be there, but I didn't know about 20060101-005960
until two days ago.

I can only support Warners notion that you have no idea.

--
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 02:37 AM 7/5/2005, Poul-Henning Kamp wrote...

I had expected better than ad hominem attacks on this list. I'm disappointed in this, and will take it as a clear indication that the poster is unable to rationally defend his position.

From: "Poul-Henning Kamp" phk@phk.freebsd.dk
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Tue, 05 Jul 2005 08:29:44 +0200
Message-ID: 33697.1120544984@phk.freebsd.dk

Hej Poul-Henning!

Whatever sea-level on this planet is. It's not at the sea-level at all. You
have to measure the gravity and compensate for that to some constructed and
standardised sea-level. The gravity and sea-level maps of the earth is
interesting to study and when you think of it in this context you really start
to wonder. There are pretty accurate gravity instruments that are among other
things used to measure when vulcano bursts is due to happend and stuff like
that.

Indeed. There is an 24 hour cycle which is due to the shift in gravity position
relative to the sun as the earth turns. The amplitude is however quite small
and I'd guess that the temperature shifts from the same cycle makes larger
influence on most clocks.

Relativity bites you many times when trying to do this.

The Universal in UTC is to indicate our world, the earth, and not to be
confused with the universe as in deep space. It was never meant to include
Mars for instance.

I try not to! ;O)

Which is a better wording of my point. ;O)

When different IT systems can be off by minutes (I have received the reports
about that some telcos have this problem for instance) I think there are a
bigger issues to handle first.

But, Werner is bringing out a very important point, if you do care about
doing it right, you need to do it properly and that involves caring about many
different things, including the relative brokenness of many systems and the
consequence when the systems missalign. Some of the systems could potentially
be fixed thought. NTP with the propper patches on kernel and software in
general will indeed solve parts of the problem, at least in the UNIX world.

Cheers,
Magnus

Maybe being a newbie, means staying out of the way of giant..  well
I'll take the chance of embarrassing myself...

Magnus Danielson cfmd@bredband.net writes:

A common definition, iirc, is some epoch of sea-level in the Rotterdam
harbour. From this starting point, MSL is simply the altitude where
the geopotiential has the same value as the "zero-point". MSL is often
called the geoid as opposed to various ellipsoids. One of the most
used ellipsoids are ofcause the WGS84 ellipsoid that GPS uses.

There are elaborate models of the geopotentials, where the potential
is expressed with spherical harmonics. (GEMxx, JGM-S, EGM96S etc)
With coordinates for your Cs you should be able to compute the
geopotential (gravity) potential quite good! Would you be able to
measure the error the usage of a good model gives you? If you go into
real details, you need to measure continously, since the continents
are moving and there is landrise (&fall).

What is the gain of having yet another expensive instrument, when
there are good models that can be fed with position/altitude.

There are relativistic time scales for such use. TT - time measured by
surface earth clocks. Geocentric coordinate time (TCG) - time wrt
center of Earth. Barycentric coordinate time (TCB) - time wrt center
of solar system.

Going to Mars you will supposedly end up relating your Cs to TCB and
then transform back and forth to TT to compare with measurements from
earth clocks.

I am sure there are listmembers who are knows relativity and its time
applications and can explain more, and maybe tell me if I completely
failed to understand.

--

Björn

In message 6.2.3.4.0.20050705063104.040869b0@mjs.alientech.net, Mike S writes
:

Mike, taking things out of context is a silly way to argue.

I think I defened my position rationally in my first post, which I sent
against my better judgement because Magnus asked for it again.

The reason for my better judgement is that these discussions
invariably turn into a screaming/flaming/hate match between people
like Warner and myself who have actually had to spend too much of
our life dealing with the real-world issues that leap-seconds cause,
and people on the other side which have a very thin grasp of what
life is like in the murky corners of the IT departments and real-world
life-critical installations.

Which was the context, no amply proven, of the line you took out of
context.

You really have no idea Mike...

--
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.

In message 20050705.124646.08659276.cfmd@bredband.net, Magnus Danielson write
s:

I know, but I didn't even want to add all that complication :-)

"universal" was used in the meaning of "the entire known world", and what
happened is that this got one moon larger and expansion to another planet
is now feasibly in reach.

A redefinition to make UTC still fit the creeping meaning of the word
"universal" seems very appropriate to me :-)

I can see on my stratum 1 server how far off some clocks are when systems boot,
you'd be surprised.

For the longest time, a very famous Swiss maker of precision timepieces
had a web-server which were years out of whack if you examined the HTTP
headers :-)

Actually, that's the depressing thing, UNIX doesn't fix it orderly with
NTP, it just pastes over the problem :-(

--
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 09:51 AM 7/5/2005, Poul-Henning Kamp wrote...

If you really believed that, you would not have disingenuously trimmed context from my earlier post by removing the text which directly addressed the argument you then made.

No, you didn't. What you and Warner HAVE demonstrated is that you chose the wrong time coordinate system for your systems/applications. Instead of using TAI, which doesn't have leap seconds, you chose to use UTC, which does. You're now arguing that the single differentiating factor between UTC and TAI should be removed to resolve issues cause by your poor choice. You've offered nothing in the way of rational argument as to why that should happen, except that it would be convenient for YOU. That is not rational.

This again? I predict Godwin's law will shortly need to be invoked.

In message 6.2.3.4.0.20050705100343.0412ac70@mjs.alientech.net, Mike S writes
:

This made me laugh...

Ohh, how I wish I were in a position to tell POSIX: "Sorry, the
time_t definition is wrong (and useless), fix it now please!".

Heck, I would even love get the Danish parliament to fix the law
from 18mumble so it doesn't define legal time as "the mean solar
time of the observatory in Copenhagen".

But Mike, I live in the real world.

Out here in the real world people with little grasp of fine details
write specifications for turn-key systems which they belive will
solve all their problems.

The systems must use common-off-the-Shelf components for vendor
independence, follow all applicable standards, official, industry
and corporate.

And be delivered within budget, on-time, fully debugged and
documented.

And I won't even mention the uniform 3 second upper limit on
response time or the requirement to use OS/2, Oracle and VisualBasic,
(somebody from the golfclub probably recommended that).

When you point out the mistakes and misunderstandings, legal will
tell you that the specifications can not be changed "for contractual
reasons".

If you insist, legal briefs the Mgt and your project leader will
receive a memo from them saying merely: "Annex 9 shall happen as
written."

Two years down the road, the customer will tell you "If only
you had told us!" and sales will call it an "opportunity" and
thank legal for preventing the programmers from screwing up
our profit yet again.

This, Mike, is where the real cost of leapseconds are booked.

And you have no idea...

--
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 10:40 AM 7/5/2005, Poul-Henning Kamp wrote...

POSIX time was (originally) designed with the assumption that it could/would be reset to track UTC. You're trying to use it for something it was never intended to provide. time_t works perfectly well for the vast majority of systems, i.e. those who didn't choose to make use of it beyond it's design. POSIX time is suited for tracking time monotonically by simply not attempting to maintain synchronization with UTC/Civil time. That's TAI (possibly with a fixed offset). Your choice, your problem. If you want to sync with the standard NTP hierarchy, NTP Autokey and ntp_gettime() are available, both of which handle leap seconds.

I'm not the one arguing that others should address his self-created problem. Thread over. You lost.

From: "M. Warner Losh" imp@bsdimp.com
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Tue, 05 Jul 2005 09:44:46 -0600 (MDT)
Message-ID: 20050705.094446.31252443.imp@bsdimp.com

The main problem is that you can't directly get the UTC - TAI difference,
right? If you had that, then you could always convert between them. There is
however a peculiarity of which I am sure you are aware of, you would still
need to know when the leap-seconds occured when doing time-differances over
possible leap-second insertion points. TAI(t2) - TAI(t1) may not be equalent
to UTC(t2) - UTC(t1).

Video synchronisation is going UTC, but I pointed out that all sampling rates
etc. is actually following TAI and not UTC. At least they chose to coordinate
them when TAI = UTC which is a good start. They failed to identify the time-
zone in which they where coordinated, which is another story, so their trial
publication of the standard got one comment and they had to re-write those
parts since they where plain wrong. Ah well. I still wonder if they finally got
it all correct, since my attention was diverted away from it.

Cheers,
Magnus

At 11:44 AM 7/5/2005, M. Warner Losh wrote...

If it's not one system, it's another. As I said, you (the collective you - your organization) chose to use UTC. The need to maintain both UTC and TAI, and deal with leap seconds, is purely an issue internal to your organization. Perhaps your users have a real need for time closely correlated to UT/GMST, in which case stopping UTC leaps seconds would do them a disservice. You're trying to make UTC into something it isn't.

In message 6.2.3.4.0.20050705104502.03fbb9d8@mjs.alientech.net, Mike S writes
:

Wrong, hopefully, and yes, (since I have to do the work).

--
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.

From: "Poul-Henning Kamp" phk@phk.freebsd.dk
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Tue, 05 Jul 2005 16:40:54 +0200
Message-ID: 35307.1120574454@phk.freebsd.dk

Hej Poul-Henning,

OUPS! <quick Google search on POSIX time_t> BUT IT IS BROKEN!!!!
However, the ISO C standard has it (more) right.

Now I learned something.

Haven't this been discussed with the POSIX people?

Some neighboring countries have aligned their normal and summer time as
offsets to UTC in law, with the shift between them coordinated with the EC.
Yes, you should have the Danish parlament moving in that direction.

In some buissnesses that works, in some it doesn't. There is ways to train the
management, but it takes time and patience. After letting the management learn
from expensive experience that some advice is best taken rather than overruled,
things get more on track.

Cheers,
Magnus

In message 20050705.185014.52960352.cfmd@bredband.net, Magnus Danielson write
s:

"Yeah, we know, we know, but it's too late to fix it now..."  :-(

The law has been "in preparation" ever since the meridian conference
in Washington 1873 (or thereabouts).

--
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.

That's the crux of the matter.  With leap days, I know when to insert
one for the next thousand years or so.  With leap seconds, I have no
clue.  Not only that, I have no way to know the number of leap seconds
that have happened between now and when the device was made unless I
have some communications mechanism to the outside world to tell me.

Yes.  that's the t1 - t2 problem that I'm talking about.  And the
answer should be identical in both cases (because the leap seconds
actually did happen).  The math is a lot easier if it is all done in
TAI since you don't have to worry about leap seconds complicating the
math.  Or the possible ambiguity that representing a UTC as a single
number can bring with it.

Warner

A number of things:
(1) I never said we should stop leap seconds.  I said there's
a huge cost associated with them.
(2) UTC is an externally imposed requirement.  Our users have
different needs for things, but UTC is a standard, and
we must provide it.
(3) It is called UT1 these days.
(4) Time is delivered from GPS as week number, second in
week.  The GPS time scale isn't TAI, but yet another one
that is needed.  While it also gives a GPS UTC offset in
its data stream, that can cause big delays in startup on
some GPS receivers while the almanac is downloaded.

Why do you refuse to accept the fundamental message I'm telling you,
based on my first hand experience:

Leap seconds have a huge cost associated with them, and they
insinuate themselves into many areas one might not naively
have thought of.

Warner

From: Warner Losh imp@bsdimp.com
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Tue, 05 Jul 2005 10:58:32 -0600 (MDT)
Message-ID: 20050705.105832.74677930.imp@bsdimp.com

Warner,

What we really would need is an ISO-8601 like fashion to indicate the UTC-TAI
difference that the time was given in. So, even if a device have the wrong
UTC-TAI offset, you would be able to correct for it. However, that one should
have been in place ages ago to be useful.

Another useful thing would be a function that returns the UTC-TAI difference
at a given time.

As long as you convert your UTC measurement into the correct TAI that is.

I have noted that many UTC time signals only indicate that an leap second is
comming, instead of giving the difference. Loosing the history isn't nice, and
recovering from it may be less than trivial naturally.

BTW. I compared the wording in the description for time in ISO-C (1999) and
POSIX (latest online), and there is a peculiar difference between them,
supporting both camps. The POSIX reading only says it shall give the number of
seconds as the EPOCH. This means following TAI with no leap seconds. The ISO-C
reading states that it shall return the calender time, which could be
interprented as following UTC. However, then there is gmtime which both have
which should be used.

Anyway, I'm refreshing some neurons here and adding a few more connections
while at it.

Cheers,
Magnus

At 01:05 PM 7/5/2005, Warner Losh wrote...

Well then, the cost argument goes away - it is simply a cost of doing business. TAI is also a standard.

Don't be pedantic. The point is that there are organizations which depend upon a time coordinate system which is closely linked to astronomical time. UTx/xMST, whatever.

Why do you refuse to recognize that eliminating leap seconds from UTC has huge costs to other organizations? If you're required to use UTC because of regulation, then your costs are just a part of doing business. If you're not supporting the elimination of leap seconds from UTC, then your posts have no purpose unless your're just looking for a little sympathy.

UTC was specifically intended to follow astronomical time closely, that is the only significant way it differs from TAI. That some regulators require you to use it is no reason to change it's fundamental nature. Work on changing the regulations instead of breaking something which is working as intended.

At 01:28 PM 7/5/2005, Magnus Danielson wrote...

While it can't rewrite history, look at NTP autokey, which can automatically distribute the information necessary to keep things right. ( http://www.eecis.udel.edu/~mills/leap-seconds.3169152000 ) Also see libtai ( http://cr.yp.to/libtai.html ), which does those calculations. TAI64 also fixes the 2038 problem.

ntp_gettime(), at least for the current time. By using libtai, the calculation for any given time should be trivial.

In message 6.2.3.4.0.20050705132358.03fa8218@mjs.alientech.net, Mike S writes
:

Where are these alleged costs documented ?

All I've seen yet is from various astronomers who have hedged their
bets with a "I want a brand new instrument" estimates...

And even adding all those guestimates up, I bet you that the DoD
will spend more time on personel this coming new years day than the
sum of your costs.

Get a grip on the scale of things, will ya ?

--
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.

Nobody want TAI.  Nobody.  Everything is done in terms of UTC in the
time and frequency business.

Don't be pedantic. The point is that there are organizations which

I'm sorry, but all the time issues is about being pedantic.  If you
can't be pedantic, you will make mistakes.

The main argument for elimination of leap seconds is that the
astronomy folks that want UT1-UTC < 1s can adapt more cheaply than the
rest of teh world dealing with unpredictable, random leap seconds.  It
is important to know exactly what you are talking about.

I could reduce the cost of doing business by eliminating them.  I've
not been arguing for their elimination in this thread.  I've just been
providing data to show that they have a real, unseen cost.  It is my
belief that the cost of everybody doing leap seconds is much higher
than the astronomers just coping with UTC/UT1 drifting apart.

UTC was intended to be a civil time.  It was thought that it would be
best if it followed astronomical time.  Maybe that fundamental thought
is just wrong.

Over the next few hundred years we'll have several problems with leap
seconds.  As the rate of the earth slows, we'll need them more and
more.  Somewhere near 2072 the UTC-GPS offset will overflow 7 bits.
Somewhere in the next hundred years we'll need more leap seconds than
we can do by doing 2 per year.  For long range analysis of these
effects, you can look at
http://www.ucolick.org/~sla/leapsecs/dutc.html to see that there will
be increasing problems with leap seconds as we move forward and the
earth's rotation continues to slow.

Warner