On Thu 2006/01/19 16:36:45 BST, "Deckers, Michael" wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
> of UTC where UTC is not just taken as the (discontinuous) timescale
> TAI - DTAI.
It's possible that I have misunderstood your email (after many readings)
but it seems that we are going arou
Mark Calabretta wrote on 2006-01-17:
> The way UTC is disseminated is not directly relevant to the
discussion,
> and I don't think I said anything about topology.
You are right, you did not mention topology. But I am still
suspecting
that the 60 s notation as proposed by [ITU-R TF.460]
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 agre
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 that the current definitions leave a lot to be desired in terms
of clarity and rigour - an unchari
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]>
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 constan
Poul-Henning Kamp wrote:
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.
Well, if
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 ha
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 is correct.
> > The integral of d( UTC ) is TAI (up to an integration constant),
> > b
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
>
> >So if asked for a definition
On Fri 2006/01/13 12:32:27 +1100, Mark Calabretta wrote
in a message to: Leap Seconds Issues
>So if asked for a definition I would say that "UTC (post 1972) is a
>representation of TAI such that ... (you know the rest)".
.. and I should have said that prior to 1972, when UTC had "rubber
seconds"
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 - D
On Mon 2006-01-16T12:11:04 +, Michael Deckers hath writ:
>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 for each
>full minute of TAI - DTAI.
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 indi
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 not
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 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 f
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 ra
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, T
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
> 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".
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
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
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
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, 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
On Thu 2006/01/12 10:19:05 -, David Malone wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
>The reason that I came to this conclusion is because none of the
>documents I've read say that UTC can be expressed as a real number
>- they all suggest it is expressed as labelled seconds. (For examp
>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 different
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 0
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 +
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 [IT
On 2006-01-11, David Malone wrote:
> [A lot of discussion on this list seem to revolve around people
> understanding terms in different ways. In an impractical example
> of that spirit...]
Anyway: excuse me for repeating some basics of classical mechanics;
but I believe it to be neces
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 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 Mars
[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 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 unde
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 the
> > 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
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
On Tue, 10 Jan 2006, Mark Calabretta wrote:
> 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 sa
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 respons
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
> >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
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]
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.
>
"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 actual
In message: <[EMAIL PROTECTED]>
Peter Bunclark <[EMAIL PROTECTED]> 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 bou
In message <[EMAIL PROTECTED]>, "Clive D.W. Feather" writes:
>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.
Doesn't work.
Struct tm is defined such that if you do
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
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, YO
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 E
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 against
suggesting changing (or augmenting) POSIX time.
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_
Michael Sokolov said:
> http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt
>
> The short summary is that I believe the root problem is not the
> adjustments made to the civil time scale to match Earth's rotation, but
> the fact that UTC is not expressible as a real number. Read the article
> f
> : As I understood it, it was mainly that TAI is a post-factum "postal"
> : timescale.
>
> 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?
>
> Wanrer
Not f
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 y
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:
:
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 suggeste
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
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 acceptab
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 suggestion that the international agencies in charge of
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.
Ed Davies asked:
Since the usual response of the pro-leap second lobby to people
who want a uniform timescale is "use TAI" t
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
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 th
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
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
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
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 host
3.1/Submit)
id
k0782oFP025399 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006
00:02:50 -0800
Date: Sat, 7 Jan 2006 00:02:50 -0800
From: Steve Allen <[EMAIL PROTECTED]>
To: Leap Second Discussion List
Subject: Re: The real problem with leap seconds
Message-Id: <[EMA
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 dece
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 proces
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
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 w
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.
And, in many countries (including the United States), the legally-
defined civil time is the mean
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 differe
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 2006-01-07T13:06:13 -0500, John Cowan hath writ:
> Well, yes. But that's a matter of verbal labels. The Gregorian calendar
> extends to all future time: what is not known is the date on which it
> will be replaced in civil use by a further refinement. We know we will
> need one eventually
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
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 conce
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 Ast
Michael Sokolov wrote:
Hello,
I am a new entrant into the leap second debate and I have just written a
paper in which I have outlined what I think is the real problem with UTC
and leap seconds as they are currently implemented and a proposed
solution. I have put the article on my web page:
htt
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.
Diffe
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
Steve Allen wrote:
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/
http:/
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
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/
http://www.cl.cam.ac.uk/~mgk2
Hello,
I am a new entrant into the leap second debate and I have just written a
paper in which I have outlined what I think is the real problem with UTC
and leap seconds as they are currently implemented and a proposed
solution. I have put the article on my web page:
http://ivan.Harhan.ORG/~msok
91 matches
Mail list logo
