### Re: A lurker surfaces

```Daniel R. Tobias wrote:
It's a few seconds off from TAI, isn't it?  It was synchronized to
UTC in 1980 (I think),

Yes.  The epoch for GPS time is 1980-01-06T00:00:00 UTC, which is
1980-01-06T00:00:00 GPS time.  Not having leap seconds, it effectively
tracks TAI, with the equation

TAI(GPS) = GPS + 19 s

TAI(GPS) generally stays within about 15 ns of TAI.

The GPS time signal uses a ten-bit count of weeks, which wraps every
twenty years, so the raw signal is ambiguous between, for example,
1987-05-20 and 2007-01-03.  They are, nevertheless, distinct points on
the GPS time scale.  I recall there being some plan for a new field in
the navigation message that would disambiguate them.

They probably should just have
used TAI if they wanted a time scale without leap seconds, rather
than ending up creating a different one.

Would have been nice.  Actually, since the only real significance of
GPS time is that it's part of the signal format, they could just as
well have picked an unconventional but space-efficient encoding (say,
32-bit count of seconds, wrapping every 4 Gis).  I think GPS time is
best viewed as an encoding of TAI(GPS).

-zefram

```

### Re: A lurker surfaces

```Magnus Danielson wrote:
TA(GPS) = GPS + 19 + C0

No, there is no TA(GPS).  TA(k) are distinct timescales that AFAICT
generally do not attempt to track TAI.  Presumably they are intended as
maximally stable frequency standards, not steering to maintain long-term
interval accuracy, like TAI itself.

[UTC-GPS time] = -14 s + C0,   [TAI-GPS time] =  19 s + C0, global
uncertainty is of order 10 ns.

The formula implied by this is

TAI = GPS + 19 s + C0

which can be readily rewritten as

TAI(GPS) = GPS + 19 s
TAI = TAI(GPS) + C0

the latter half of which is how the rest of Circular T works.  They
actually describe the corrections as UTC - UTC(k), but of course that's
the same thing as TAI - TAI(k).

-zefram

```

### Re: A lurker surfaces

```In message [EMAIL PROTECTED], Zefram writes:

Would have been nice.  Actually, since the only real significance of
GPS time is that it's part of the signal format, they could just as
well have picked an unconventional but space-efficient encoding (say,
32-bit count of seconds, wrapping every 4 Gis).  I think GPS time is
best viewed as an encoding of TAI(GPS).

I have been told by a person who should know better than to tell
me such things that the choice of timescale in GPS is the result
of unmitigated incompetence and the signal format is sheer stupidity.

The fact that the UTC offset is in the Almanac instead of the
Ephemeris means that almost all of the rapid response weapons cannot
be used for tightly timed attacks until they have been primed with
an almanac.

He talked about the transmissions of the almanac being staggered
between the satellites rather than in tandem, to reduce the mean-time
to capture UTC-delta, but I did not find out if this was reality
or plan.

I guess one could use the raw-dump message to the Oncore and
decode the almanac by hand to find out if this is the case.

He also said that the quote in my .signature was used more often
in Pentagon than he was comfortable with.

Poul-Henning
--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

```

### Re: A lurker surfaces

```On Tue, 2 Jan 2007, Steve Allen wrote:

And, yes, explaining all this is very hard.  It's not obvious to the
geek that the political and funding realities are more real than the
underlying physics, but that's the way the world works.

I've been reading The Measurement of Time by Audoin and Guinot, and one
of the things its history of time keeping makes clear is that a lot of the
improvements have been driven by cross-comparison of different measures of
time. At the moment UTC requires the keepers of atomic time and
astronomical time to work together, guaranteeing continued funding and
employment for both :-) If we were to move to a purely atomic foundation
for civil time, I wonder what effect that will have on the organizational
arrangements. Will there continue to be enough cross-checks to drive the
keepers of time to further improvements? Will geodesy be enough to
preserve the astronomers' jobs? I usually take a technical view of things
so this slightly meta way of thinking is unfamiliar to me...

(Audoin and Guinot seem to favour purely atomic time.)

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
FAIR ISLE FAEROES: SOUTHWESTERLY BECOMING CYCLONIC THEN NORTHWESTERLY 6 TO
GALE 8, OCCASIONALLY SEVERE GALE 9. VERY ROUGH OCCASIONALLY HIGH. RAIN OR
SQUALLY SHOWERS. MODERATE OCCASIONALLY POOR.

```

### Re: A lurker surfaces

```On Sun, 31 Dec 2006, Rob Seaman wrote:

But actually, I think we should call leap seconds what they are -
intercalary events.

Yes! I also liked Zefram's comment As a calendar, UTC is presently of the
observational variety.

http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg01367.html

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
BISCAY FITZROY: SOUTHWEST VEERING WEST 6 TO GALE 8, DECREASING 4 OR 5. ROUGH
OR VERY ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.

```

### Re: A lurker surfaces

```Ashley Yakeley wrote:
I'd like to see an elastic civil second to which SI nanoseconds are
added or removed. Perhaps this could be done annually: at the
beginning of 2008, the length of the civil second for the year 2009
would be set, with the goal of approaching DUT=0 at the end of 2009.

This was tried, between 1961 and 1972.  It sucked.  There is a big
problem with having two kinds of second in common use, especially with
such close values.  They get mixed up.  It is very convenient to have
civil days made up of SI seconds, even if the number of one in the other
has to vary in order to fit.

A technical issue: broadcast time signals are phase-locked with the
carrier, which is at some exact number of hertz.  If the time pulses are
every civil second, and that is now 1.00015 s (as it was in 1961),
it can't be synchronised with the (say) 60 kHz carrier that must still
have exactly 6 cycles per SI second.

The historical trend is towards using uniform time units.  It seems
curious now that when the atomic clock was invented astronomers opposed
calling it a time standard.  They wanted to keep the Earth's rotation
as the ultimate time, and accepted atomic clocks only as *frequency*
standards.

It is much like the ancient Egyptians (IIRC) making the transition from
sundials to water clocks.  They had always marked out hours on sundials
subtending equal angles, so the actual temporal length of the hours
varied over the course of the day.  When the water clock gave them
an independent time reference, they were horrified that its uniform
hours didn't match sundial hours.  Much technical ingenuity went into
mechanical modifications to water clocks to make them accurately emulate
what went before.

Actually I was going to suggest that everyone observe local apparent
time, and include location instead of time-zone, but I think that
would make communication annoying.

Yes.  It would be a big step backward.  Look up the history that led to
the adoption of standard timezones: it was prompted by the invention of
railways and telegraph.  The trend in this area is towards increasing
agreement of time over progressively larger geographical regions.
Projecting into the future, one can foresee the eventual abandonment of
timezones in favour of the universal use of Universal Time.

-zefram

```

### Re: A lurker surfaces

```
Zefram wrote:

...
The historical trend is towards using uniform time units.  It seems
curious now that when the atomic clock was invented astronomers opposed
calling it a time standard.

Well, it seems curious to everybody except Rob Seaman :-)

...
It is much like the ancient Egyptians (IIRC) making the transition from
sundials to water clocks.  They had always marked out hours on sundials
subtending equal angles, so the actual temporal length of the hours
varied over the course of the day.  When the water clock gave them
an independent time reference, they were horrified that its uniform
hours didn't match sundial hours.  Much technical ingenuity went into
mechanical modifications to water clocks to make them accurately emulate
what went before.
...

Nice analogy.

Ed.

```

### Re: A lurker surfaces

```Zefram scripsit:

Projecting into the future, one can foresee the eventual abandonment of
timezones in favour of the universal use of Universal Time.

I think that's over the top.  Bureaucratically it is just too annoying
if the large majority of people have a work shift that overlaps legal
midnight.

--
On the Semantic Web, it's too hard to prove John Cowan[EMAIL PROTECTED]
you're not a dog.  --Bill de hOra   http://www.ccil.org/~cowan

```

### Re: A lurker surfaces

```
On Jan 1, 2007, at 22:56, Steve Allen wrote:

Then let's improve the infrastructure for communicating the best
estimation of earth orientation parameters.  Then in a world of
ubiquitous computing anyone who wants to estimate the current
rubber-second-time is free to evaluate the splines or polynomials
(or whatever is used) and come up with output devices to display that.

This is fine, but leaves open the question of when 9:00am is here in
Seattle. And why not transmit rubber-second-time as well, where
technically feasible (such as over the internet)?

What is a good source of earth orientation parameters, btw?

--
Ashley Yakeley

```

### Re: A lurker surfaces

```  Then let's improve the infrastructure for communicating the best
estimation of earth orientation parameters.  Then in a world of
ubiquitous computing anyone who wants to estimate the current
rubber-second-time is free to evaluate the splines or polynomials
(or whatever is used) and come up with output devices to display that.

This is fine, but leaves open the question of when 9:00am is here in
Seattle. And why not transmit rubber-second-time as well, where
technically feasible (such as over the internet)?

The technical problem is that many timing systems aren't connected to
the internet.  They are at secure installations and they only have GPS
almanac data at their disposal.  And, no, they aren't likely to ever
be on the internet.  Any changes would have to be announced a long
time in advance, and GPS almanac would have to be updated to include

The second technical problem is that the length of a second is
implicitly encoded in the carrier for many of the longwave time
distribution stations.  10MHz is at SI seconds.  For rubber seconds,
things.

Also, GPS would have to remain in SI seconds.  The error in GPS time
translates directly to an error in position.  Approximately 1m/ns of
error (give of take a factor of 3).  Rubber seconds would require that
the rubber timescale be off by as much as .5s.  So GPS has to remain
in GPS time (UTC w/o leap seconds, basically).  That means that the
rubberness of the seconds would need to be broadcast in the
datastream.

Many GPS receivers put out a PPS.  This needs to be in SI seconds, or
a number of other applications break.  However, if one defined UTC in
terms of these rubber seconds, then the top of UTC second would be out
of phase with this PPS.  That breaks a lot of assumptiosn that rightly
assume that PPS is phase aligned to top of second.

The interval math in UTC that's hard today would be significantly
harder with rubber seconds.  But it is just software, eh?

In short, it is an interestingly naive idea that was tried in the
1960's and failed when there were only dozens of high precision time
users rather than the hundreds of thousands there are today.

The earth does not define the second any more.  At most, it defines
the day and the year.

What is a good source of earth orientation parameters, btw?

usno publishes several.

Warner

```

### Re: A lurker surfaces

```
On Jan 2, 2007, at 05:15, Zefram wrote:

A technical issue: broadcast time signals are phase-locked with the
carrier, which is at some exact number of hertz.  If the time
pulses are
every civil second, and that is now 1.00015 s (as it was in 1961),
it can't be synchronised with the (say) 60 kHz carrier that must still
have exactly 6 cycles per SI second.

The obvious solution is to transmit rubber time on a rubber frequency.

--
Ashley Yakeley

```

### Re: A lurker surfaces

```
On Jan 2, 2007, at 11:40, Warner Losh wrote:

The second technical problem is that the length of a second is
implicitly encoded in the carrier for many of the longwave time
distribution stations.  10MHz is at SI seconds.  For rubber seconds,
things.

At 1000ns, the carrier would drift by 10Hz. Surely the bandwidth is
big enough for that?

Also, GPS would have to remain in SI seconds.  The error in GPS time
translates directly to an error in position.  Approximately 1m/ns of
error (give of take a factor of 3).  Rubber seconds would require that
the rubber timescale be off by as much as .5s.  So GPS has to remain
in GPS time (UTC w/o leap seconds, basically).  That means that the
rubberness of the seconds would need to be broadcast in the
datastream.

GPS is TAI. I'm not proposing abandoning TAI for those applications
that need it.

--
Ashley Yakeley

```

### Re: A lurker surfaces

```
M. Warner Losh wrote:

GPS is also used for UTC today.  Many ntpd's are stratum 1 tied to a

I imagine two parallel time infrastructures, one synchronised to TAI,
the other to rubber mean universal time. Stratum 0 devices for the
latter would probably have to use radio.

So, sure, there's an infrastructure cost for a sensible time of day...

ntpd is UTC, by definition.

I wonder how easily NTP could be generalised to transmit different
timescales without too much confusion? Using different UDP port numbers
might be one option.

--
Ashley Yakeley

```

### Re: A lurker surfaces

```In message [EMAIL PROTECTED], Ashley Yakeley writes:
M. Warner Losh wrote:
GPS is also used for UTC today.  Many ntpd's are stratum 1 tied to a

I imagine two parallel time infrastructures, one synchronised to TAI,
the other to rubber mean universal time. Stratum 0 devices for the
latter would probably have to use radio.

This proposal is so patently badly researched that you should
the implications, technical, scientifically and legally.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

```

### Re: A lurker surfaces

```
Magnus Danielson wrote:

The detailed introduction of the frequency
corrections in various sources was different, and getting a coherent view of
where UTC actually where was difficult. Since then we have grown to depend on
UTC transmission to a higher degree than we did back then. Infact, for many
purposes our UTC transmissions is also there to get us SI second traceability
for a whole range of applications. If we brake the SI second in UTC a whole lot
of technology will break. Rubber seconds would be a plain nightmare to
introduce and maintain compared to the strange and slightly uncomforting dreams
we have with the current leap second scheduling.

If the list will forgive me for airily focussing on the ideal rather
than the immediately practical... we should keep TAI and UTC as they
are, but create a new timescale for civil time with a new name and its
it. UTC can then fade into irrelevance.

No, GPS is not TAI. GPS run its own timescale and it is offset from TAI by 19
seconds, as given in BIPMs Circular T 227:

I meant up to a known conversion. If you have some GPS time, you know it
for TAI, and vice versa. That's not the case for UTC, since you don't
know what the leap second offset will be if it's too far in the future.
Of course you can also extract UTC from a GPS signal.

--
Ashley Yakeley

```

### Re: A lurker surfaces

```From: Ashley Yakeley [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Tue, 02 Jan 2007 15:21:14 -0800
Message-ID: [EMAIL PROTECTED]

Ashley,

Magnus Danielson wrote:
The detailed introduction of the frequency
corrections in various sources was different, and getting a coherent view of
where UTC actually where was difficult. Since then we have grown to depend
on
UTC transmission to a higher degree than we did back then. Infact, for many
purposes our UTC transmissions is also there to get us SI second
traceability
for a whole range of applications. If we brake the SI second in UTC a whole
lot
of technology will break. Rubber seconds would be a plain nightmare to
introduce and maintain compared to the strange and slightly uncomforting
dreams
we have with the current leap second scheduling.

If the list will forgive me for airily focussing on the ideal rather
than the immediately practical... we should keep TAI and UTC as they
are, but create a new timescale for civil time with a new name and its
it. UTC can then fade into irrelevance.

I do not think it is feasable to build a separate infrastructure. The pure
economics of it is the prohibiting factor. If we could do it, then the rubber
second would solve a certain particlar headache. But I am very very very
pessimistic about it. The budget isn't there and the govrements already pay
good money for the systems in place and is looking to get as much out of it as
possible. Also, on the user equipment side it would require us to toss out a
whole bunch of already paid for and perfectly running gear. This would cost
much of the industry (medicin, telecom etc.) alot of money. You can be sure
that they would be advocating against it. To put it bluntly, we are too deep in
the shit to get out of it now. This is why a new timescale with all its new
requirements wouldn't go very far.

If you do want a new timescale, I think rubber seconds isn't going to be the
solution. It needs to be SI second based one way or another. This means that
you need to come up with something such as UTC. This is why I beleive that we
should be looking on how to ease the pain of current UTC leap second schedules
rather than inventing the wheel and getting it quite similar but not quite like
the UTC.

Just consider the confusion we have between GMT and UTC. Now with a third
timescale it would become a mess to sort things out. These days when ordinary
people (and most beurochrats) say GMT we can silently assume they meant to say
UTC but if we are going to follow them to the letter we have trouble.

So, yes... it would solve certain things, but I don't think it will happend.

No, GPS is not TAI. GPS run its own timescale and it is offset from TAI by
19
seconds, as given in BIPMs Circular T 227:

I meant up to a known conversion. If you have some GPS time, you know it
for TAI, and vice versa.

Indeed. But it was not what you wrote.

That's not the case for UTC, since you don't
know what the leap second offset will be if it's too far in the future.
Of course you can also extract UTC from a GPS signal.

You assume that you always convert UTC into TAI when you are given a UTC time.
You don't need to. You can maintain your time in UTC and when the local UTC
time (as corrected by received UTC leap seconds) reaches that time, you will
get your even at the correct UTC time. You can resolve these issues, but you
have to be aware that time differences needs to be done in TAI and future UTC
timestamps needs to be done in UTC. You know this naturally, but we do lack
the vehicle in some systems. Is this the fault of how UTC was built? No.
Will a third time scale solve this? No. Will we eventually have to reform the
UTC scale as we run out of leap second oppertunities? Yes, but not in our
lifetime to the best of my knowledge.

Cheers,
Magnus

```

### Re: A lurker surfaces

```
Magnus Danielson wrote:

The budget isn't there and the govrements already pay
good money for the systems in place and is looking to get as much out of it as
possible.

Yes, you're probably right, they're likely to prefer to patch up
something ultimately broken cheaply than fix it properly.

I think the best that can be hoped for in the short term is a
user-created infrastructure among those who care enough to bother. And
just agreeing what the lengths of the seconds should be, or even the
schedule for specifying them, is likely to be hard enough.

Indeed. But it was not what you wrote.

Eh, GPS time is TAI. You just have to know about the odd encoding...

--
Ashley Yakeley

```

### Re: A lurker surfaces

```From: Ashley Yakeley [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Tue, 02 Jan 2007 16:40:23 -0800
Message-ID: [EMAIL PROTECTED]

Ashley,

Magnus Danielson wrote:
The budget isn't there and the govrements already pay
good money for the systems in place and is looking to get as much out of it
as
possible.

Yes, you're probably right, they're likely to prefer to patch up
something ultimately broken cheaply than fix it properly.

I think the best that can be hoped for in the short term is a
user-created infrastructure among those who care enough to bother. And
just agreeing what the lengths of the seconds should be, or even the
schedule for specifying them, is likely to be hard enough.

There is never such a thing as a perfect system in this game. We need to run of
one or another of a whole set of approximation schemes. Whatever scheme we have
or come up with, we have a number of different needs which in themselfs are
conflicting. Whatever system we are running, it needs to be widely realizeable
with sufficient precission as the many different usages require, and there are
many customers around. It also needs to be well understood and supported by
system designs throughout many types of equipment.

Even if we can come up with a better scheme for some purposes, it needs to be
manageable into the whole infrastructure in a fairly painless fashion. You can
never get it quite right, but fairly painless is what you can hope fore.

If we rebuilt all time distribution systems and all systems using time, we
could do anything. Including rubber seconds which can be designed handle all
expected rates of earth spinning in the next 1 years or so. Unfortunatly
that is not a luxury we have. Technological and economical limitations is
there and real. Not that we don't have technological and economical issues as
it is, we do, but that even strengthen the point.

So, I don't think we will get the perfect time solution ever. But behing humans
as we are, we keep striving towards that unobtainable goal.

I would do a whole lot of things differently if time and economics where not a
limiting factor. In the meantime, I too will have to suffer approximations.

Indeed. But it was not what you wrote.

Eh, GPS time is TAI. You just have to know about the odd encoding...

In order to know about the odd encoding you need to call it something else
than TAI since is not EXACTLY as TAI. It is not even TAI plus some fixed
number. You can make a darn good (given the money you need) TAI approximation
off the GPS time. Another darn good approximation could I have if I plugged
into say PTB-CS2. They are not the same and never will be. You can hower use
the GPS time to getyourself a TAI approximation, but it never will be TAI.

So GPS time is not TAI. Never will be. Given some compensation it is near
thought.

Cheers,
Magnus

```

### Re: A lurker surfaces

```On 2 Jan 2007 at 12:40, Warner Losh wrote:

The interval math in UTC that's hard today would be significantly
harder with rubber seconds.  But it is just software, eh?

In short, it is an interestingly naive idea that was tried in the
1960's and failed when there were only dozens of high precision time
users rather than the hundreds of thousands there are today.

Actually, rubber seconds were what were in use for centuries, as
the time calibrated to astronomical observations, with the second
defined in terms of the length of a solar day, was what was in use
(or, actually, a very rough approximation of it given the lack of
accuracy of timepieces in the pre-atomic era).  What was tried
unsuccessfully in the 1960s was to actually define such timekeeping
in a rigorous scientific way allowing conversion to and from atomic
time.

--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

```

### Re: A lurker surfaces

```On 2 Jan 2007 at 11:47, Ashley Yakeley wrote:

The obvious solution is to transmit rubber time on a rubber frequency.

Are rubber duckies involved?

--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

```

### Re: A lurker surfaces

```On 2 Jan 2007 at 11:56, Ashley Yakeley wrote:

GPS is TAI. I'm not proposing abandoning TAI for those applications
that need it.

It's a few seconds off from TAI, isn't it?  It was synchronized to
UTC in 1980 (I think), but without subsequent leap seconds, so it's
now different from both TAI and UTC.  They probably should just have
used TAI if they wanted a time scale without leap seconds, rather
than ending up creating a different one.

--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

```

### Re: A lurker surfaces

```
Magnus Danielson wrote:

If you do want a new timescale, I think rubber seconds isn't going
to be the solution.

One might point out that many time scales do rely on rubbery seconds,
e.g., sidereal time and apparent solar time.  If might be
enlightening to step back from the tendentious and tedious tug-of-war
between UTC and TAI and reflect that even UT1 - a mean solar time
scale - intrinsically has rubber seconds.  Sexagesimal notation is
clearly revealed as a way to express an angle - of Earth orientation
in this case.  The whole point of UTC is to permit Earth orientation
to be approximated while using SI seconds.

Rob Seaman
NOAO

```

### Re: A lurker surfaces

```In message: [EMAIL PROTECTED]
Daniel R. Tobias [EMAIL PROTECTED] writes:
: On 2 Jan 2007 at 11:56, Ashley Yakeley wrote:
:
:  GPS is TAI. I'm not proposing abandoning TAI for those applications
:  that need it.
:
: It's a few seconds off from TAI, isn't it?  It was synchronized to
: UTC in 1980 (I think), but without subsequent leap seconds, so it's
: now different from both TAI and UTC.  They probably should just have
: used TAI if they wanted a time scale without leap seconds, rather
: than ending up creating a different one.

Yes.  There's a fixed offset between seconds in TAI and seconds in
GPS.  The GPS timescale is tied to seconds in UTC(NRO).  TAI is a
paper clock, computed after the fact, so GPS can't ever be TAI time.
However, the differences there are down in the nanosecond or so
range.

There's a big philosophical opposition to using the paper clock that
is TAI in a real-time operational timescale that GPS uses.  The
European version of GPS originally specified TAI time, but this was
changed in later revisions to be the same as GPS time.  There's an
extreme reluctance in the time community to call something without
leap seconds TAI or TAI + fixed offset.  TAI means something very
specific.  That's the other problem with just using TAI, btw, but
explaining that point is very hard...

The principle time scientist made me change the description of the
output of measurment time for a product I did.  I described it as TAI
time seconds since 1970.  Instead, he descriped it as Number of PPS
ticks in the UTC time scale since 1972 + 63072000 + 10.
Mathematically, they work out to be the same thing, but he was
extremely resistant to calling it TAI time or using the TAI moniker
isn't realized in real time, but UTC is.  UTC is what one can measure
against.  Producing a number that corresponded to TAI time was OK, and
likely the least confusing thing to do (we give a second number and
UTC time in '-MM-DD HH:MM:SS Z' as well as the channel and the
measurement for that time in out output), but actually calling it TAI
would 'confuse' the really smart time geeks out in the world.  I asked
him for a reference where I could read up on this, and he shrugged and
said he just knew it and didn't know of any good write up.

Warner

```

### Re: A lurker surfaces

```From: Rob Seaman [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Tue, 2 Jan 2007 20:45:14 -0700
Message-ID: [EMAIL PROTECTED]

Rob,

Magnus Danielson wrote:

If you do want a new timescale, I think rubber seconds isn't going
to be the solution.

One might point out that many time scales do rely on rubbery seconds,
e.g., sidereal time and apparent solar time.  If might be
enlightening to step back from the tendentious and tedious tug-of-war
between UTC and TAI and reflect that even UT1 - a mean solar time
scale - intrinsically has rubber seconds.  Sexagesimal notation is
clearly revealed as a way to express an angle - of Earth orientation
in this case.  The whole point of UTC is to permit Earth orientation
to be approximated while using SI seconds.

Indeed. The civil usage require something like UT1 even if not precise UT1.
UTC is one such solution. UT1 is as rubbery as it gets. Some transmissions
include enought information for creating a local estimate of UT1, but not with
sufficient level of resolution for all the uses we have. With the one-way
(or indeed two-way) time transfer mechanisms now at our disposal we can remove
much of the time offset between transmitter and receiver. You could therefore
build UT1 realizations based on improved clock model and diverse parameters for
UT1 realization. Technically it would be quite possible. You just need to add
these parameters in order for a TAI/UTC transmission or for that matter UT1
transmission (with transmitter corrections). Even if rubbery, you should be
able to build an smoothed UT1 realisation of quite high accuracy if you need
to. However, this would result in several problems not only in the updating of
the transmission system and the related receivers, for many other purposes we
still require TAI traceability/stability as well as civil time alongside.
With all its thorns UTC is IMHO a better solution than having to deal with
two different types of seconds which moves around all the time.

I view your comment as being astronomy-oriented (nothing wrong with that).
However, for the type of systems which I normally wrap my head around the exact
angle of Earth orientation is as such not very interesting, but on average it
needs to be somewhere in the neighborhood of UT1 in the long run.

There are usage for TAI, UTC and UT1. Do we need to invent one more? Do we need
to make wider useage of UT1? Are the problems of UTC really that big? IMHO and
to the best of my limited insight I still find those questions answered with a
no.

Cheers,
Magnus

```

### Re: A lurker surfaces

```From: Steve Allen [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Tue, 2 Jan 2007 21:35:24 -0800
Message-ID: [EMAIL PROTECTED]

On Tue 2007-01-02T22:16:19 -0700, M. Warner Losh hath writ:
changed in later revisions to be the same as GPS time.  There's an
extreme reluctance in the time community to call something without
leap seconds TAI or TAI + fixed offset.  TAI means something very
specific.  That's the other problem with just using TAI, btw, but
explaining that point is very hard...

It would almost seem to consistent with established notation
to define

TAI(GPS) = GPS + 19 + W1K * n

Actually, in BIPM Circular T they use another notation to avoid confusing TAI
with that of a particular local TAI realization, TA(k). So the above formula
would be

TA(GPS) = GPS + 19 + C0

where C0 is being reported in Clause 5 of Circular T. Actually, they write it
as:

[UTC-GPS time] = -14 s + C0,   [TAI-GPS time] =  19 s + C0, global
uncertainty is of order 10 ns.

(direct quote from Circular T No 227).

For UTC they gladly refer to UTC and UTC(OP) or whatever laboratory they choose
to discuss.

Producing a number that corresponded to TAI time was OK, and
likely the least confusing thing to do (we give a second number and
UTC time in '-MM-DD HH:MM:SS Z' as well as the channel and the
measurement for that time in out output), but actually calling it TAI
would 'confuse' the really smart time geeks out in the world.  I asked
him for a reference where I could read up on this, and he shrugged and
said he just knew it and didn't know of any good write up.

This is my tail wags the dog point.

The national metrology agencies are tasked by their national laws
and funding agencies to produce the legal time scale for each country.
Depending on the state of legislation that is either GMT or UTC.
In the US the time agencies have chosen to interpret GMT as UTC
by taking advantage of the imprecision of the federal law.

The national metrology agencies are not *directly* tasked to keep TAI,
but by being parties to the Metre Convention their own version of UTC
plus leap seconds contributes to TAI.

So each national contributing source to TAI is really based on that
country's version of UTC.  Despite the appearances of the equations
the versions of UTC are the primary entities and TAI is secondary.

Notice that some laboratories actually maintain their own TAI in addition to
maintaining their own UTC. You can even see that they produce different data
for UTC and TAI.

And, yes, explaining all this is very hard.  It's not obvious to the
geek that the political and funding realities are more real than the
underlying physics, but that's the way the world works.

Indeed. I investigated the different translations of the European Commission
summer time directive and it turns out that most translations referred to GMT
where as only a few actually said UTC. It gives the filmtitle Lost in
translation yeat another meaning. Sigh. Interestingly was the Danish
translation indicating the transition times in UTC where as Denmark yeat has to
legally accept UTC (where as it in reality thanks to a certain friend of ours
here for all practicall reasons actually is UTC). Sigh.

Cheers,
Magnus

```

### Re: A lurker surfaces

```
On Dec 30, 2006, at 17:41, Jim Palfreyman wrote:

The earlier concept of rubber seconds gives me the creeps and I'm

I rather like the idea, though perhaps not quite the same kind of
rubber as was used.

I'd like to see an elastic civil second to which SI nanoseconds are
added or removed. Perhaps this could be done annually: at the
beginning of 2008, the length of the civil second for the year 2009
would be set, with the goal of approaching DUT=0 at the end of 2009.
This would mean no nasty unusualities, and match the common
intuition that a second is a fixed fraction of a day. If NTP were to
serve up this sort of time, I think one's computer timekeeping would
be quite stable. And of course this will work forever, long after
everyone else is fretting over how to insert a leap-hour every other
week, or whatever. Software should serve human needs, not the other
way around. Anyone needing fixed seconds should use TAI.

Actually I was going to suggest that everyone observe local apparent
time, and include location instead of time-zone, but I think that
would make communication annoying.

--
Ashley Yakeley

```

### Re: A lurker surfaces

```In message: [EMAIL PROTECTED]
Ashley Yakeley [EMAIL PROTECTED] writes:
: Software should serve human needs, not the other
: way around. Anyone needing fixed seconds should use TAI.

I think this idea would be harder to implement than the current
leapseconds.

There are many systems that need to display UTC externally, but need
to operate on a tai-like timescale internally.  Having there being a
sliding delta between them would be a nightmare.

Warner

```

### Re: A lurker surfaces

```Ashley Yakeley [EMAIL PROTECTED] wrote:

I'd like to see an elastic civil second to which SI nanoseconds are

Ditto!  I have always been in favor of rubber seconds, and specifically
civil second.  I believe that the *CIVIL* second should have its own
definition completely and totally independent of the SI second.

Civil time independent of physical time would solve all problems.  The
scale of civil time should be defined as a continuous real number scale
of *angle*, not physical time.  It would solve the problem of needing to
measure time intervals while at the same time synchronising with the
civil calendar.  Civil time interval is defined as the clock on the
Kremlin tower turning by a given angle.  Define one second of civil time
as the hour hand turning by 30 seconds of arc.

The people who complain about leap seconds screwing up their interval
time computations are usually told to use TAI.  They retort that they
need interval time *between civil timestamps*.  To me that seems like
what they are really measuring as interval time is not physical
interval time, but how much time has elapsed *in civil society*.  Hence
my idea of civil interval time that's completely decoupled from physical
time and is instead defined as the turning angle of the clock on the
Kremlin tower.

Flame deflector up

MS

```

### Re: A lurker surfaces

```Michael Sokolov scripsit:

The people who complain about leap seconds screwing up their interval
time computations are usually told to use TAI.  They retort that they
need interval time *between civil timestamps*.  To me that seems like
what they are really measuring as interval time is not physical
interval time, but how much time has elapsed *in civil society*.

I think this point is quite sound, but I don't quite see what
its implications are (or why it makes rubber seconds better than

--
John Cowan   http://ccil.org/~cowan[EMAIL PROTECTED]
We want more school houses and less jails; more books and less arsenals;
more learning and less vice; more constant work and less crime; more
leisure and less greed; more justice and less revenge; in fact, more of
the opportunities to cultivate our better natures.  --Samuel Gompers

```

### Re: A lurker surfaces

```
On Jan 1, 2007, at 17:03, John Cowan wrote:

Michael Sokolov scripsit:

The people who complain about leap seconds screwing up their interval
time computations are usually told to use TAI.  They retort that they
need interval time *between civil timestamps*.  To me that seems like
what they are really measuring as interval time is not physical
interval time, but how much time has elapsed *in civil society*.

I think this point is quite sound, but I don't quite see what
its implications are (or why it makes rubber seconds better than

One implication is that a leap second insertion is a second of real
time, but zero seconds of intuitive civil time.

Rubber seconds are appropriate because we have rubber days. People
who need absolute time have their own timescale based on some
absolute unit (the SI second), but to everyone else, the second is
a fraction of the day.

--
Ashley Yakeley

```

### Re: A lurker surfaces

```In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Michael Sokolov) writes:
: The people who complain about leap seconds screwing up their interval
: time computations are usually told to use TAI.  They retort that they
: need interval time *between civil timestamps*.

Actaully, interval deltas are needed, but it is in TAI time.  There
needs to be, in the systems I've done, a timescale without leapseconds
to keep all the measurements sane.  In addition, many of the systems
I've done have other functions they do also, some of which need to
present UTC to the user.  As much of a pita that leapseconds are
today, having the converion between TAI and UTC (or put another way:
between GPS and UTC or LORAN and UTC) would make these systems
signficantly more difficult to get correct.

There's also times when our systems take in events that are
timestamped using UTC time, so we need to back correlate them to TAI
or whatever internal timescale we're using.  Some of that is because
UTC is the standard for exchanging time, part of that is because the
events in question are measured in whatever timescale is present on an
NTP server.

: To me that seems like
: what they are really measuring as interval time is not physical
: interval time, but how much time has elapsed *in civil society*.  Hence
: my idea of civil interval time that's completely decoupled from physical
: time and is instead defined as the turning angle of the clock on the
: Kremlin tower.

Actually, you are wrong.  The intervals is in the number of pps that
have happened, or fractions thereof.  Civil time does intrude because
that's what people use right now to know time fo day.  In the systems
I've done, you need to know both.

The requirements, as you may have noticed, for my needs aren't that
the intervals be done in TAI (we use a variant of LORAN time due to
historical accident, but with a 1970 epoch), but rather that UTC and
these time scales be convertable between one another.

Like I've said a number of times, saying 'just use TAI' isn't viable
because of the conversion issue.  Using TAI (or something with the no
leapsecond regualrity that TAI gives) is necessary for the algorithms
to work.  However, external pressures also require that some things be
done in UTC time and that some of the external sources of data use UTC
time and that needs to be back correlated to the internal timescale
that we're using.

The algorithms, btw, basically integrate frequencies of different
clocks, over time, to predict phase difference.  In this case, you
definitely want to use an interval, and not whatever weirdnesses civil
time happened to do in that interval.  Using an civil time interval
would introduce errors in algorithms.  These algorithms are used to
estimate how well the clocks are doing, but other parts of the system
need to play our UTC for things like NTPD and IRIG.

Warner

```

### Re: A lurker surfaces

```From: Michael Sokolov [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Mon, 1 Jan 2007 22:22:23 GMT
Message-ID: [EMAIL PROTECTED]

Ashley Yakeley [EMAIL PROTECTED] wrote:

I'd like to see an elastic civil second to which SI nanoseconds are

Ditto!  I have always been in favor of rubber seconds, and specifically
civil second.  I believe that the *CIVIL* second should have its own
definition completely and totally independent of the SI second.

Civil time independent of physical time would solve all problems.  The
scale of civil time should be defined as a continuous real number scale
of *angle*, not physical time.  It would solve the problem of needing to
measure time intervals while at the same time synchronising with the
civil calendar.  Civil time interval is defined as the clock on the
Kremlin tower turning by a given angle.  Define one second of civil time
as the hour hand turning by 30 seconds of arc.

No. It does not solve all problems. It introduces a whole bunch of new problems
of which I don't see any chances of swift implementations in many systems and
infact there would be quite large investments involved which I don't see with
other proposals.

Why?

Today we have a joint infrastructe for time distribution and in effect much of
todays *civil* time effectively hangs of GPS and do some degree transmissions
suchs as MSF, DCF77 etc. The later sources can be adjusted to rubber seconds,
but doing this to the GNSS world such as GPS would be quite problematic. The
NTP side of the world depends on various sources of UTC such as GPS, MSF,
DCF77 etc. For that not to break we need a real-time or near real-time solution
to compensate for that (using information comming from that source for
security reasons).

The longwave radio sources can easilly be adjusted at the source, but some of
their uses still lies in frequency comparision so due care would be needed for
those still using those sources for that purpose.

For GPS it would most probably require additional messages for a predicted
rubberization of the transmitted GPS time. This would also require the update
of all GPS receivers related to legal timing relating to be able to include the
correction.

Another way to go around it would be to adjust all sources (including GPS) to
actually transmitt rubber seconds. This would mean deeper modifications of the
GNSS satellites. I don't see that happening.

The last time we ran rubber seconds we could easilly device the transmitters of
time with the necessary hardware and run adjustments. The problems with
rubber seconds back then was that the detailed operations deviated from site to
site, so two transmitters would not necessarilly work. These days we have a
much more rigid system. We cannot choose arbitrarilly.

UTC is the civil time and in some countries the legal time. We need it to tick
in some reasnoble relation to things like the rise, noon and settlement of the
sun. Rubber days by means of leap seconds or leap minutes would work. There are
issues with these, mostly relating to the scheduling time obviously.

Not to say that there isn't problems with leap seconds. However, for the
civil use aspect, the DUTC  0.9s is not necessary. There is however a
requirement to keep DUTC below some limit, so just giving up on leap seconds
would be unacceptable in the long run. To avoid such things we have already
corrected the calender through the Julian and Gregorian corrections.

We do have TAI for usage of time intervals etc. Many systems uses TAI (or some
offset of TAI) and then leap second corrections for UTC reference. The leap
seconds can cause problems when jumping between TAI and UTC and which
particular problem one get depends on what the goal is (i.e. if a particular
UTC time is needed to a particular time difference). A scheduled leap second
may arrive into the decission process later than the initial decission was
taken in a system. The problem can be solved, but it complicate matters, but
they do not necessarilly become impossible.

There are problems relating to leap seconds. Interestingly enought, the
previous scheduling rules where limited by mail transfer to all affected
parties. With the new digital communication allowing us to transmitt messges
to any part of the globe within a few seconds, we seems to have a need for a
longer scheduling time. But sure, a longer scheduling time could work.

I think there is no real solution outside of the leap second (or possibly leap
minute) world. Rubber seconds has too many issues for it to be useable.
Abandoning leap second issuing doesn't fullfill the civil useage in long term.
We can work with the ways we predict and schedule leap seconds. The noise
process however prohibit us from setting up strict rules such as the Gregorian
date rules for leap days, those will actually have to be corrected too
eventually. So, for civil usage, I have yeat to hear a better proposal than
leap seconds. There is room```

### Re: A lurker surfaces

```Ashley Yakeley scripsit:

Rubber seconds are appropriate because we have rubber days. People
who need absolute time have their own timescale based on some
absolute unit (the SI second), but to everyone else, the second is
a fraction of the day.

Well, okay.  Does the rubberiness go down all the way?  Is a civil
nanosecond one-billionth of a civil second, then?  If so, how do we
build clocks that measure these intervals?

--
One art / There is  John Cowan [EMAIL PROTECTED]
No less / No more   http://www.ccil.org/~cowan
All things / To do
With sparks / Galore -- Douglas Hofstadter

```

### Re: A lurker surfaces

```On Tue 2007-01-02T01:48:26 -0500, John Cowan hath writ:
Well, okay.  Does the rubberiness go down all the way?  Is a civil
nanosecond one-billionth of a civil second, then?  If so, how do we
build clocks that measure these intervals?

Let's not.

Let's continue the valid and agreeable notion of transmitting seconds
and frequencies based on a coordinate time scale tied to the ITRS at a
specified depth in the gravitational+rotational+tidal potential.  The
best practical implementation of such is undeniably the estimation
given by TAI.

Then let's improve the infrastructure for communicating the best
estimation of earth orientation parameters.  Then in a world of
ubiquitous computing anyone who wants to estimate the current
rubber-second-time is free to evaluate the splines or polynomials
(or whatever is used) and come up with output devices to display that.

And let's create an interface better than POSIX time_t which allows
those applications which need precise time to do a good job at it.

--
Steve Allen [EMAIL PROTECTED]WGS-84 (GPS)
UCO/Lick ObservatoryNatural Sciences II, Room 165Lat  +36.99858
University of CaliforniaVoice: +1 831 459 3046   Lng -122.06014
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m

```

### Re: A lurker surfaces

```
Poul-Henning Kamp wrote:

In message [EMAIL PROTECTED], Rob Seaman writes:

Jim Palfreyman wrote:

Just a reminder that UTC has no - none - nada - discontinuities.
Various computer mis-implementations may, but the standard is very
carefully constructed to avoid spring-forward or fall-back gaps or do-
overs.

Rob, If you feel uncomfortable with calling leapseconds
discontinuities, then we can use the term arrhythmia instead.

If we assume that every month has 30 days and obtain a day
number by multiplying the month number by 30 and adding
the day in month (call this the SDN - Silly Day Number) and
then look at SDN-MJD (modified Julian day number) we would
see discontinuities.

The only way to see discontinuities in UTC-TAI is by making
an equally silly assumption in numbering the seconds of
UTC: assuming all UTC minutes are 60 seconds or, equivalently,
all UTC days are 86 400 seconds.

The unfortunate thing is that people actually do think of it
this way.  E.g.:

http://hpiers.obspm.fr/eop-pc/earthor/utc/TAI-UTC_tab.html

The whole idea of the expression UTC-TAI being meaningful
and evaluating to a number of seconds is a convenient but
rather sloppy shorthand.  Any strongly typed programming
language ought to give a type error on that expression.

UTC times of day are variable radix - in just the same way
as days and months are in the Gregorian calendar.

Except, of course, that the Gregorian calendar is fixed and
completely predicable.  I have an awful lot of sympathy for
the idea of making leap seconds predictable over longer
periods, even if it risks UTC-UT1 becoming larger than at
present allowed.

Ed.

```

### Re: A lurker surfaces

```On Sun 2006-12-31T07:59:35 +, Poul-Henning Kamp hath writ:
Rob, If you feel uncomfortable with calling leapseconds
discontinuities, then we can use the term arrhythmia instead.

The point of my allegory about unplanned pregnancies is that
all practically available time scales have arrhythmias.
Almost everything has jumps at some point during power on self test,
and the national time bureaus (and the GPS almanac) publish their
current estimate of their deviation from regularity.  If you can
handle leap seconds, then you can handle reality.  The decision made
37 years ago was that the reality of most systems didn't/couldn't care
about seconds, and that's the part that now is getting scrutiny.

What tweaks me is that I get the impression that a lot of folks are
perfectly willing to accept those irregularities and to let Dave Mills
diddle with the rates of their system clocks so long as they never
have to admit the existence of a named leap second.  It's as if
everything is okay so long as the baby never comes to term -- everyone
can live in denial about those things going on behind the scenes --
but as soon as the county recorder gets that birth certificate with
Mr.  Astronomer named as father the social order of the world breaks
down.

I see this as a form of denial.  Almost all applications may be
capable of tolerating the level of irregularity in the currently
practically available time scales, but they are irregular.

What happens in a world with terabit per second information streams
coming over fibers from sources whose clocks, even if they are
ion-trap clocks (especially if so), are different tidal potentials
that vary diurnally?  (Of course the glib answer is that if the
optical fiber engineers do manage to notice this first then they will
win the Nobel prize just as surely as Penzias and Wilson did after
they found that cleaning pigeon shit out of their microwave horns did
not manage to make the background noise go away.)

What happens in a world where systems begin to be sensitive to the
effective leap microseconds or variations in length of seconds which
happen even if Dave Mills is conditioning their clocks?

It's my expectation that if all systems are allowed to deny the
reality of precision time keeping we will eventually find ourselves
living in a timekeeping world that resembles C.M. Kornbluth's story
The Marching Morons.

--
Steve Allen [EMAIL PROTECTED]WGS-84 (GPS)
UCO/Lick ObservatoryNatural Sciences II, Room 165Lat  +36.99858
University of CaliforniaVoice: +1 831 459 3046   Lng -122.06014
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m

```

### Re: A lurker surfaces

```On Sun, 31 Dec 2006, John Cowan wrote:

However, it's clear that UTC does not contain the sort of jumps
that LCT does, where a single broken-down time may represent
two different UTC seconds.

Not if you include the timezone offset in the representation.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
THAMES DOVER WIGHT PORTLAND PLYMOUTH BISCAY: SOUTHWEST VEERING WEST 6 TO GALE
8, INCREASING 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. ROUGH OR VERY ROUGH
BUT HIGH IN PLYMOUTH AND BISCAY. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.

```

### Re: A lurker surfaces

```Rob Seaman wrote:
Just a reminder that UTC has no - none - nada - discontinuities.

I concur, and so I prefer to say that UTC has _irregularities_.  The rest
of what Jim Palfreyman said applies to these irregularities: they must
occur frequently so that the method of handling them is implemented and
well tested.

-zefram

```

### Re: A lurker surfaces

```In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: Tony Finch scripsit:
:  On Sun, 31 Dec 2006, John Cowan wrote:
:
:   However, it's clear that UTC does not contain the sort of jumps
:   that LCT does, where a single broken-down time may represent
:   two different UTC seconds.
:
:  Not if you include the timezone offset in the representation.
:
: Quite so.  Or alternatively a standard/daylight flag.  The point is,
: people usually don't.

This is the leapsecond problem in a nutshell:  While it is possible to
keep enough information around in the representation of time, most
people opt not to do so.  It complicates the representation of time,
and is one (or more) pieces of information that need to be carried
around, mostly just to handle weird edge cases.  Sure, you can do it,
and some people try.  However, there's no standardized way to do so,
and people re-invent it wrong over and over again.

Another poster I think was right: ntpd (and the underlying OS) hides a
lot of these sins.  Either by just twitterpating at the leapsecond in
some way (time stands still, time jumps back a little, etc), or for a
period of time around the leapsecond (by sticking its fingers in its
ears, singing lalala and changing the size of a second to get through
it a millisecond at a time).

Warner

```

### Re: A lurker surfaces

```
Poul-Henning Kamp wrote:

Rob, If you feel uncomfortable with calling leapseconds
discontinuities, then we can use the term arrhythmia instead.

Which raises the question of why projects requiring an interval time
scale lacking in such arrhythmias would have selected UTC in the
first place.  And why timekeepers who understand these issues would
focus on remediating (i.e., eviscerating) UTC as the cure.
Astronomers are among the power users for interval time as well as
time-of-day.  Helioseismologists (http://gong.nso.edu) needed an
interval timescale that would be even tempered over years or even
decades (a solar cycle is eleven years - the magnetic field flips at
solar max, so a complete sample would require 22 years) - so they
selected GPS, not UTC.

But actually, I think we should call leap seconds what they are -
intercalary events.  My wife works at the Arizona-Sonora Desert
Museum.  We have family visiting and decided to spend the day at the
museum - a good way to end a year.  I especially recommend the raptor
free flight program - the ferruginous hawk is especially impressive.
My point is that a javelina is not a pig, a coatimundi is not a
raccoon, and a ringtail cat is not a cat.  A kangaroo rat is, of
course, neither.  And a leap second is a not a discontinuity.
Imprecision in terminology leads to poor decision making.

Rob

```

### Re: A lurker surfaces

```In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Poul-Henning Kamp wrote:
:
:  Rob, If you feel uncomfortable with calling leapseconds
:  discontinuities, then we can use the term arrhythmia instead.
:
: Which raises the question of why projects requiring an interval time
: scale lacking in such arrhythmias would have selected UTC in the
: first place.

The real world often times requires both kinds of time keeping, with
correlation back and forth between all the timescales.  The customers
want to deal with times in UTC.  To get an effective, high precision
time system, you need to count seconds in a sane way (UTC isn't a sane
way for this purpose) so some conversion between this count and UTC is
needed.

The problem is that most interesting systems have a need to do things
based on UTC time of day, as well as in a time scale that has none of
the complications of the unpredictable UTC implementation we have
today.  So you can't just 'pick one' because real-world systems need
to use different ones for different things, and they also need to
translates events from one timescale to events in the other
timescale.

Let me give you a concrete example.  Let us say we are measuring a
number of atomic clocks against one another.  We get the measurements
and those measurements are in a monotonic timescale that is defined as
PPS's from some epoch (or number of 5MHz or 10MHz ticks from some
arbitrary epoch).  We get data from GPS, which has a similar
timescale.  We compute the clock states and deside that we need to
steer one of the clocks.  These algoritmns are very much elapsed time
sorts of deals.  So we schedule a time to steer it, and then note the
time when we are done steering it.  Since we cannot easily get the GPS
or timer times without interfereing with the operations of those
subsystems (maybe because the steering system and GPS system are on
dufferent cpus), we get the system time when the steer starts and when
the clock tells us the steer is complete (since a steer isn't an
instantaneous event).  Since this system also is an ntpd server, that
system time is in UTC.  Now we have to convert UTC into the internal
timescale so that the algorithms know when the steer happened and can
take that into account for their next round of measurments and
decision making.

To make this all work out well, one has to have perfect leap second
knowledge and all the special case code you have for dealing with the
arrhythmia of a leap second has to work perfectly.  Anything that can
be dobe to make things more perdictable helps out quite a bit...

Warner

```

### Re: A lurker surfaces

```
Jim Palfreyman wrote:

With my time hat on, having time that is discontinuous pains me. It
doesn't make sense in my heart. But at least these
discontinuities are in whole seconds.

Any discontinuities must be regularly done. So they are part of all
computer systems and are tested and used all the time. Don't let

Just a reminder that UTC has no - none - nada - discontinuities.
Various computer mis-implementations may, but the standard is very
carefully constructed to avoid spring-forward or fall-back gaps or do-
overs.

This is just one of many flaws of the notion of leap hours.  A leap
hour (like a leap second or leap day) is an extra intercalary
temporal unit inserted into the continuous flow of time.  A leap hour
is NOT an unmatched fall back do-over - the day in question would
have 25 regular, ordinary, permanent, unique hours - and the extra
hour would occur contemporaneously worldwide.  It would not involve
an easy floating 2 am Sunday local clock reset.

So, for example, if the leap hour is 2606-12-31, 24:00:00 to 24:59:59
UT, it would fall BETWEEN 18:59:59 and 19:00:00 EST, just like a leap
second today is 23:59:60 UT or 18:59:60 EST, also falling between
18:59:59 and 19:00:00.  In each time zone in turn, the leap hour
would fall between different otherwise sequential clock ticks - a non-
issue with a leap second, not so easy to ignore with a leap hour.
Still not a discontinuity, but certainly a real pain for anyone who
is trying to keep the events of the day straight.

More than likely, the hour would be labeled the same worldwide, so
the EST clock would run 18:59:58, 18:59:59, 24:00:00, 24:00:01, ...,
24:59:58, 24:59:59, 19:00:00, 19:00:01, ...

Rob

```

### Re: A lurker surfaces

```In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Just a reminder that UTC has no - none - nada - discontinuities.

At the very least, the TAI-UTC difference is discontinuous with jumps
at the leap seconds.  One could easily suggest that 'UTC has
discontinuities' really is a shorthand way of saying this.  One could
also call them irregularities, like the time scale is constipated, as
well.

And the variable radix seems to be to be a crude way to define away
the problem.  You never know, unless you look it up in a table, when
to do the variation in the radix.

: Various computer mis-implementations may, but the standard is very
: carefully constructed to avoid spring-forward or fall-back gaps or do-
: overs.

Well, if you count the variable radix notation as being 'continuous'
then maybe you are right.  However, you never know when the radix is
variable, hence the assertion on many people's part that UTC is
discontinuous.

Warner

```