Mark Calabretta scripsit:
> 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
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
> 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
> i
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 par
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 sign
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 su
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 simpl
> 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 m
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".
On Jan 13, 2006, at 4:20 AM, Ed Davies wrote:
There's nothing in this text which would stop the IERS continuing
to issue leap seconds as they do now except they'd have to do it
five years in advance so would, presumably, have to relax the ±0.9
seconds requirement somewhat.
An excellent point!
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 beli
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 secon
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.
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
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) observatio
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
> re
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.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://ww
FYI.
-- Richard Langley
Professor of Geodesy and Precision Navigation
===
Richard B. LangleyE-mail: [EMAIL PROTECTED]
Geodetic Research Laboratory Web: http://www.unb.ca/GG
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
Rob Seaman quoted:
Operational rules
(after UTC 21 December of the transition year)
1 Tolerance
The difference of UT1 from UTC should not exceed ±1h.
2 Adjustments to UTC
2.1Adjustments to the UTC time-scale should be made as
determined by the IERS
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 provi
21 matches
Mail list logo
