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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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.
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
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.
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
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
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.
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
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
[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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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]
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
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.
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
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
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
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
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
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
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
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
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/
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]
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
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.
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
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
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
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
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
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
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.
:
:
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
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
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
In-Reply-To: [EMAIL PROTECTED]
User-Agent: Mutt/1.4.2.1i
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
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
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
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
66 matches
Mail list logo
