Re: Problems with GLONASS Raw Receiver Data at Start of New Year

2006-01-15 Thread Rob Seaman

On Jan 14, 2006, at 8:59 AM, Richard Langley wrote:


The problem existed for only 2-1/2 minutes, not hours.


Thanks for the clarification.


Might be coincidental with the leap second but I've not noticed
this problem at other times.


Would be a significant coincidence.  Any simple explanation for the
90 second lag in the issue being triggered?  The latency associated
with emergent behavior is of interest in itself.


Stations were not running during the previous leap second.


Right - that's a central fact influencing policy.  That different
groups take this to imply that different choices should be made adds
a little spice to the discussion :-)


UNB1 Web page is here: http://gge.unb.ca/Resources/UNB1.html.
IGS Central Bureau Web page is here: http://igscb.jpl.nasa.gov/


Thanks for the pointers.

Rob Seaman
NOAO


Re: The real problem with leap seconds

2006-01-15 Thread Mark Calabretta
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

2006-01-15 Thread Mark Calabretta
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

2006-01-15 Thread Mark Calabretta
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: Monsters from the id

2006-01-15 Thread Mark Calabretta
On Fri 2006/01/13 18:39:01 CDT, John Cowan wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

 The situation with the proposed leap hour is quite different.  Given
 that AEST is defined as UTC+1000, and AEDT as UTC+1100, would someone
 care to speculate, in terms similar to the above, what will happen when
 a leap hour is inserted?

Perhaps the two scales will be labeled O.S. and N.S., as our anglophone
antecessors did when switching from Julian to Gregorian.

If you go through the exercise trying to tie leap hours to DST, as I
challenged, you will discover that it raises many questions that are not
addressed by the leap hour proposal.

If you make some plausible assumptions as to how it would operate, with
DST starting and ending at the usual times of year and leap hours
occurring on new year's eve, I believe you will find it far from simple
to do in a rigorous fashion, and that at least one of the timescales is
genuinely discontinuous.

Mark Calabretta
ATNF


Re: Monsters from the id

2006-01-15 Thread John Cowan
Mark Calabretta scripsit:

 If you go through the exercise trying to tie leap hours to DST, as I
 challenged, you will discover that it raises many questions that are not
 addressed by the leap hour proposal.

I realize the ALHP has severe problems with this, but I don't approve
of the ALHP anyhow (save perhaps tactically, as explained).

 If you make some plausible assumptions as to how it would operate, with
 DST starting and ending at the usual times of year and leap hours
 occurring on new year's eve, I believe you will find it far from simple
 to do in a rigorous fashion, and that at least one of the timescales is
 genuinely discontinuous.

Indeed.  But the sensible approach would be for each State government to
fail to omit the hour of the normal spring transition in the year 2700,
say.  In that way, AEDT would become TI+1000 and a normal-looking autumn
transition would cause AEST to become TI+0900.  Countries without DST
transitions would have to actually repeat an hour, of course, just
as Algeria had to do in 1940, 1956, 1977, and 1981 (the country has
repeatedly flipflopped between UTC+ and UTC+0100).

By the way, I re-counted all the secular time zone transitions worldwide.
According to the Olson timezone database, there have been 516 of them
since the beginning of standard time (when that is, of course, varies
with the country or subdivision thereof).

--
John Cowan  http://www.ccil.org/~cowan  [EMAIL PROTECTED]
Be yourself.  Especially do not feign a working knowledge of RDF where
no such knowledge exists.  Neither be cynical about RELAX NG; for in
the face of all aridity and disenchantment in the world of markup,
James Clark is as perennial as the grass.  --DeXiderata, Sean McGrath