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

```

### Report of Leap Second Problem with GPS Data

```FYI.
-- Richard Langley
Professor of Geodesy and Precision Navigation

===
Richard B. LangleyE-mail: [EMAIL PROTECTED]
Geodetic Research Laboratory  Web: http://www.unb.ca/GGE/
Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142
University of New Brunswick   Fax:  +1 506 453-4943
Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===

-- Forwarded message --
Date: Fri, 13 Jan 2006 09:59:31 +1100
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [IGSSTATION-760]: DARR and 1Hz data from ARGN

**
IGS Station Mail  12 Jan 14:59:42 PST 2006  Message Number 760
**

Author: Michael Moore

Geoscience Australia
Australian Regional GPS Network
Geodetic Operation

High rate data, 1Hz 15 minute files, from the ARGN suffered a software
problem due to the recently introduced UTC leap-second. Data from DOY 001 to
DOY 009 is 1s off in the timestamps reported n the RINEX files. This problem
only applies to the 1Hz 15minute files submitted from the ARGN. The software
problem has been fixed, and all files from DOY 010 is reporting the correct
time.

RINEX headers for DARR from DOY 009, was incorrectly reporting an antenna
height of 0.000. The headers have now been fixed to report the correct
antenna height of 0.0025, and the data from DOY 009 has been resubmitted with

I apologise for any inconvenience this may cause.

Regards
Mike

*
Michael Moore
Geodetic Operations
Geoscience Australia Earth Monitoring Group (GEM)
http://www.ga.gov.au/
Telephone: (+61 2) 62499052
Fax: (+61 2) 62499929
Email: [EMAIL PROTECTED]
GPO Box 378
Canberra ACT 2601
Australia
*

```

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

```

### Problems with GLONASS Raw Receiver Data at Start of New Year

```The International GNSS Service (IGS) includes a sub-network of continuously
operating GLONASS monitor stations (about 50) including one at the University
of New Brunswick (UNB1).  At UNB1 we lost C1 (coarse code on L1 frequencies),
P1 (precision code on L1), and P2 (precision code on L2) observations on the 5
GLONASS satellites we were tracking at 00:01:30 GPS Time on 1 January 2006
along with phase jumps in L1 (carrier phase on L1) and L2 (carrier phase on
L2). Code measurements were back at 00:04:00.

I have just learned from one of the IGS analysis centres that all January 1
IGS GLONASS observation files that they checked show a similar problem.

-- Richard Langley
Professor of Geodesy and Precision Navigation

===
Richard B. LangleyE-mail: [EMAIL PROTECTED]
Geodetic Research Laboratory  Web: http://www.unb.ca/GGE/
Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142
University of New Brunswick   Fax:  +1 506 453-4943
Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===

```

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

```

### Analog clocks and leap seconds

```Michael Sokolov writes:
I cannot make the beautiful analog clock on the tower show 23:59:60.
But it's trivial to make it occasionally take 1.1 SI seconds instead of
1 SI second to turn its hands by 1 civil second.

Yes, this is one of the awkward features of a leap
second (positive leap second, at least). In practice
few clocks with analog displays are accurate enough
to even worry about leap seconds.

But if you were to design an analog clock that was
somehow leap second compatible here is my list
of possible implementations:

- You can have it run UT1 instead of UTC.

- For extra credit, you can have it run sidereal.
(http://www.bmumford.com/clocks/sidereal/index.html)

- You can pause at :59 or :00 for a second. Or pause
halfway in between.

- You can slow down a bit sometime before the leap
second and resume normal speed sometime after
the leap second such that one second is wasted.
Even 5 or 15 seconds before and after would be
sufficient that no one would notice the rate change.

- You can slow it down to exactly 1/2 speed between
:59 and :00. This, in my opinion, would be the most
visually pleasing. As of last week, photos of digital
23:59:60 displays are now common. But an analog
hand slowing down half speed between 59 and 00
would be quite unique. Similarly use 2x speed for a
negative leap second, should one to ever occur.

- You could wait for the second hand to hit :00 and
then go backwards for 1/2 second, then forwards
for 1/2 second. Kind of weird, but it would work.

- You can design it with 61 seconds around the circle
and jump over number 60 (go from 59 to 00) every
minute except for when a positive leap second occurs.
Also kind of weird, but the further into the future the
more it would be appreciated.

/tvb
http://www.LeapSecond.com

```

### 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: Analog clocks and leap seconds

```Tom Van Baak [EMAIL PROTECTED] wrote on Fri, 13 Jan 2006
at 07:31:50 -0800 in [EMAIL PROTECTED]:

But if you were to design an analog clock that was
somehow leap second compatible here is my list
of possible implementations:
...

Please consider a clock with a leap second hand that simply goes around
once (in either direction, as appropriate) in the event of a leap second.

[EMAIL PROTECTED]
John Hawkinson

```

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

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: Monsters from the id

``` It should be clear that the gaps and repeats are fictitious, especially
if you think of AEST and AEDT as existing beyond the times when they are
in legal use.  Putting it in practical terms, suppose I have a traffic
accident at 0230 on 2006/04/02, what time will the police officer write
in his report?  For most times of the year he can omit the timezone spec
because there is no legal ambiguity, but to do so for this specific hour
would be insufficient, he must specify AEDT or AEST.

There are two instances of 0230 but only one
0230 EST and one 0230 EDT. So that could take
care of the ambiguity, if the officer were clever.

Or he could use UTC/GMT/Zulu, if the office had a
military background.

implemented with +/- leap hours. Consider if the DST

Then the Spring DST change would jump from 22:59 to
00:00 skipping the 60 minutes labeled 23:00 to 23:59.
The Fall DST would be implemented after 23:59 where
and extra 60 minutes labeled 24:00 to 24:59 would be

/tvb
http://www.LeapHour.com

```

### Time standards: RFC3339 and ISO 8601, NTP

```On Fri, Jan 13, 2006 at 11:32:36AM -0700, Warner Losh wrote:
Has anybody compiled a canonical list of the standards in this area?
This is the first, I think I've seen ISO 8601 mentioned.

As usual, the IETF does a much better job than the ITU of making this
stuff available to the general public.  See

RFC 3339 Date and Time on the Internet: Timestamps
http://www.potaroo.net/ietf/idref/rfc3339/

This document defines a date and time format for use in Internet
protocols that is a profile of the ISO 8601 standard for
representation of dates and times using the Gregorian calendar.

Written via an open process; free for all to read, copy, distribute,
implement, or be involved in improvements to; with a complete ABNF
syntax specification; compatible with ISO 8601 but without a sufeit of
unnecessary alternative formats like ISO 8601.  Includes a short
section on Leap Seconds, lots of info on time zones, etc.

LEAPSECS members Markus Kuhn and myself contributed suggestions to it.

And as I noted earlier, the IETF ntp working group is working on
updating the NTP standard (RFC1305 on NTP version 3, RFC2030 on SNTP
version 4), again in a relatively refreshing and open manner:

http://ietf.org/html.charters/ntp-charter.html

http://www.potaroo.net/ietf/idref/rfc1305/