Re: The real problem with leap seconds

2006-01-19 Thread Deckers, Michael
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]

Re: The real problem with leap seconds

2006-01-18 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-18 Thread Ed Davies
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

Re: The real problem with leap seconds

2006-01-18 Thread M. Warner Losh
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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

2006-01-18 Thread M. Warner Losh
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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

2006-01-16 Thread Warner Losh
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

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,

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

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

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

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

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

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

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.

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

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.

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

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

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.

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

Re: The real problem with leap seconds

2006-01-12 Thread David Malone
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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

2006-01-11 Thread David Malone
[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

Re: The real problem with leap seconds

2006-01-11 Thread Daniel R. Tobias
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

Re: The real problem with leap seconds

2006-01-11 Thread Steve Allen
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.

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

2006-01-11 Thread M. Warner Losh
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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

2006-01-10 Thread Peter Bunclark
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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

2006-01-10 Thread John Cowan
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

Re: The real problem with leap seconds

2006-01-09 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-09 Thread Clive D.W. Feather
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

Re: The real problem with leap seconds

2006-01-09 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-09 Thread Clive D.W. Feather
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

Re: The real problem with leap seconds

2006-01-09 Thread Markus Kuhn
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

Re: The real problem with leap seconds

2006-01-09 Thread Warner Losh
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

Re: The real problem with leap seconds

2006-01-09 Thread Poul-Henning Kamp
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]

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

2006-01-08 Thread Ed Davies
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

Re: The real problem with leap seconds

2006-01-08 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-08 Thread Rob Seaman
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

Re: The real problem with leap seconds

2006-01-08 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-08 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-08 Thread M. Warner Losh
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

Re: The real problem with leap seconds

2006-01-08 Thread Steve Allen
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

Re: The real problem with leap seconds

2006-01-07 Thread Steve Allen
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/

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
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]

Re: The real problem with leap seconds

2006-01-07 Thread Ed Davies
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/

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-07 Thread Ed Davies
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.

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-07 Thread Rob Seaman
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

Re: The real problem with leap seconds

2006-01-07 Thread John Cowan
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

Re: The real problem with leap seconds

2006-01-07 Thread Steve Allen
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,

Re: The real problem with leap seconds

2006-01-07 Thread John Cowan
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

Re: The real problem with leap seconds

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

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-07 Thread M. Warner Losh
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. : :

Re: The real problem with leap seconds

2006-01-07 Thread Steve Allen
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

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
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

Re: The real problem with leap seconds

2006-01-07 Thread Michael Sokolov
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

Re: The real problem with leap seconds

2006-01-07 Thread Michael Sokolov
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

Re: The real problem with leap seconds

2006-01-07 Thread Michael Sokolov
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

Re: The real problem with leap seconds

2006-01-07 Thread Michael Sokolov
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

Re: The real problem with leap seconds

2006-01-07 Thread Michael Sokolov
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