Re: The real problem with leap seconds

```In message [EMAIL PROTECTED], Francois Meyer writes:
On Mon, 16 Jan 2006, Mark Calabretta wrote:

1. UTC and TAI  share  the  same  rate,  the  same
origin, the same second. And therefore :

UTC - TAI = 0

This is wrong, plain and simple wrong.

Please don't come back until you have understood and accepted that this is not
the case.

--
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: The real problem with leap seconds

```
Poul-Henning Kamp wrote:

In message [EMAIL PROTECTED], Francois Meyer writes:

On Mon, 16 Jan 2006, Mark Calabretta wrote:

1. UTC and TAI  share  the  same  rate,  the  same
origin, the same second. And therefore :

UTC - TAI = 0

This is wrong, plain and simple wrong.

Well, if by UTC you mean the count of seconds including leaps then this
is right.

Please don't come back until you have understood and accepted that this is not
the case.

Please don't be so rude - it really doesn't help to have conversations so
polarised.

Ed.

```

Re: The real problem with leap seconds

```In message: [EMAIL PROTECTED]
Francois Meyer [EMAIL PROTECTED] writes:
: On Mon, 16 Jan 2006, Mark Calabretta wrote:
:
:  On Fri 2006/01/13 11:17:52 -, Michael Deckers wrote
:  in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
:
: I must get TAI, up to an integration constant. This is correct.
: The integral of d( UTC ) is TAI (up to an integration constant),
: but this integral is UTC only where UTC is a continuous function
: of TAI.
:
:  You're still not getting the point that UTC is just a representation
:  of TAI.
:
: Maybe it should be,  but  this  is  far  from  being
: obvious from its current definition.
:
: The actual situation corresponds to :
:
: 1. UTC and TAI  share  the  same  rate,  the  same
:origin, the same second. And therefore :
:
: UTC - TAI = 0

The history of UTC and TAI is complicated and tricky.  You can only
say that on Jan 1, 1972, the TAI - UTC offset was fixed to be 10s.
UTC and TAI prior to 1972 did not evolve at the same rate.  The UTC
seconds differed in length from the SI seconds.  I'll ignore the
nomenclature differences over time as well.

: 2. UTC only differs from TAI by  its  definitions of
:the minute, hour and day.

This is not true prior to 1972.  There were a number of frequency
offsets in UTC that weren't present in TAI.  Some leap second charts
have these included in them.

: 4. the UTC minute is defined  to  ensure  that  dhms
:expressions of UTC match UT1 at .9 s; it  can  be
:either  59,  60  or  61  SI  seconds  long.  This
:definition of the minute is realized
:by  (positive  or  negative)  leap  seconds   and
:ensures that the mean UTC day is the  mean  solar
:day in the long term. The UTC  hour  has  60  UTC
:minutes, the UTC day has 24 UTC hours.

Again, post 1972...  I'm not sure what I think of this definition.

: From that point of view, the sentence from the ITU460-6 :
:
: [UTC] ...differs from it [TAI] from an integer of seconds
:
: should read :
:
: representations of UTC  involving  minutes,  hours,
: days differ from equivalent representations  of  TAI
: by an integral number of seconds

After 1972, and ignoring minor variations in the realization of UTC
and TAI in any given location, this is basically true.  The only ideal
difference between TAI(ideal) and UTC(ideal) is in the labeling of the
pulses that both time scales have experienced.  If one were to treat
them both as fixed radix, you get the difference of 33s.  Viewed
topologically as a 1-1 mapping, one could easily define subtraction so
that the difference is zero since UTC has a variable radix...

To further complicate things, TAI isn't created in realtime, but is a
paper clock that's steered to the correct time of the clocks that feed
it data.  There are clocks that are steered to this paper clock, but
it is all done by hand (if the various web pages I've read are still
accurate).  Different facilities realization of the TAI and UTC time
scales may differ by several nanoseconds (or more depending on a lot
of factors).

However, leaving aside those complications...

Given that UTC is a variable radix notation for labeling the pulses
that have elapsed since the epoch.  TAI is a fixed radix notation for
labeling pulses that have elapsed since the epoch.

Warner

```

Re: The real problem with leap seconds

```   On 2006-01-18, Steve Allen wrote:

Now I am confused.

By my reading of the documents, ITU-R did not define DTAI until the
most recent revision of TF.460 in 2002.  DUT1 had been defined since
very early on.

You are right, the name DTAI has apparently been introduced in 2002. It
also appears in [ITU-R TF536.2 2003] and [ITU-R TF686.2 2002]. It is
defined in these documents as the values of TAI - UTC and is described
as the contribution of the IERS to the determination of UTC. Such values
of TAI - UTC are published back to 1972 (step function) and even to 1961
(piecewise linear function).

Since I wanted to describe how I understood Mark Calabretta's
description of UTC as essentially the same as TAI except for the
variable radix notation for the (whole) second field in the time
of day values, I took DTAI as a convenient abbreviation of
TAI - ( UTC value when interpreted with
a fixed radix for the second field )
I avoided writing UTC for TAI - DTAI because this would contradict
the assumption that UTC is just TAI plus additional information.
Hope that clarifies things a bit.

Michael Deckers

```

Re: The real problem with leap seconds

```On Wed 2006/01/18 08:17:54 -, Francois Meyer wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

Maybe it should be,  but  this  is  far  from  being
obvious from its current definition.

I agree that the current definitions leave a lot to be desired in terms
of clarity and rigour - an uncharitable person might even describe the
extract of ITU-R TF.460-6 cited the other day by Michael Deckers as
inconsistent.  However, you have to consider how UTC is actually used in
practice and this is what my comments are based on.

1. UTC and TAI  share  the  same  rate,  the  same
origin, the same second. And therefore :

UTC - TAI = 0

They both count SI seconds but the question of the origin is a bit
muddy.

You could argue that there is a fixed 10s offset between UTC and TAI
because UTC post-1972 (everything I've said about UTC only applies
post-1972) started with 10 leap seconds, and before 1972 UTC wasn't
simply a representation of TAI.  There's no simple way of fudging
radixes that I can think of to make them match up, but if this worries
you then simply think in terms of proleptic UTC (post-1972),
see http://en.wikipedia.org/wiki/Proleptic.

However, this is not important and really only confuses things further.
(It's why I couched the original example as a graph of a person's age
vs UTC rather that TAI vs UTC.)

2. UTC only differs from TAI by  its  definitions of
the minute, hour and day.

3. the TAI day, hour, minute are  the  SI
day, hour, minute  of  86400,3600,60
SI seconds.

4. the UTC minute is defined  to  ensure  that  dhms
expressions of UTC match UT1 at .9 s; it  can  be
either  59,  60  or  61  SI  seconds  long.  This
definition of the minute is realized
by  (positive  or  negative)  leap  seconds   and
ensures that the mean UTC day is the  mean  solar
day in the long term. The UTC  hour  has  60  UTC
minutes, the UTC day has 24 UTC hours.

OK, but using the word definition doesn't seem quite right, I'd couch
it in terms based on counting seconds.

If you consulted the wikipedia entry for Factoradic that I referenced
the other day you will see that each digit in the factoradic
representation of a number has a subscript indicating its (fixed) radix.
The fields (not the digits!) of a UTC representation should have
something similar (likewise calendar dates written as 2006/01/19),
except that for the seconds field (and the day field) the radix would
be variable and there's no simple way to write it, so people assume
it's 60 which is what you do anyway if you want your approximation of
UT1.

From that point of view, the sentence from the ITU460-6 :

[UTC] ...differs from it [TAI] from an integer of seconds

representations of UTC  involving  minutes,  hours,
days differ from equivalent representations  of  TAI
by an integral number of seconds

I agree that the ITU-R TF.460.6 text needs fixing, but I would argue for
a stronger statement emphasising that a UTC representation (of TAI) has
two interpretions, one giving TAI (exact) and the other UT1 (approx), the
latter being offset from TAI by an integral number of seconds.

Mark Calabretta
ATNF

```

Re: The real problem with leap seconds

```In message: [EMAIL PROTECTED]
Mark Calabretta [EMAIL PROTECTED] writes:
: On Wed 2006/01/18 08:17:54 -, Francois Meyer wrote
: in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
:
: Maybe it should be,  but  this  is  far  from  being
: obvious from its current definition.
:
: I agree that the current definitions leave a lot to be desired in terms
: of clarity and rigour - an uncharitable person might even describe the
: extract of ITU-R TF.460-6 cited the other day by Michael Deckers as
: inconsistent.  However, you have to consider how UTC is actually used in
: practice and this is what my comments are based on.
:
: 1. UTC and TAI  share  the  same  rate,  the  same
:origin, the same second. And therefore :
:
: UTC - TAI = 0
:
: They both count SI seconds but the question of the origin is a bit
: muddy.
:
: You could argue that there is a fixed 10s offset between UTC and TAI
: because UTC post-1972 (everything I've said about UTC only applies
: post-1972) started with 10 leap seconds, and before 1972 UTC wasn't
: simply a representation of TAI.  There's no simple way of fudging
: radixes that I can think of to make them match up, but if this worries
: you then simply think in terms of proleptic UTC (post-1972),
: see http://en.wikipedia.org/wiki/Proleptic.

UTC (and its predecessors) prior to 1972 did not tick off in SI
seconds.  It used a fixed radix like TAI currently does.  The amount
of time in UTC seconds varied a little.  Here's the table from
ftp://maia.usno.navy.mil/ser7/tai-utc.dat

1961 JAN  1 =JD 2437300.5  TAI-UTC=   1.4228180 S + (MJD - 37300.) X 0.001296 S
1961 AUG  1 =JD 2437512.5  TAI-UTC=   1.3728180 S + (MJD - 37300.) X 0.001296 S
1962 JAN  1 =JD 2437665.5  TAI-UTC=   1.8458580 S + (MJD - 37665.) X 0.0011232S
1963 NOV  1 =JD 2438334.5  TAI-UTC=   1.9458580 S + (MJD - 37665.) X 0.0011232S
1964 JAN  1 =JD 2438395.5  TAI-UTC=   3.2401300 S + (MJD - 38761.) X 0.001296 S
1964 APR  1 =JD 2438486.5  TAI-UTC=   3.3401300 S + (MJD - 38761.) X 0.001296 S
1964 SEP  1 =JD 2438639.5  TAI-UTC=   3.4401300 S + (MJD - 38761.) X 0.001296 S
1965 JAN  1 =JD 2438761.5  TAI-UTC=   3.5401300 S + (MJD - 38761.) X 0.001296 S
1965 MAR  1 =JD 2438820.5  TAI-UTC=   3.6401300 S + (MJD - 38761.) X 0.001296 S
1965 JUL  1 =JD 2438942.5  TAI-UTC=   3.7401300 S + (MJD - 38761.) X 0.001296 S
1965 SEP  1 =JD 2439004.5  TAI-UTC=   3.8401300 S + (MJD - 38761.) X 0.001296 S
1966 JAN  1 =JD 2439126.5  TAI-UTC=   4.3131700 S + (MJD - 39126.) X 0.002592 S
1968 FEB  1 =JD 2439887.5  TAI-UTC=   4.2131700 S + (MJD - 39126.) X 0.002592 S
1972 JAN  1 =JD 2441317.5  TAI-UTC=  10.0   S + (MJD - 41317.) X 0.0  S
1972 JUL  1 =JD 2441499.5  TAI-UTC=  11.0   S + (MJD - 41317.) X 0.0  S
1973 JAN  1 =JD 2441683.5  TAI-UTC=  12.0   S + (MJD - 41317.) X 0.0  S
1974 JAN  1 =JD 2442048.5  TAI-UTC=  13.0   S + (MJD - 41317.) X 0.0  S
1975 JAN  1 =JD 2442413.5  TAI-UTC=  14.0   S + (MJD - 41317.) X 0.0  S
1976 JAN  1 =JD 2442778.5  TAI-UTC=  15.0   S + (MJD - 41317.) X 0.0  S
1977 JAN  1 =JD 2443144.5  TAI-UTC=  16.0   S + (MJD - 41317.) X 0.0  S
1978 JAN  1 =JD 2443509.5  TAI-UTC=  17.0   S + (MJD - 41317.) X 0.0  S
1979 JAN  1 =JD 2443874.5  TAI-UTC=  18.0   S + (MJD - 41317.) X 0.0  S
1980 JAN  1 =JD 2444239.5  TAI-UTC=  19.0   S + (MJD - 41317.) X 0.0  S
1981 JUL  1 =JD 2444786.5  TAI-UTC=  20.0   S + (MJD - 41317.) X 0.0  S
1982 JUL  1 =JD 2445151.5  TAI-UTC=  21.0   S + (MJD - 41317.) X 0.0  S
1983 JUL  1 =JD 2445516.5  TAI-UTC=  22.0   S + (MJD - 41317.) X 0.0  S
1985 JUL  1 =JD 2446247.5  TAI-UTC=  23.0   S + (MJD - 41317.) X 0.0  S
1988 JAN  1 =JD 2447161.5  TAI-UTC=  24.0   S + (MJD - 41317.) X 0.0  S
1990 JAN  1 =JD 2447892.5  TAI-UTC=  25.0   S + (MJD - 41317.) X 0.0  S
1991 JAN  1 =JD 2448257.5  TAI-UTC=  26.0   S + (MJD - 41317.) X 0.0  S
1992 JUL  1 =JD 2448804.5  TAI-UTC=  27.0   S + (MJD - 41317.) X 0.0  S
1993 JUL  1 =JD 2449169.5  TAI-UTC=  28.0   S + (MJD - 41317.) X 0.0  S
1994 JUL  1 =JD 2449534.5  TAI-UTC=  29.0   S + (MJD - 41317.) X 0.0  S
1996 JAN  1 =JD 2450083.5  TAI-UTC=  30.0   S + (MJD - 41317.) X 0.0  S
1997 JUL  1 =JD 2450630.5  TAI-UTC=  31.0   S + (MJD - 41317.) X 0.0  S
1999 JAN  1 =JD 2451179.5  TAI-UTC=  32.0   S + (MJD - 41317.) X 0.0  S
2006 JAN  1 =JD 2453736.5  TAI-UTC=  33.0   S + (MJD - 41317.) X 0.0  S

(or the yet to be updated http://www.iers.org/MainDisp.csl?pid=95-106)

Here's slides from a presentation that is actually fairly well
balanced:
http://www.ien.it/luc/cesio/itu/mc_carthy.pdf
It has history there as well.  There's a nice graph of the above on
page 20.

http://www.ucolick.org/~sla/leapsecs/timescales.html also contains a
nice summary of UTC which is too long to include here but in outline
form is:

UTC during 1960
UTC from 1961 through 1971
UTC in 1963
UTC in 1965
UTC ```

Re: The real problem with leap seconds

```   Mark Calabretta wrote:

You're still not getting the point that UTC is just a representation
of TAI.

OK, let me try again.

UTC (since 1972) is a disseminated timescale that is equal to TAI
except for additional date and time codes transmitted with the
signal. These codes indicate the values of TAI - DTAI for each
full minute of TAI - DTAI.

In a reading of UTC, (the most recent values of) these date and
time codes can be taken as is so as to yield a reading that
approximates UT1. The codes may also be used to derive the value of
DTAI (from a table of leap seconds since 1972), and thus, to yield
a reading of TAI. When a timestamp is characterised as UTC
(rather than TAI), then the first type of reading is implied.

In order to ensure a unique derivation of TAI from a recorded
reading of UTC in the vicinity of a positive leap second (where
DTAI jumps up by 1 s and the value of TAI for a given value of
TAI - DTAI is not unique), the UTC reading that corresponds to the
earlier TAI value shall be recorded with a second field = 60 s,
and the other UTC reading, with a second field  60 s.

Michael Deckers (still trying to understand the topology you referred to)

```

Re: The real problem with leap seconds

```On Mon 2006/01/16 12:11:04 -, Michael Deckers wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

UTC (since 1972) is a disseminated timescale that is equal to TAI
except for additional date and time codes transmitted with the
signal. These codes indicate the values of TAI - DTAI for each
full minute of TAI - DTAI.

In a reading of UTC, (the most recent values of) these date and
time codes can be taken as is so as to yield a reading that
approximates UT1. The codes may also be used to derive the value of
DTAI (from a table of leap seconds since 1972), and thus, to yield
a reading of TAI. When a timestamp is characterised as UTC
(rather than TAI), then the first type of reading is implied.

In order to ensure a unique derivation of TAI from a recorded
reading of UTC in the vicinity of a positive leap second (where
DTAI jumps up by 1 s and the value of TAI for a given value of
TAI - DTAI is not unique), the UTC reading that corresponds to the
earlier TAI value shall be recorded with a second field = 60 s,
and the other UTC reading, with a second field  60 s.

Michael Deckers (still trying to understand the topology you referred to)

I think we are basically on the same wavelength, though I would turn
some of your sentences around.

The way UTC is disseminated is not directly relevant to the discussion,
and I don't think I said anything about topology.  A better way to think
about it would be from the combinatorics point of view.

Enumerative combinatorics is basically concerned with counting things,
usually counting them two ways and drawing conclusions from that.  Use
of mixed-radix numbers is one of the strategies used in combinatorics,

The representation of UTC as a variable-mixed-radix number is a clever
way (possibly too clever) of counting seconds of TAI in a way that
allows interpretation as either TAI or, approximately, UT1.

The UT1 (or time_t) interpretation is obtained by treating UTC's
representation (label, notation) at face value, as though it was an
ordinary sexagesimal number.  UT1 so derived does have a discontinuity
when leap seconds are inserted and presumably this is what leads people
to say, misleadingly, that UTC itself is discontinuous.

On the other hand, TAI is recovered when the variable radix of the
seconds field is taken into account.  However, since they occur
irregularly, this interpretation requires a table containing the full
history of changes in the radix.  Alternately, the cumulative effect of
the table for epochs since the last leap second is conveniently
summarized in a number that we call DTAI, usually referred to as
TAI-UTC, where UTC here is understood to be the usual mixed-but-

So there is plenty of scope for confusion.  However, think back to the
graph of age vs UTC that I described at the start of this discussion and
particularly that each instant of the continuous time axis has a unique
UTC representation.

Mark Calabretta
ATNF

```

Re: The real problem with leap seconds

```From: Mark Calabretta [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] The real problem with leap seconds
Date: Tue, 17 Jan 2006 11:15:09 +1100

On Fri 2006/01/13 12:32:27 +1100, Mark Calabretta wrote
in a message to: Leap Seconds Issues LEAPSECS@ROM.USNO.NAVY.MIL

So if asked for a definition I would say that UTC (post 1972) is a
representation of TAI such that ... (you know the rest).

.. and I should have said that prior to 1972, when UTC had rubber
seconds, it was not a representation of TAI but something else again.

Yes.  TAI was recoverable from the UTC that existed prior to 1972, but
the math wasn't a simple addition...

Warner

```

Re: The real problem with leap seconds

```On Fri 2006/01/13 14:20:21 -, Michael Deckers wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

Then why can the IERS express UTC in the MJD notation?

Good point.  The only such usage I am aware of is in IERS Bulletin A
where the MJD column is given without saying even whether it's UTC, TAI,
UT1, or something else.  In fact, in the situation where it's used the
accuracy doesn't warrant it.

Mark Calabretta
ATNF

```

Re: The real problem with leap seconds

```On Fri 2006/01/13 11:45:13 -, Ed Davies wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

If you don't count the leap seconds then the good news is that
days are all 86 400 seconds long but the bad news is that the
real is undefined during the leap second and there's a
discontinuity (or rather, a surprising continuity in that
at some point it's 23:59:59.99 and a whole second and
a tiny bit later it's 00:00:00.).

Agreed.  I would add that two occasions when you would do this is in
computing UT1 and time_t.

The use of the 23:59:60 notation is described in ISO 8601.
Is it also specified in TF.460?  If so, how do they relate
it to the notion of DTAI?

In practice, refer to the example I gave on Jan/12.

Mark Calabretta
ATNF

```

Re: The real problem with leap seconds

```On Fri 2006/01/13 16:45:33 -, Michael Deckers wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

Right, UTC timestamps are ambiguous (in the sense that the

... would have been ambiguous ...

corresponding TAI value is not known) in the vicinity of
positive leap seconds, and the notation with a second
field = 60 s is one (elegant) way to disambiguate.

... had not the variable-radix notation not been introduced.

Another way to disambiguate is to record the value of DTAI
together with a UTC (or TAI) timestamp. Such a method is
standardised in ISO 8601 for denoting offsets from UTC,
but only with minute resolution. I seem to remember that
Clive Feather once proposed this for an extension to the
C programming language.

... where UTC here is taken to be in the usual (fixed-radix) sexagesimal
format.

Mark Calabretta
ATNF

```

Re: The real problem with leap seconds

```   On 2006-01-13, Mark Calabretta wrote:

I have two time scales, TAI and UT1, that tick at very slightly
different rates.  I want to make TAI the basis for civil time keeping
but I need to make adjustments occasionally to keep it in step with
UT1.  How do I do it?

The answer provided by CCIR was to represent TAI in a variable-radix
notation that matches (or appears to match), to within 0.9s, that of
UT1 expressed in the usual calendar/clock format.  This is done by
varying the radix of the seconds field in a pseudo-sexagesimal clock
format from 60 to 61 (or in principle 59) on occasions announced 6

So if asked for a definition I would say that UTC (post 1972) is a
representation of TAI such that ... (you know the rest).

The point is that UTC is simply a representation of TAI.  Writing UTC
as a real reveals it to be TAI.

I believe I'm now grasping what you mean: the rate of UTC is the same
as the rate of TAI (since 1972), that is, the derivative
d( UTC )/d( TAI ) = 1. Hence, when I integrate the ticks of UTC
I must get TAI, up to an integration constant. This is correct.
The integral of d( UTC ) is TAI (up to an integration constant),
but this integral is UTC only where UTC is a continuous function
of TAI.

Astronomers who write UTC as a real (eg, in JD or MJD notation)
want an approximation of UT1 to point their telescopes, they do
_not_ want TAI. They use UTC as a timescale whose values are
close to UT1, but whose rate nevertheless is d( UTC ) = d( TAI )
and not d( UT1 ). Such a function cannot be continuous (and it
cannot be differentiable everywhere). At the latest discontinuity
of UTC, it jumped from a little bit after UT1 to a little bit before
UT1.

Michael Deckers

```

Re: The real problem with leap seconds

```
Michael Deckers wrote:

I believe I'm now grasping what you mean: the rate of UTC is the same
as the rate of TAI (since 1972), that is, the derivative
d( UTC )/d( TAI ) = 1. ...

This conversation is making something of a meal of a simple
point.  You can treat UTC as a real in either of two ways:

If you don't count the leap seconds then the good news is that
days are all 86 400 seconds long but the bad news is that the
real is undefined during the leap second and there's a
discontinuity (or rather, a surprising continuity in that
at some point it's 23:59:59.99 and a whole second and
a tiny bit later it's 00:00:00.).

If you do count the leap seconds then that real is the same
as TAI but the days it's divided up into aren't all 86 400
seconds long.

Sort of like, is it a particle or a wave? :-)

The truth is that UTC only really makes sense as a year,
month, day, hour, minute and second value.  Years have 12
months, months have 28, 29, 30 or 31 days, days have 24
hours, hours have 60 minutes, minutes have 59, 60 or 61
seconds.

The use of the 23:59:60 notation is described in ISO 8601.
Is it also specified in TF.460?  If so, how do they relate
it to the notion of DTAI?

Ed.

```

Re: The real problem with leap seconds

```   On 2006-01-13, Ed Davies wrote:

This conversation is making something of a meal of a simple
point.  You can treat UTC as a real in either of two ways:

If you don't count the leap seconds then the good news is that
days are all 86 400 seconds long but the bad news is that the
real is undefined during the leap second and there's a
discontinuity (or rather, a surprising continuity in that
at some point it's 23:59:59.99 and a whole second and
a tiny bit later it's 00:00:00.).

If you do count the leap seconds then that real is the same
as TAI but the days it's divided up into aren't all 86 400
seconds long.

Sort of like, is it a particle or a wave? :-)

At the risk of being misunderstood as sarcastic: if
users of UTC were really expected to understand such
strange concepts (Schrodinger time) I would plead for the
immediate abolishment of UTC. Why cannot UTC be simply taken as
the reading of a clock that runs at the same rate as TAI and
that is is set back by a second every once in a while?

The truth is that UTC only really makes sense as a year,
month, day, hour, minute and second value.  Years have 12
months, months have 28, 29, 30 or 31 days, days have 24
hours, hours have 60 minutes, minutes have 59, 60 or 61
seconds.

Then why can the IERS express UTC in the MJD notation?

The use of the 23:59:60 notation is described in ISO 8601.
Is it also specified in TF.460?  If so, how do they relate
it to the notion of DTAI?

Yes, it is specified in [ITU-R TF.460-6. Annex 3]:

The dating of events in the vicinity of a leap-second shall be
effected in the manner indicated in the following Figures:

Follow some pictures; for a positive leap second, it looks like:

event
|leap second
+-|---+
| |   |
|  | |   |   |
|  | |   |   |
59 60 0   1
|
---30 June, 23h 59m--|--1 July, 0h 0m

Designation of the date of the event
|
|
|
V
30 June, 23h 59m 60.6s UTC

They also say:

C Coordinated universal time (UTC)

UTC is the time-scale maintained by the BIPM, with assistance from
the IERS, which forms the basis of a coordinated dissemination of
standard frequencies and time signals. It corresponds exactly in
rate with TAI but differs from it by an integer number of seconds.
The UTC scale is adjusted by the insertion or deletion of seconds
(positive or negative leapseconds) to ensure approximate agreement
with UT1.

E DTAI

The value of the difference TAI � UTC, as disseminated with time
signals, shall be denoted DTAI. DTAI = TAI - UTC may be regarded
as a correction to be added to UTC to obtain TAI. The TAI - UTC
values are published in the BIPM Circular T. The IERS should
announce the value of DTAI in integer multiples of one second in
the same announcement as the introduction of a leap-second (see �
D.2).

HTH

Michael Deckers

```

Re: The real problem with leap seconds

```
Michael Deckers wrote:

Sort of like, is it a particle or a wave? :-)

At the risk of being misunderstood as sarcastic: if
users of UTC were really expected to understand such
strange concepts (Schrodinger time) I would plead for the
immediate abolishment of UTC. Why cannot UTC be simply taken as
the reading of a clock that runs at the same rate as TAI and
that is is set back by a second every once in a while?

Not really Schrodinger time - just time which you can usefully
think of in different ways for different purposes.

UTC can be taken the way you suggest most of the time (and
that's clearly the way TF.460 wants to think of it), but it
is then not well defined during the leap second itself.  To
deal with that properly you have to either:

1) think of a count of UTC milliseconds or whatever (including
those in the leap second) which is then the same as TAI or

2) work in separate fields with a 61 second minute.

The truth is that UTC only really makes sense as a year,
month, day, hour, minute and second value.  Years have 12
months, months have 28, 29, 30 or 31 days, days have 24
hours, hours have 60 minutes, minutes have 59, 60 or 61
seconds.

Then why can the IERS express UTC in the MJD notation?

wasn't answered clearly.  MJD 27123.5 means 12:00:00 on day
27123 if it's not a leap second day, but what does it mean
on a day with a positive leap second?  12:00:00.5?  I think
it only works if that level of precision doesn't matter but
maybe some document somewhere has a convention.

Thanks for the further notes from TF.460.

Ed.

```

Re: The real problem with leap seconds

```
Markus Kuhn wrote:

Ed Davies wrote on 2006-01-13 11:45 UTC:

The use of the 23:59:60 notation is described in ISO 8601.
Is it also specified in TF.460?

It originally comes from ITU-R TF.460, which is a standard for radio
time signals.

OK, thanks.

Ed.

```

Re: The real problem with leap seconds

```
I'm glad to see such active traffic on the list - particularly
discussions such as this that are wrestling with fundamental concepts.

On 2006-01-13, Mark Calabretta wrote:

The point is that UTC is simply a representation of TAI.

On Jan 13, 2006, at 4:17 AM, Michael Deckers wrote:

I believe I'm now grasping what you mean:

Have spent many hours wrestling with standards documents written by
M. Calabretta.  The key to understanding what they mean is to
carefully read what is on the page.  Simply a representation is not
an editorial comment like, say, just a representation might be
taken to be.  Representations are important, too.  It is - simply -
not accurate to suggest that UTC is discontinuous at a leap second.
DST is indeed discontinuous twice a year, but the underlying standard
time never is.

Astronomers who write UTC as a real (eg, in JD or MJD notation)
want an approximation of UT1 to point their telescopes, they do
_not_ want TAI.

Astronomers want various flavors of time for various purposes.  It is
indeed exceptionally useful to be able to rely on simple closed form
calculations relating various quantities to universal time, where
UTC is often a sufficiently accurate approximation.  It happens that
we also use TAI and other interval time scales for many things.  And
it turns out that our images and other data products often benefit
from the use of civil time stamps for which good old reliably
continuous UTC serves admirably.  Ultimately it is the risk to this
last category of use cases that concerns me most about the notion of
leap hours.

That said, I suspect M. Deckers and M. Calabretta could productively
collaborate on a document synthesizing the fundamental issues into a
common vision.  Or perhaps somebody is aware of such a document that

Rob

```

Re: The real problem with leap seconds

```
On Jan 13, 2006, at 8:05 AM, Ed Davies wrote:

MJD 27123.5 means 12:00:00 on day 27123 if it's not a leap second
day, but what does it mean on a day with a positive leap second?
12:00:00.5?

And we're back to the point in question.  The precise issue is the
definition of the concept of a day.  A leap second itself is a
clearly defined moment in time.

```

Re: The real problem with leap seconds

``` We've recently had a question about this on this list which
wasn't answered clearly.  MJD 27123.5 means 12:00:00 on day
27123 if it's not a leap second day, but what does it mean
on a day with a positive leap second?  12:00:00.5?  I think
it only works if that level of precision doesn't matter but
maybe some document somewhere has a convention.

I'm not the expert, but I just read through

http://en.wikipedia.org/wiki/Julian_day

and from what I learned there the answer appears to be that MJD can be
either MJD(UT) or MJD(TT), and leap seconds are not involved.  So MJD
27123.5 means 12:00:00. on day 27123.

MJD(UT) 27123.5 means UT 12:00:00.0 on day 27123.

MJD(TT) 27123.5 means TT 12:00:00.0 on day 27123.

UTC is an approximation of UT, perhaps the poorest one in the family
of UT time scales. If you care about what time it is UT to better
than one second, then UTC is probably not the right time scale for you
to be using (at least not directly).

If a fuzz of +/- 1 second doesn't bother you, then you can pretend
that UTC is UT, and things are easier.

For the time scale experts on this list, did I get that right?

-Tim Shepard
[EMAIL PROTECTED]

```

Re: The real problem with leap seconds

```   On 2006-01-13, Ed Davies wrote:

Michael Deckers wrote:

. Why cannot UTC be simply taken as
the reading of a clock that runs at the same rate as TAI and
that is is set back by a second every once in a while?

UTC can be taken the way you suggest most of the time (and
that's clearly the way TF.460 wants to think of it), but it
is then not well defined during the leap second itself.  To
deal with that properly you have to either:

1) think of a count of UTC milliseconds or whatever (including
those in the leap second) which is then the same as TAI or

2) work in separate fields with a 61 second minute.

Right, UTC timestamps are ambiguous (in the sense that the
corresponding TAI value is not known) in the vicinity of
positive leap seconds, and the notation with a second
field = 60 s is one (elegant) way to disambiguate.

Another way to disambiguate is to record the value of DTAI
together with a UTC (or TAI) timestamp. Such a method is
standardised in ISO 8601 for denoting offsets from UTC,
but only with minute resolution. I seem to remember that
Clive Feather once proposed this for an extension to the
C programming language.

If you only need an approximation to UT1, however, there
is no need to disambiguate, nor is it relevant which value
of DTAI is applied during the leap second.

Thanks for your patience.

Michael

```

Re: The real problem with leap seconds

```From: Ed Davies [EMAIL PROTECTED]
Markus Kuhn wrote:
Ed Davies wrote on 2006-01-13 11:45 UTC:

The use of the 23:59:60 notation is described in ISO 8601.
Is it also specified in TF.460?

It originally comes from ITU-R TF.460, which is a standard for radio
time signals.

OK, thanks.

Has anybody compiled a canonical list of the standards in this area?
This is the first, I think I've seen ISO 8601 mentioned.

TF.460 doesn't talk about days at all, really, or MJD.  It doesn't
talk about rendering a time a floating point number, only as the
traditional sexagesimal fractional time, with the 'execption' during
the positive leap second.

If we explore the orgins of the time
12:34:56 (just after noon)
we note that it is in the 13th 1/24th division of a day (since the 0th
(aka 12) hour is first), the 35th 1/60th division of the 1/24th
division (since the first one is 0) and the 56th 1/60th division of
the 1/60th division of the 1/24th division a day.  Labeling the
positive leap second as
23:59:60
leads to some trouble if we try to work backwards through the above
derivation.  It creates an exception to the nice, orderly rules of
time.  But I'm digressing...

The ITU-R TF.460 states:

2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s
of the first day of the following month. In the case of a negative
leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s
of the first day of the following month (see Annex III).

2.3 The IERS should decide upon and announce the introduction of a
leap-second, such an announcement to be made at least eight weeks in

In Annex III, it talks about the dating of events during the positive
leap second.  If something were to happen .6s into that second, it
would be denoted (assuming a june leap) as:

30 June, 23h 59m 60.6s UTC

(the document has h, m and s superscripted, and the European (?) style
centered decimal point)

Warner

```

Re: The real problem with leap seconds

```
I don't know about a canonical list, but one standard document that is used
within NASA is CCSDS 301.0-B-3, which is available from the Consultative
Committee on Space Data Systems website at

http://public.ccsds.org/publications/BlueBooks.aspx

This standard references ISO-8601, and is partially based on it.

Bill Thompson

Warner Losh wrote:

From: Ed Davies [EMAIL PROTECTED]

Markus Kuhn wrote:

Ed Davies wrote on 2006-01-13 11:45 UTC:

The use of the 23:59:60 notation is described in ISO 8601.
Is it also specified in TF.460?

It originally comes from ITU-R TF.460, which is a standard for radio
time signals.

OK, thanks.

Has anybody compiled a canonical list of the standards in this area?
This is the first, I think I've seen ISO 8601 mentioned.

TF.460 doesn't talk about days at all, really, or MJD.  It doesn't
talk about rendering a time a floating point number, only as the
traditional sexagesimal fractional time, with the 'execption' during
the positive leap second.

If we explore the orgins of the time
12:34:56 (just after noon)
we note that it is in the 13th 1/24th division of a day (since the 0th
(aka 12) hour is first), the 35th 1/60th division of the 1/24th
division (since the first one is 0) and the 56th 1/60th division of
the 1/60th division of the 1/24th division a day.  Labeling the
positive leap second as
23:59:60
leads to some trouble if we try to work backwards through the above
derivation.  It creates an exception to the nice, orderly rules of
time.  But I'm digressing...

The ITU-R TF.460 states:

2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s
of the first day of the following month. In the case of a negative
leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s
of the first day of the following month (see Annex III).

2.3 The IERS should decide upon and announce the introduction of a
leap-second, such an announcement to be made at least eight weeks in

In Annex III, it talks about the dating of events during the positive
leap second.  If something were to happen .6s into that second, it
would be denoted (assuming a june leap) as:

30 June, 23h 59m 60.6s UTC

(the document has h, m and s superscripted, and the European (?) style
centered decimal point)

Warner

--
William Thompson
NASA Goddard Space Flight Center
Code 612.1
Greenbelt, MD  20771
USA

301-286-2040
[EMAIL PROTECTED]

```

Re: The real problem with leap seconds

```Yes: there is an order on the set of values of timescales -
it is a basic property of spacetime models that one can distinguish
past and present, at least locally. Spacetime is a differentiable
4-dimensional manifold, its coordinate functions are usually two
times differentiable or more. In particular, the set of values of
timescales does indeed have a topology (which is Hausdorff).

Sure - this is a reasonable definition of timescale, but I don't
think it is wide enough to include UTC. As I understand it, and
everyone will correct me if I'm wrong, UTC is not intended to be
directly related to spacetime coordinates at all. UTC is (currently)
an aproximation to the direction the earth is facing and is adjusted
according to how long it takes the earth to end up facing the same
direction again.

All of this is completely independent from the choice of a particular
calendar or of the time units to be used for expressing timescale values.

I'd agree with this for TAI (including that it should be the integral
of a nice 1-form), but I'm not so sure for UTC.

If you subtract a time from a timescale value, you get another
timescale value. If you mean to say that UTC takes its values in a
different space than TAI then you cannot agree with UTC = TAI - DTAI,
as in the official definition of UTC. And if you say that
UTC - TAI can be discontinuous (as a function of whatever)
with both UTC and TAI continuous then you must have a subtraction that
is not continuous. Strange indeed. Where did I misinterpret your post?

Yep - you've picked up my intent correctly. I'm saying that subtraction
is a stange operator taking a UTC value and a TAI value and gives
you something that's a real number.

The reason that I came to this conclusion is because none of the
documents I've read say that UTC can be expressed as a real number
- they all suggest it is expressed as labelled seconds. (For example,
see the way that Rec. 460-4 gives UTC values - I've never seen an
official looking document that tries to write UTC as a real.)

David.

```

Re: The real problem with leap seconds

```   On 2006-01-10, Mark Calabretta wrote:

I can't let this one pass - UTC is continuous and monotonic.  In fact,
ignoring differences in origin, UTC = TAI.  Surprised?  If so then
you're confusing a quantity with its representation (though in good
company in doing so).

I do not understand. As a function of TAI, UTC is neither continuous
nor monotone increasing in the mathematical sense.

In the defining document, [ITU-R TF.460-6], UTC is given as
UTC = TAI - DTAI
where DTAI is a step function of TAI assuming as values only integral
multiples of 1 s. Unless constant, such a function is not continuous
on a connected domain in the mathematical sense. Hence, UTC is not
a continuous function of TAI.

At some instant when TAI took a value in the positive leap second between
2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s
(the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped
from 32 s to 33 s; thus, UTC is not a monotone increasing function of
TAI either.

Perhaps you consider UTC as a function of something other than TAI where
it may well be continuous or monotone (eg, as a function of itself, UTC
trivially is both continuous and monotone).

Reference:
[ITU-R TF.460-6] Recommendation ITU-R TF.460-6
Standard-frequency and time-signal
emissions. 2002 Geneva.

Michael Deckers

```

Re: The real problem with leap seconds

```[A lot of discussion on this list seem to revolve around people
understanding terms in different ways. In an impractical example
of that spirit...]

I do not understand. As a function of TAI, UTC is neither continuous
nor monotone increasing in the mathematical sense.

To say if TAI is a monotone function of UTC, you need to put an
order on the set of possible TAI and UTC values. To say if UTC is
a continious function of TAI, you need to put a topology on both.

To me, TAI seems to be a union of copies of [0,1) labelled by
YEAR-MM-DD HH:MM:SS where you glue the ends together in the obvious
way and SS runs from 00-59. You then put the obvious order on it
that makes it look like the real numbers.

OTOH, UTC seems to be a union of copies of [0,1) labelled by
YEAR-MM-DD HH:MM:SS where SS runs from 00-60. You glue both the end
of second 59 and 60 to the start of the next minute, in adition to
the obvious glueing.

I haven't checked all the details, but seems to me that you can put
a reasonable topology and order on the set of UTC values that
will make UTC a continious monotone function of TAI. The topology
is unlikely to be Hausdorf, but you can't have everything.

DTAI jumped
from 32 s to 33 s; thus, UTC is not a monotone increasing function of
TAI either.

Since DTAI involves subtracting quantities that aren't real numbers,
you can't conclude that a discontinuity in DTAI results in a
discontinuity in UTC.

David.

```

Re: The real problem with leap seconds

```On 11 Jan 2006 at 0:08, Tim Shepard wrote:

If humans spread out to other places besides the earth, an
earth-centric time scale might begin to seem somewhat quaint.
Distributing leap second information to a Mars colony seems kind of
silly.

As I recall, the NASA Mars missions are using Mars-centric time
scales, which include a Martian second that has a different length
from the SI second in order for the different-length Martian day
(called a Sol) to be subdivided into a familiar 24 hours composed
of 60 minutes each with 60 seconds.

If, however, this Martian second is actually defined as a particular
multiple of the SI second, then the use of leap seconds on Mars would
ultimately be necessary to account for any future changes in the
length of the Martian day.

--
== 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: The real problem with leap seconds

```On Wed 2006-01-11T09:01:07 -0500, Daniel R. Tobias hath writ:
If, however, this Martian second is actually defined as a particular
multiple of the SI second, then the use of leap seconds on Mars would
ultimately be necessary to account for any future changes in the
length of the Martian day.

The martian second in their case is defined purely for the sake of the
local solar time of the solar powered rovers which are effectively
stationary on the planet.  Something akin to the long-used Newcomb
expression for mean solar time is more than sufficient.  In that
respect the rovers are sundials.

The mission clock on the lander has a more uniform time scale used for
the sake of such things as the cool photos of the martian moons
transiting the sun.

Leap seconds for Mars seem irrelevant until there are VLBI antennae on
Mars performing routine observations.  The atomic clocks used by such
VLBI antennae will not, however, keep synchronized with earth using
anything less than a fully general relativistic expression for the
intercomparisons.

--
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: The real problem with leap seconds

```   On 2006-01-11, David Malone wrote:

[A lot of discussion on this list seem to revolve around people
understanding terms in different ways. In an impractical example
of that spirit...]

Anyway: excuse me for repeating some basics of classical mechanics;
but I believe it to be necessary.

To say if TAI is a monotone function of UTC, you need to put an
order on the set of possible TAI and UTC values. To say if UTC is
a continuous function of TAI, you need to put a topology on both.

Yes: there is an order on the set of values of timescales -
it is a basic property of spacetime models that one can distinguish
past and present, at least locally. Spacetime is a differentiable
4-dimensional manifold, its coordinate functions are usually two
times differentiable or more. In particular, the set of values of
timescales does indeed have a topology (which is Hausdorff).

To me, TAI seems to be a union of copies of [0,1) labelled by
YEAR-MM-DD HH:MM:SS where you glue the ends together in the obvious
way and SS runs from 00-59. You then put the obvious order on it
that makes it look like the real numbers.

TAI is determined as a weighted mean of the (scaled) proper times
measured by an ensemble of clocks close to the geoid - so the
values of TAI must belong to the same space as these proper times,
which (being line integrals of a 1-form) take their values in the
same space as the time coordinates of spacetime (such as TCB and TCG).
No gluing is needed. And yes: this space is diffeomorphic to the
real line.

All of this is completely independent from the choice of a particular
calendar or of the time units to be used for expressing timescale values.

OTOH, UTC seems to be a union of copies of [0,1) labelled by
YEAR-MM-DD HH:MM:SS where SS runs from 00-60. You glue both the end
of second 59 and 60 to the start of the next minute, in adition to
the obvious glueing.

I haven't checked all the details, but seems to me that you can put
a reasonable topology and order on the set of UTC values that
will make UTC a continious monotone function of TAI. The topology
is unlikely to be Hausdorf, but you can't have everything.

If you subtract a time from a timescale value, you get another
timescale value. If you mean to say that UTC takes its values in a
different space than TAI then you cannot agree with UTC = TAI - DTAI,
as in the official definition of UTC. And if you say that
UTC - TAI can be discontinuous (as a function of whatever)
with both UTC and TAI continuous then you must have a subtraction that
is not continuous. Strange indeed. Where did I misinterpret your post?
And can you give some reference for your assertions?

Michael

```

Re: The real problem with leap seconds

```On Wed 2006/01/11 10:47:25 -, Michael Deckers wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

At some instant when TAI took a value in the positive leap second between
2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s
(the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped
from 32 s to 33 s; thus, UTC is not a monotone increasing function of
TAI either.

Here in a topology-free way is what the axis labels of my graph look
like during the said leap second insertion:

UTC axisTAI axis DTAI
2005/12/31 23:59:58 2006/01/01 00:00:3032
2005/12/31 23:59:59 2006/01/01 00:00:3132
2005/12/31 23:59:60 2006/01/01 00:00:3232
60.932.9  32
60.99   32.99 32
60.999...   32.999... 32
2006/01/01 00:00:00 2006/01/01 00:00:3333
2006/01/01 00:00:01 2006/01/01 00:00:3433

The seconds keep step and the graph has no gaps, jumps or kinks.

The only difference between UTC and TAI is one of representation, like
the current year which may be represented as 2006 or MMVI but it's still
the same year.

Mark Calabretta
ATNF

```

Re: The real problem with leap seconds

```In message: [EMAIL PROTECTED]
Mark Calabretta [EMAIL PROTECTED] writes:
: On Wed 2006/01/11 10:47:25 -, Michael Deckers wrote
: in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
:
:At some instant when TAI took a value in the positive leap second between
:2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s
:(the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped
:from 32 s to 33 s; thus, UTC is not a monotone increasing function of
:TAI either.
:
: Here in a topology-free way is what the axis labels of my graph look
: like during the said leap second insertion:
:
: UTC axisTAI axis DTAI
:2005/12/31 23:59:58 2006/01/01 00:00:3032
:2005/12/31 23:59:59 2006/01/01 00:00:3132
:2005/12/31 23:59:60 2006/01/01 00:00:3232
: 60.932.9  32
: 60.99   32.99 32
: 60.999...   32.999... 32
:2006/01/01 00:00:00 2006/01/01 00:00:3333
:2006/01/01 00:00:01 2006/01/01 00:00:3433
:
: The seconds keep step and the graph has no gaps, jumps or kinks.

Shouldn't the DTAI increment for the leap second?  That's the point of
the leap second...  Or is that only needed when you do the POSIX
time_t thing of repeating 59?

In computer science, regular things are easy.  Irregular ones are hard
and prone to errors.  The :60 kludge makes a regular 1-1 mapping
function for time into a table driven nightmare :-(.

: The only difference between UTC and TAI is one of representation, like
: the current year which may be represented as 2006 or MMVI but it's still
: the same year.

The point isn't that one can construct a 'second labelling' that is
unambiguous, monotonic and increasing, but rather that when one
distills the UTC time down to a single number, you necessarily have
ambiguities and discontinuties in that function.  Of course there's an
implicit assumption that the conversion function is the same as
POSIX's time_t, otherwise you would be using TAI or a count of actual
seconds.  We call it PPSes or pulses at work to distinguish it.  We
label UTC time as having leap seconds swizzled in, and TAI time as
unswizzled.

Warner

```

Re: The real problem with leap seconds

```On Wed 2006/01/11 20:58:25 PDT, M. Warner Losh wrote
in a message to: [EMAIL PROTECTED]
and copied to: LEAPSECS@ROM.USNO.NAVY.MIL

: 60.999...   32.999... 32
:2006/01/01 00:00:00 2006/01/01 00:00:3333
:2006/01/01 00:00:01 2006/01/01 00:00:3433
:
: The seconds keep step and the graph has no gaps, jumps or kinks.

Shouldn't the DTAI increment for the leap second?

It goes from 32 to 33 at precisely 2006/01/01 00:00:00 (UTC) (or at
precisely 2006/01/01 00:00:33 (TAI) if you prefer), as shown in the
above table.

Refer to the last page of the current IERS Bulletin A, Vol. XIX No. 1,
ftp://maia.usno.navy.mil/ser7/ser7.dat, which says the same as above
though in a little less detail.

That's the point of
the leap second...  Or is that only needed when you do the POSIX
time_t thing of repeating 59?

My comments on discontinuity etc. do not apply to time_t which is not
the same thing as UTC.

In computer science, regular things are easy.  Irregular ones are hard
and prone to errors.  The :60 kludge makes a regular 1-1 mapping
function for time into a table driven nightmare :-(.

It sure does.

The point isn't that one can construct a 'second labelling' that is
unambiguous, monotonic and increasing, but rather that when one
distills the UTC time down to a single number, you necessarily have
ambiguities and discontinuties in that function.

time_t has ambiguities and discontinuties, but that is not a necessary
consequence of leap seconds.  To their credit the CCIR did not stuff up
in specifying the clock notation to be used for UTC.

Mark Calabretta
ATNF

```

Re: The real problem with leap seconds

```On Mon, 9 Jan 2006, Tim Shepard wrote:

wot, no attribution of quotes?
and you still cannot even get it [TAI] reliably from your

I still think NTP should have distribute TAI, but I understand using

Was your failure to form a past-participle a Freudian slip? I'm with you
if you really mean NTP should distribute TAI!!!

Pete.

```

Re: The real problem with leap seconds

```  I still think NTP should have distribute TAI, but I understand using

Was your failure to form a past-participle a Freudian slip? I'm with you
if you really mean NTP should distribute TAI!!!

Uh, probably yes.  I didn't even see the grammer error when I re-read
it the first time just now.

About 15 years ago I came to believe that it would have been better if
NTP distributed TAI instead of (or perhaps alongside) UTC.

And yes, I still believe that.

Now I think it would be best if TAI and UTC were both distributed by
time signals (and NTP, etc), with equal emphasis to make it clear to
all users that they have a choice to make.

Atomic time based on the SI second (TAI) and traditional time based on
earth orientation (UT) are both needed in the modern world.  Both
should be distributed.  People who have some need to synchronize
clocks should be forced to decide which kind of time would be best for
them.  (Or perhaps in some cases it would be best for them to
implement both side-by-side in their system.)

A system which distributes TAI (which never has leap seconds) and also
distributes the current number of seconds of offset for UTC, as well
as leap warnings (or continuously broadcasts the table of all known
(past and scheduled) leap seconds), would seem to be reasonable.

This would allow the decisions about what would be the best time scale
to use to be made downstream.  Build good mechanisms that allow a
variety of policies, and leave policies to those downstream of you.

My preference would be for civil time keeping to continue to be tied
to earth orientation, as it was when GMT was the standard.  So UT1 or
UTC would continue to be normal time, and TAI (or something like it)
would be the weird time that certain geeks care about.

The other alternative would be for civil timekeeping to be based on
TAI (something which never has leap seconds), with UTC (or something
like it) to be the weird time that certain geeks care about.  This
is the radical proposal, but I can understand that some would want to
do this.

If humans spread out to other places besides the earth, an
earth-centric time scale might begin to seem somewhat quaint.
Distributing leap second information to a Mars colony seems kind of
silly.  (Though I guess that those on a Mars colony would in fact care
about earth orientation, e.g. if they wished to communicate with
friends back on Earth using their amateur laser-communication gear in
their backyards.)

I very much dislike the proposal to *redefine* UTC to abolish leap
seconds.  I dislike very much trying to understand code that was
written with descriptive names (for variables, functions, constants,
etc) but which has evolved such that what the names apparently mean
and what they really mean are very different.  UTC is a type of UT
time.  If you stop putting leap seconds in UTC to keep it close to all
the other UT time scales, then it no longer deserves to have a name
that starts with UT.

So fine, if we must stop maintaining UTC with leap seconds and move
civil time keeping users to some sort of new standard, please do *not*
call it UTC after the change.

The hack of having UTC ticks align with TAI ticks and adjusting UTC
with leap seconds was perhaps not the best idea.  But it was done, and
has been in place for more than 30 years, and is now a widely
implemented and understood standard.  If this hack should be replaced
with something better (and perhaps it should be), I'd want 20 years
advance notice that a change is coming, and 15 years advance notice as
to what exactly the change will be.  (I suspect though I won't get
that much notice.)

leap hours are a horrible idea, whether they be leap hours inserted
in to some UTC-like global standard, or by local jurisdictions.

Well, those are my opinions.   Thanks for listening.

-Tim Shepard
[EMAIL PROTECTED]

```

Re: The real problem with leap seconds

```Tim Shepard scripsit:

[many sensible opinions snipped]

leap hours are a horrible idea, whether they be leap hours inserted
in to some UTC-like global standard, or by local jurisdictions.

I understand what's wrong with the former kind, but what's wrong with
the latter?  Why do you think they are more of a problem than DST shifts?

--
Andrew Watt on Microsoft:   John Cowan
Never in the field of human  computing  [EMAIL PROTECTED]
has so much been paid by so manyhttp://www.ccil.org/~cowan
to so few! (pace Winston Churchill) http://www.reutershealth.com

```

Re: The real problem with leap seconds

```In message [EMAIL PROTECTED], Clive D.W. Feather writes:

The real problem is not the 23:59:60, it's *predicting* when they happen.

I agree, the short prediction horizon is the major problem.

But 23:59:60 _is_ a problem too.

I don't think anybody dare even think about redefining POSIX time_t
and even if they did redefine it to contain leap-seconds, many tons
of software wouldn't be updated/recompiled to take advantage of it.

So the standards crew, POSIX, LSB or whoever would have to come up
with a new data type for holding timestamps, and while a number of
proposals have been floated over the years, none of them seem to
contain any real clue, so I don't think this is likely to happen.

But pressume for a moment that they did come up with a new standard,
the many tons of software would still not be rewritten to take
advantage of it, so we'd still be stuck with time_t's ostrich
behaviour for the forseeable future.

Unlikely as it is, it would allow people like Warner and me to write
software that Do The Right Thing.

A far more sensible idea is to just forget about leap-seconds from
now on, leave DUT1 to wander, tell BIPM/IERS to provide a contemporary
kind of service (internet services instead of handwritten letters),
the astronomers to shut upcope and leaving the issue of the length
of day in 500 years to the people who live 500 years from now on.

It's the comparison between educating all programmers in the world
vs having the astronomers use a DUT which is larger than 1 second.

There is no doubt that from a humanistic point of view it would be
better to educate all the programmers, but considering that I still
suffer from web-forms that insist I enter a USA style phone number
when I have entered Denmark as country, this is a far moure
daunting task than it might appear.

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: The real problem with leap seconds

```I wrote:
Right now, the DTAI(TAI) function is the sum of a set of Kroneker delta
functions.

Thanks to David for quietly pointing out that I meant Heaviside step
functions, not Kroneker delta functions.

--
Clive D.W. Feather  | Work:  [EMAIL PROTECTED]   | Tel:+44 20 8495 6138
Internet Expert | Home:  [EMAIL PROTECTED]  | Fax:+44 870 051 9937
Demon Internet  | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc||

```

Re: The real problem with leap seconds

```In message [EMAIL PROTECTED], Peter Bunclark writes:
On Mon, 9 Jan 2006, Poul-Henning Kamp wrote:

I don't think anybody dare even think about redefining POSIX time_t

I wish people would stop making positive assertions about what other
people are bound to think.  What you mean in is, YOU are against
suggesting changing (or augmenting) POSIX time.

No, I mean exactly what I wrote: I don't think anybody dare even
think about redefining POSIX time_t

The reason I mean that is that I've talked to a lot of the relevant
people and they're all totally morified about the consequences
of (time_t % 86400) not giving you the time of day.

Remember, most of these people are even afraid to extend time_t to
64 bits because of the possible fall-out :-(

--
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: The real problem with leap seconds

```Poul-Henning Kamp said:
So the standards crew, POSIX, LSB or whoever would have to come up
with a new data type for holding timestamps,

We already have one: struct tm.

There is no doubt that from a humanistic point of view it would be
better to educate all the programmers, but considering that I still
suffer from web-forms that insist I enter a USA style phone number
when I have entered Denmark as country, this is a far moure
daunting task than it might appear.

Amen.

[I happen to have a US Social Security number, which allows me to confuse
some web pages back.]

--
Clive D.W. Feather  | Work:  [EMAIL PROTECTED]   | Tel:+44 20 8495 6138
Internet Expert | Home:  [EMAIL PROTECTED]  | Fax:+44 870 051 9937
Demon Internet  | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc||

```

Re: The real problem with leap seconds

```M. Warner Losh wrote on 2006-01-09 16:57 UTC:
There's been many many many people that have tried to fix POSIX time_t.

One person's fix is another person's recipe for disaster ...

The POSIX definition of time_t is not quite as broken as some
individuals would like you to believe. It actually does its job very
well, especially out there in the real world, where UTC is easily and
reliably available from many, many, independent channels. The same
surely could not (and probably still cannot) be said for TAI and for
automatic leap-second table updates. You cannot get TAI from the BBC
evening news, and you still cannot even get it reliably from your
average local NTP server.

(I know, we've already discussed this here, on [EMAIL PROTECTED], on
pasc-time-study, and on austin-group-l in *very* great detail, many,
many, many times, so I'll stop.)

Markus

--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain

```

Re: The real problem with leap seconds

```From: Markus Kuhn [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] The real problem with leap seconds
Date: Mon, 09 Jan 2006 19:12:05 +

M. Warner Losh wrote on 2006-01-09 16:57 UTC:
There's been many many many people that have tried to fix POSIX time_t.

One person's fix is another person's recipe for disaster ...

True.  All the fixes are worse than the disease.  However, let us not
forget that the disease is still bad.

The POSIX definition of time_t is not quite as broken as some
individuals would like you to believe. It actually does its job very
well, especially out there in the real world, where UTC is easily and
reliably available from many, many, independent channels.

True.

The same
surely could not (and probably still cannot) be said for TAI and for
automatic leap-second table updates. You cannot get TAI from the BBC
evening news, and you still cannot even get it reliably from your
average local NTP server.

False.  Leap second tables are readily available.  Current offset
between UTC and TAI is generally available (or computable) from many
time broadcasts (although not all).

(I know, we've already discussed this here, on [EMAIL PROTECTED], on
pasc-time-study, and on austin-group-l in *very* great detail, many,
many, many times, so I'll stop.)

POSIX's time_t is broken.  Very broken.  It is broken accross leap
seconds, and other times.  It is convenient because one can get a
decent notion of UTC from many places.  However, it is equally easy to
get a notion of TAI time as well, with very minimal effort.  One can
easily look on IERS' web page, or download the current leap second
table from ftp://time.nist.gov/pub/leap-seconds.list with very minmal
effort.

When you have a leap second table, you can run in TAI and compute
intervals correctly.  When you don't have a leap second table, you can
run in UTC, but cannot compute intervals correctly (accross leap
seconds).  Which set of problem do you want to have?  The answer will
very much depend on how connected you are and what the negative
consequences are of computing time intervals wrong are.  My
applications tend to be unconnected with big consequences if intervals
are computed wrong, which is the worst of both worlds.

Anyway, time_t is like goto.  Sure, you can use it.  Sure it usually
won't get you into trouble, but it is being badly abused and that
abuse causes real problems for people that care about accuracy.

Warner

```

Re: The real problem with leap seconds

```In message [EMAIL PROTECTED], Markus Kuhn writes:

and you still cannot even get it reliably from your
average local NTP server.

This is a circular argument:  The reason NTP doesn't provide it
is that time_t needs UTC.

--
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: The real problem with leap seconds

``` and you still cannot even get it [TAI] reliably from your
average local NTP server.

This is a circular argument:  The reason NTP doesn't provide it
is that time_t needs UTC.

No, I asked David Mills about 15 or so years ago why NTP distributes
UTC and not TAI (me thinking and suggesting that it would have been so
much better if NTP distributed TAI) and the reason was quite simple:

There was no convenient way to get TAI.  The time signals broadcast by
WWV and WWVB in the US distributed UTC and leap warning bits, but did
not distribute (and still do not AFAIK) what the TAI offset is.

GPS receivers were (very) rare back then, so getting GPS time and
subtracting out the constant offset to get back to TAI was not a
viable option either (though perhaps it would be today, as long as the
GPS system keeps running).

I still think NTP should have distribute TAI, but I understand using
TAI was not practicable option when NTP was designed.

BTW, I don't know if the Fuzzball OS had any Posix time_t's in it, or
anything resembling them, but I suspect not.  I vaguely recall hearing
that it had some other way of keeping the time in a collection of
16-bit registers (PDP-11s, don't you know).

-Tim Shepard
[EMAIL PROTECTED]

```

Re: The real problem with leap seconds

```On Mon 2006/01/09 10:01:27 -, Clive D.W. Feather wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

I've just read through the email that has accumulated on this list since
before xmas - impressive volume!  Why not devote a fraction of that time
and energy to producing a formal position paper.

You've expressed it very badly in the article.

...and you've expressed this rather tactlessly!

The problem is not that UTC
can't be expressed as a real number. Rather (and you do sort of say this,
just not very well), the function UTC(TAI) is not continuous and monotonic.

I can't let this one pass - UTC is continuous and monotonic.  In fact,
ignoring differences in origin, UTC = TAI.  Surprised?  If so then
you're confusing a quantity with its representation (though in good
company in doing so).

First consider a graph of a person's age versus calendar date with a
precision of 1 day.  The fields in calendar dates are mixed-radix, the
day field is also variable-radix depending on the month, and for
February the year, so how should we plot the calendar axis?  Simple, do
it as a count of days and then label it with year, month and day-of-
month; Feb/29 in leap years comes out in the wash.  As expected, the
graph is a continuous straight line of slope 1 - no breaks, no kinks -
the person doesn't age in fits and starts!

Now consider extending this graph to sub-second precision, accounting
for leap seconds, with age to be measured in TAI and calendar date in
UTC.  Now the date axis must be constructed as a count of seconds of UTC
(SI seconds, same as TAI) measured from birth.  As before label the date
axis using conventional calendar/clock notation.  The graph is still a
continuous straight line of slope 1 (no breaks, no kinks).  Leap seconds
are labelled as 23:59:60 - that is the formal representation, each
second of UTC has a unique label as required for mathematical validity.
(Note that it is incorrect to repeat the seconds count at 59, 00, 01 or
anywhere else, even though that may be required on clock displays for
practical reasons.)

Doing arithmetic on UTC using clock notation is like doing arithemetic
on calendar dates or with numbers using Roman numerals.  The principle
difference is that leap days follow a set rule and computations
involving future times can be performed, whereas leap seconds do not
follow a set rule and computations cannot be performed into the future.

I am reminded of a discussion concerning the curious repetition of
1828 in e = 2.718281828...  Simply reexpress the number in base 2,
base e, or something else; the pattern disappears.

Mark Calabretta
ATNF

```

Re: The real problem with leap seconds

```On Mon 2006/01/09 10:38:54 -, Peter Bunclark wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

I't be interesting to do an FFT on this list, and see if some of the
contributers actually ever sleep, or do any other work...

I had the same thought - the moreso when I reflect on the nil response
to my request for a counter-presentation at ADASS.

(What sort of FFT did you have in mind?)

Cheers, Mark

```

Re: The real problem with leap seconds

```
Wow, things have got really stirred up around here.  Lots of interesting
points but I'll just concentrate on one...

Poul-Henning Kamp wrote:

Well, the BIPM doesn't really want anybody to use TAI, their director
said as much last year, and I can see where he is coming from on that
one.

Since the usual response of the pro-leap second lobby to people
who want a uniform timescale is use TAI this is significant.
Do you have any information or references on why the BIPM director
said this?

Ed.

```

Re: The real problem with leap seconds

```In message [EMAIL PROTECTED], Ed Davies writes:
Wow, things have got really stirred up around here.  Lots of interesting
points but I'll just concentrate on one...

Poul-Henning Kamp wrote:
Well, the BIPM doesn't really want anybody to use TAI, their director
said as much last year, and I can see where he is coming from on that
one.

Since the usual response of the pro-leap second lobby to people
who want a uniform timescale is use TAI this is significant.
Do you have any information or references on why the BIPM director
said this?

As I understood it, it was mainly that TAI is a post-factum postal
timescale.

--
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: The real problem with leap seconds

```
On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote:

As I understood it, it was mainly that TAI is a post-factum
postal timescale.

One is left pondering the fact that UTC is now (and would remain
under any changes I've heard suggested) a time scale based on TAI.
What magic makes one acceptable and the other not?

```

Re: The real problem with leap seconds

```In message [EMAIL PROTECTED], Steve Allen writes:
On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ:
Well, the BIPM doesn't really want anybody to use TAI, their director
said as much last year

The Italian contribution to the November 2005 WP7A meeting could be
interpreted a suggestion that the international agencies in charge of
time scales need to get their heads together, pick one time scale with
no discontinuities, and abolish all others.

That sounds like the sensible partys platform to me.

Doing so would once and for all have to divorce earth orientation
from that unified time scale, leaving it to governments to align
civil time with daylight as they see fit (just like today).

Klepczynski had implied that more clearly on pages 322 and 323 of
http://tycho.usno.navy.mil/ptti/ptti2004/panel.pdf
where he discusses getting all the satellite navigation systems
to use a single time scale.

It is the time scale that is the issue, it's the clock offset between
the systems.

If you have 2 GPS sats, one GLONASS and one GALILEO, you also need
to know the clock offsets between the three systems before you can
calculate a position.

If everybody gets their act together and hold the clock offsets small,
then it would be a wonderful world indeed, but I think the practical,
organizational and political problems will prevent that.

The other option is for the systems to broadcast their clock offsets
relative to the other systems.  For that to help rapid first fix
it must be a frequent broadcast (ie: non-almanac) otherwise you
might as well just wait until you get four birds in one system.

(And to see that psychology is not just relevant to astronomers,
read Matsakis on page 336.)

Yes, astronomers have psychology too, but the comments on that page
has nothing to do with leap seconds at all.

--
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: The real problem with leap seconds

```In message [EMAIL PROTECTED], Rob Seaman writes:
On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote:

As I understood it, it was mainly that TAI is a post-factum
postal timescale.

One is left pondering the fact that UTC is now (and would remain
under any changes I've heard suggested) a time scale based on TAI.
What magic makes one acceptable and the other not?

I didn't say I thought the protest against more widespread use
made sense, I merely tried to relay it faithfully.

I does sound consistent with previously mentioned old fashionedness.

--
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: The real problem with leap seconds

```In message: [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:
: In message [EMAIL PROTECTED], Ed Davies writes:
: Wow, things have got really stirred up around here.  Lots of interesting
: points but I'll just concentrate on one...
:
: Poul-Henning Kamp wrote:
:  Well, the BIPM doesn't really want anybody to use TAI, their director
:  said as much last year, and I can see where he is coming from on that
:  one.
:
: Since the usual response of the pro-leap second lobby to people
: who want a uniform timescale is use TAI this is significant.
: Do you have any information or references on why the BIPM director
: said this?
:
: As I understood it, it was mainly that TAI is a post-factum postal
: timescale.

How is it that UTC can be realized in realtime, but TAI isn't.  I
thought the difference between the two was an integral number of
seconds, by definition.  Is that understanding flawed?

Wanrer

```

Re: The real problem with leap seconds

```On Sun 2006-01-08T11:44:04 -0700, M. Warner Losh hath writ:
How is it that UTC can be realized in realtime, but TAI isn't.  I
thought the difference between the two was an integral number of
seconds, by definition.  Is that understanding flawed?

I believe the claim would be that UTC(insert your national time
service here) is realized in real time.  UTC(USNO) is the official
time of the US, and I suspect that there would be loss of face if
any agency charged with keeping a national time did not, in some
sense, proclaim autonomy.  UTC(pick one) is, of course, directly
related to TAI(pick one).

TAI(anywhere) has no official status anywhere, except in the ex post
facto statistical sense that it contributes to TAI (unmodified, the
real thing from the BIPM).

In an official sense of operational time scales, it is not clear that
there really is anything such as UTC (plain old, unmodified) which
differs from TAI by an integral number of seconds.  As an identifiable
entity, UTC (unmodified) may only exist within the text of ITU-R
TF.460

--
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: The real problem with leap seconds

```On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ:

http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt

If I read it right you have reinvented Markus Kuhn's UTS as seen in

http://www.cl.cam.ac.uk/~mgk25/uts.txt
http://www.cl.cam.ac.uk/~mgk25/time/leap/
http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf

--
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: The real problem with leap seconds

```In message [EMAIL PROTECTED], Michael Sokolov writes:

http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt

In this rather humorous document you have managed to say that POSIX
screwed up badly.  We already knew that :-)

--
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: The real problem with leap seconds

```In message [EMAIL PROTECTED], Ed Davies writes:

Also, Markus wasn't proposing UTS as a civil timescale but just
for use within computer systems, etc.

What a weird concept...

Why not go the full distance and define a timescale for each
particular kind of time-piece:

Wrist Watch time

Wall clock time

Grandfather clock time

Tower clock time

Television time

Embedded system time

Appliance time

Router time

PC time

Windows server time

Commercial UNIX time

Free UNIX time

Main-frame time

and give each of them their own unique way of coping with leapseconds ?

Ohh wait...

That's what it looks like today already isn't it ?  :-(

--
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: The real problem with leap seconds

```
Poul-Henning Kamp wrote:

What a weird concept...

Why not go the full distance and define a timescale for each
particular kind of time-piece:

and give each of them their own unique way of coping with leapseconds ?

Ignoring the ridiculous parody - no, it's not a weird concept.
Different timescales are useful for different purposes.  Get
used to it.

The question is, where in the range of possible timescales is
it most useful to put civil time.

Ed.

```

Re: The real problem with leap seconds

```In message [EMAIL PROTECTED], Ed Davies writes:

Ignoring the ridiculous parody - no, it's not a weird concept.
Different timescales are useful for different purposes.  Get
used to it.

I have no problems with different timescales for different purposes.

For instance I very much wish the Astronomers would start to use
UT1, which is very much their timescale, and stop abusing UTC,
which isn't, as a convenient approximation.

But I have big problems with people who want to introduce more
timescales without thinking through the legal and technical
complications.

The question is, where in the range of possible timescales is
it most useful to put civil time.

Civil time is in the hands of individual governments, and they
tend to expect their computers to use the same time as the
rest of their country.

Nobody here is in any position to do anything about civil time
or legal time, neither are we in a position to introduce a
computer time scale in a pathetic attempt to paste over leap
seconds.

We can talk about _representation_ of a given timescale in computers,
but there are far too many laws to rewrite if we want to dictate
which timescale they should use.

--
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: The real problem with leap seconds

```
Hi Ed,

Poul-Henning Kamp wrote:

What a weird concept...

Why not go the full distance and define a timescale for each
particular kind of time-piece:

and give each of them their own unique way of coping with
leapseconds ?

Ignoring the ridiculous parody - no, it's not a weird concept.
Different timescales are useful for different purposes.  Get
used to it.

The question is, where in the range of possible timescales is
it most useful to put civil time.

Ed.

I was contemplating an answer along the same lines.  Yours is much
superior.

Rob

```

Re: The real problem with leap seconds

```Ed Davies scripsit:

(There's a small difference in practice in that the UTC to
TAI conversion requires a lookup table which is not known
very far into the future whereas the Gregorian calendar is
defined algorithmically for all time.)

Well, yes.  But that's a matter of verbal labels.  The Gregorian calendar
extends to all future time: what is not known is the date on which it
will be replaced in civil use by a further refinement.  We know we will
need one eventually, both because of the current annual discrepancy of
about 27 seconds between the Gregorian and tropical years, and because
of future changes in the length of the tropical year.

--
John Cowan  [EMAIL PROTECTED]  www.reutershealth.com  www.ccil.org/~cowan
If a traveler were informed that such a man [as Lord John Russell] was
leader of the House of Commons, he may well begin to comprehend how the
Egyptians worshiped an insect.  --Benjamin Disraeli

```

Re: The real problem with leap seconds

```Steve Allen scripsit:

The changes in the length of any kind of year are slight by comparison
to the changes in length of day.  Neglecting short period variations
the length of the sidereal year has not changed much in a billion years.

That is to say, the current best approximation to the n-body problem of
the Solar System says that it hasn't.  Fair enough.  I merely threw that in
in case it was an issue.

The Gregorian calendar was designed to match the vernal equinox year.

Thanks for the correction.

The new fields being added to GPS signals make them able to count leap
seconds for 3 years.  That's quite an example of engineering margin.

Indeed.  But then so is IPv6 (if we ever get it adopted widely).

--
John Cowan  [EMAIL PROTECTED]  www.ccil.org/~cowan  www.reutershealth.com
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.
--Gerald Holton

```

Re: The real problem with leap seconds

```On Sat, Jan 07, 2006 at 04:02:04PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Ed Davies writes:
Ignoring the ridiculous parody - no, it's not a weird concept.
Different timescales are useful for different purposes.  Get
used to it.

I have no problems with different timescales for different purposes.

For instance I very much wish the Astronomers would start to use
UT1, which is very much their timescale, and stop abusing UTC,
which isn't, as a convenient approximation.

But I have big problems with people who want to introduce more
timescales without thinking through the legal and technical
complications.

Yes  And with people that want to redefine existing time scales so
they mean one thing in one era, and another thing in a different era.
As happened with GMT, or the proposed changes to UTC.

The question is, where in the range of possible timescales is
it most useful to put civil time.

Civil time is in the hands of individual governments, and they
tend to expect their computers to use the same time as the
rest of their country.

Yes again.  And they are free to choose TAI if they want a uniform
time scale.  But why take the choice of a UTC that remains within 0.9s
of the earth's average rotation rate?

Nobody here is in any position to do anything about civil time
or legal time, neither are we in a position to introduce a
computer time scale in a pathetic attempt to paste over leap
seconds.

Here we disagree.  I guess you're confirming what is in fact the
current problem as I see it.  We're here because an ITU committee,
shrouded in secrecy, is trying to redefine UTC and the international
distribution of time signals, which most jurisdictions rely on one way
or another as civil time.

But the way the ITU works undermines the sort of open and informed
discussion that is necessary for an issue so sweeping in its legal,
practical and philosophical implications.

The thing that is most flawed here is the process.

We can talk about _representation_ of a given timescale in computers,
but there are far too many laws to rewrite if we want to dictate
which timescale they should use.

But it is inappropriate for ITU to do an end-run around the laws, and
redefine the timescale so that it swings an extra hour back and forth.

Some folks here suggest that legislatures just change their timezones
periodically, forced by the actions of the ITU.  But data was
presented in Torino suggesting a cost to NASA and US DoD of a half a
billion dollars to study, re-engineer and test their systems if UTC
diverges markedly from UT1.  Not an easy thing for a legislature to
deal with.  Again - it's a process problem

The only time there has been an inclulsive international meeting
devoted to the issue, at the colloquium in Torino, There was no
overwhelming consensus on whether the status quo should be maintained
or an alternative should be pursued.

But If a change were to be made one alternative appeared to be
preferred. The essence of this alternative was as follows: 1. Any
change should slowly evolve from the current UTC Standard in
transitioning to a uniform timescale, perhaps to be called Temps
International (TI). 2. A suggested date for inaugurating any change
would be 2022, the 50 TH anniversary of the UTC timescale. The date
suggested is influenced by the lifetimes of existing systems that
would be expensive to change.
[http://www.ien.it/luc/cesio/itu/annex_a.pdf]

So it is distressing to see committee members of the ITU headed in a
different direction.

Neal McBurnett http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

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: The real problem with leap seconds

```In message [EMAIL PROTECTED], Neal McBurnett writes:

Civil time is in the hands of individual governments, and they
tend to expect their computers to use the same time as the
rest of their country.

Yes again.  And they are free to choose TAI if they want a uniform
time scale.  But why take the choice of a UTC that remains within 0.9s
of the earth's average rotation rate?

Well, the BIPM doesn't really want anybody to use TAI, their director
said as much last year, and I can see where he is coming from on that
one.

The snippy answer to why UTC was adopted for civil timekeeping would
be Because they got bad advice, but that would be grossly unfair
since nobody (but possibly Dave Mills) at that time could be expected
to foresee what computer networks would result in and how that would
affect the needs for timekeeping.

Just like the variable rate atoms of the sixties where a bad idea
we now know that the variable length days that replaced them are

I'm not old enough to have any axe to grind about the last couple
of redefinitions of time, but I can see where they both went wrong
(insisting on using the unprecise and unstable clock to discipline
the stable and precise clock) and I want us to stop that mistake.

Here we disagree.  I guess you're confirming what is in fact the
current problem as I see it.  We're here because an ITU committee,
shrouded in secrecy, is trying to redefine UTC and the international
distribution of time signals, which most jurisdictions rely on one way
or another as civil time.

But you overlook that ITU is an international organization under
the UN aegis.

If ITU in their plenary assembly decides to do something, no matter
how stupid, (X.400 for example), that is nontheless the will of
the governments of the world.

You can find locate your countrys ITU-R representative and contact
them with your input, just as well as I can for mine.

There is nothing hidden, undemocratic or revolutionary about it.
The ITU _process_ does actually work.

I will agree that a lot of what ITU churns out, UTC with leapseconds
and X.400 being my best examples, are rubbish.

Some folks here suggest that legislatures just change their timezones
periodically, forced by the actions of the ITU.  But data was
presented in Torino suggesting a cost to NASA and US DoD of a half a
billion dollars to study, re-engineer and test their systems if UTC
diverges markedly from UT1.  Not an easy thing for a legislature to
deal with.  Again - it's a process problem

Let me channel something that gets said a lot here:

They should have used the right timescale from the beginning.

It sounds like they should have used UT1, doesn't it ?

And why is it that IT related costs matter so much if they come from
people worried about the effect of lack of leapseconds, while at
the same time, they don't matter at all if they come from people
worried about the effect of leapseconds ?

Clearly what's good for the goose is good for the gander, right ?

The only time there has been an inclulsive international meeting
devoted to the issue, at the colloquium in Torino, There was no
overwhelming consensus on whether the status quo should be maintained
or an alternative should be pursued.

... at that meeting.

The only consensus that matters is the ITU-R SG7A, which coincidentally
didn't reach one either.

--
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: The real problem with leap seconds

```In message: [EMAIL PROTECTED]
Daniel R. Tobias [EMAIL PROTECTED] writes:
: On 7 Jan 2006 at 16:02, Poul-Henning Kamp wrote:
:
:  Civil time is in the hands of individual governments, and they
:  tend to expect their computers to use the same time as the
:  rest of their country.
:
: And, in many countries (including the United States), the legally-
: defined civil time is the mean solar time at some particular spot, or
: a fixed or seasonally-variable offset from it.  Any use of UTC-based
: time scales for determining civil time in such places is merely an
: approximation, currently to within a second, but perhaps varying by
: greater amounts if some new timekeeping plan is adopted.  Once UTC
: stopped being a sufficiently-close approximation to the solar mean
: time at the Prime Meridian (with sufficiently close possibly being
: of differing values depending on the particular purpose), it would be
: necessary to either stop using UTC for determining civil time in such
: countries, or to change the law to base the civil time on UTC instead
: of a solar standard.

The US's legislation leaves it to the commerce department to define
what the mean solar time is (or rather states that it is the mean
solar time, as determined by the secretary of commerce).  This is what
presumably gives us leap seconds and the like in our civil time and
when we insert them.  This is a political function: Up to a second of
tolerance is allowed and leap seconds are inserted whenever everybody
else does.  The same political decision could be made to say something
else, since it is the folks in DC could say that a minute is close
enough to solar mean and that's what we're going to do.

Warner

```

Re: The real problem with leap seconds

```On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ:
You can find locate your countrys ITU-R representative and contact
them with your input, just as well as I can for mine.

You can try that, and you may succeed, but it is deceptive to assert
that is easy to do.

In the US the process is Byzantine.  Whereas it is apparently required
that draft contributions to the ITU be publicly available, it is
apparently not required that their availability be published outside
of predefined special interest groups.  I would describe more of what
I know, but given that my knowledge is assembled from little bits
gleaned from unrelated documents I'm not convinced I am right.

If anyone else cared to challenge me to post the rules of some other
nation I'll gladly rise to the challenge and post the US rules.

There is nothing hidden, undemocratic or revolutionary about it.
The ITU _process_ does actually work.

Agreed, you just have to be prepared to play the Byzantine games.

--
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: The real problem with leap seconds

```In message [EMAIL PROTECTED], Steve Allen writes:
On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ:
You can find locate your countrys ITU-R representative and contact
them with your input, just as well as I can for mine.

You can try that, and you may succeed, but it is deceptive to assert
that is easy to do.

As far as I know, pretty much anybody can get observer status in the
working group for a modest/outrageous (take your pick) amount of money.

There is nothing hidden, undemocratic or revolutionary about it.
The ITU _process_ does actually work.

Agreed, you just have to be prepared to play the Byzantine games.

Well, that's politics for you.  Just because one doesn't like the
rules doesn't mean that they're not fair.

--
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: The real problem with leap seconds

```From [EMAIL PROTECTED] Sat Jan  7 08:03:04 2006
Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by
ivan.Harhan.ORG (5.61.1.3/1.36)
id AA14507; Sat, 7 Jan 06 08:03:03 GMT
Received: from rom.usno.navy.mil by [198.116.61.253]
via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006
08:10:46 UT
Received: from ROM (rom.usno.navy.mil [10.1.4.27])
by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k077o0kU019926;
Sat, 7 Jan 2006 08:02:52 GMT
Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release
1.8e) with spool id 0549 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan
2006 08:02:52 +
Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by
rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k0782pkM019980 for
LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 08:02:52 GMT
Received: from santo.ucolick.org ([128.114.23.204]) by TS-FW.usno.navy.mil via
smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006
08:10:36 UT
Received: from localhost (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix)
with ESMTP id 475575D715 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat,  7
Jan 2006 00:02:51 -0800 (PST)
Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using
TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id
D9F7C11419 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat,  7 Jan 2006
00:02:50 -0800 (PST)
Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org
(8.13.1/8.12.10) with ESMTP id k0782ofC025400 for
LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:50 -0800
Received: (from [EMAIL PROTECTED]) by geneva.ucolick.org (8.13.1/8.13.1/Submit)
id
k0782oFP025399 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006
00:02:50 -0800
Date: Sat, 7 Jan 2006 00:02:50 -0800
From: Steve Allen [EMAIL PROTECTED]
To: Leap Second Discussion List LEAPSECS@ROM.USNO.NAVY.MIL
Subject: Re: The real problem with leap seconds
Message-Id: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Sender: [EMAIL PROTECTED]
Precedence: list
Status: RO

On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ:

http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt

If I read it right you have reinvented Markus Kuhn's UTS as seen in

http://www.cl.cam.ac.uk/~mgk25/uts.txt
http://www.cl.cam.ac.uk/~mgk25/time/leap/
http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf

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

From [EMAIL PROTECTED] Sat Jan  7 12:28:40 2006
Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by
ivan.Harhan.ORG (5.61.1.3/1.36)
id AA14637; Sat, 7 Jan 06 12:28:38 GMT
Received: from rom.usno.navy.mil by [198.116.61.253]
via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006
12:36:23 UT
Received: from ROM (rom.usno.navy.mil [10.1.4.27])
by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k07BLaki031306;
Sat, 7 Jan 2006 12:28:29 GMT
Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release
1.8e) with spool id 0583 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan
2006 12:28:28 +
Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by
rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k07CSRkM032500 for
LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 12:28:28 GMT
Received: from mail.metronet.co.uk ([213.162.97.75]) by TS-FW.usno.navy.mil via
smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006
12:36:12 UT
[213.162.103.78]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP
id 72B0F408240 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat,  7 Jan 2006
12:28:18 + (GMT)
Message-Id: [EMAIL PROTECTED]
Date: Sat, 07 Jan 2006 12:28:20 +
From: Ed Davies [EMAIL PROTECTED]
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
Mime-Version: 1.0
To: Leap Seconds Issues LEAPSECS@ROM.USNO.NAVY.MIL
Subject: Re: [LEAPSECS] The real problem with leap seconds
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Precedence: list
Status: RO

Steve```

Re: The real problem with leap seconds

```Please ignore this post.  It got away because I was connected to my UNIX
host from my girlfriend's PC over her cable Internet connection which is
probably the crappiest in the world as I was composing a reply to some
posts on this list, and as it crapped out on me, the mail process on the
UNIX host terminated and sent out whatever garbage was in its compose
buffer.

MS

```

Re: The real problem with leap seconds

```Steve Allen [EMAIL PROTECTED] wrote:

If I read it right you have reinvented Markus Kuhn's UTS [...]

Close to it, but...

Ed Davies [EMAIL PROTECTED] followed up:

Also, Markus wasn't proposing UTS as a civil timescale but just
for use within computer systems, etc.

Therein lies the key difference.  I have strived to make my argument as
independent of computers as I could.  To me the need for a real number
time scale is necessitated more by philosophy than computer science,
which is why I have resorted so much to the mathematical abstraction of
a real number in my paper.

My central argument still stands that current UTC is unsuitable for the
*philosophical* application of defining the abstract ideal scale of
civil time since it is not a scale in the mathematical definition of
this term (a real number).  I believe that the scale of civil time needs
to be a scale.  Furthermore, I believe that it should be related to the
cycle of day and night rather than completely decoupled from it, so I
won't support freezing the leap seconds for the next few centuries as a
solution.  That leaves me with my current position of arguing for a
coordinated time scale with elongated and shortened seconds.

MS

```

Re: The real problem with leap seconds

```Poul-Henning Kamp [EMAIL PROTECTED] wrote:

In this rather humorous document you have managed to say that POSIX
screwed up badly.  We already knew that :-)

What does this have to do with POSIX?  The word POSIX does not appear in
my article.

MS

```

Re: The real problem with leap seconds

```Ed Davies [EMAIL PROTECTED] wrote:

UTC is expressible as a real number in just the same way that
Gregorian dates (with months with different lengths and leap
days) can be with the Julian calendar.

There's no difference in principle between converting from a
TAI time in seconds since some epoch to a UTC date/time in
days, hours, minutes, seconds and fractions of a second [...]

You have dodged the problem so conveniently!  Of course I know how to
convert UTC to TAI or vice-versa, but that is not the problem statement
at hand.  The problem statement at hand is to express UTC *itself* as a
real number, rather than convert it to some other time scale.  For UTC
itself must be expressible as a real number in order to be called a time
*scale*.  If you admit that this cannot be done, then you should revise
TF.460-6 to remove all use of the word scale and openly admit to UTC
being a time non-scale.  Then no one will use UTC as the civil time
scale since it'll be obvious that as a non-scale it is not suitable as a
scale of any kind.

I stand by my assertion that the current ITU-R spec for UTC (and its
previous CCIR versions) is a clever scam, a parlor trick designed to
sell a non-scale to civil philosophers wanting a SCALE of civil time.
The manner in which it was adopted in 1970 by CCIR, a shove-down-the-
throat move reminiscent of the current leap hour scheme, does not help
them look any better.

MS

```