Re: The real problem with leap seconds

2006-01-13 Thread Michael Deckers
   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
  months in advance.

  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

2006-01-13 Thread Ed Davies

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

2006-01-13 Thread Richard Langley
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, N.B., Canada  E3B 5A3
 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

ADVISORY:

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
the correct header information.

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

2006-01-13 Thread Michael Deckers
   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

2006-01-13 Thread Richard Langley
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, N.B., Canada  E3B 5A3
 Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===


Re: The real problem with leap seconds

2006-01-13 Thread Ed Davies

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?


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.

Thanks for the further notes from TF.460.

Ed.


Re: The real problem with leap seconds

2006-01-13 Thread Ed Davies

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

2006-01-13 Thread Tom Van Baak
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

2006-01-13 Thread Rob Seaman

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
already exists?

Rob


Re: The real problem with leap seconds

2006-01-13 Thread Rob Seaman

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

2006-01-13 Thread Tim Shepard
 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

2006-01-13 Thread John Hawkinson
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

2006-01-13 Thread Michael Deckers
   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

2006-01-13 Thread Warner Losh
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
advance.

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

2006-01-13 Thread William Thompson

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

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

2006-01-13 Thread Tom Van Baak
 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.

Or, how about this for a laugh... Suppose DST were
implemented with +/- leap hours. Consider if the DST
switch were made around midnight instead of 2 AM.

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
added. That takes care of your EST/EDT ambiguity...

/tvb
http://www.LeapHour.com


Time standards: RFC3339 and ISO 8601, NTP

2006-01-13 Thread Neal McBurnett
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/

Join us and get a standard TAI spec for NTP!

Cheers,

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