On 2017-02-09 02:28 AM, Warner Losh wrote:
On Fri, Feb 3, 2017 at 4:30 PM, Brooks Harris wrote:
If its after the Leap Second then your method doesn't work directly; you'd
need to figure it out and make an internal adjustment to the TAI-UTC value a
second *before* its supplied to you, right? See
On Fri, Feb 3, 2017 at 4:30 PM, Brooks Harris wrote:
> If its after the Leap Second then your method doesn't work directly; you'd
> need to figure it out and make an internal adjustment to the TAI-UTC value a
> second *before* its supplied to you, right? See what I mean?
That would be a problem,
> That's where my question is. A GPS receiver would read the UTC metadata
> supplied in the GPS signal to generate UTC 23:59:60 from the primary GPS
> time, right?
Correct.
> We see from this discussion there are several ways folks use to
> calculate this conversion, but what method to use may
On 2017-02-06 06:30 PM, Tom Van Baak wrote:
I'm not a GPS expert. IS-GPS-200G is dense. The TAI-UTC value is
signaled, but how its encoded is complicated, and when its updated is
unclear to me. See 20.3.3.5.2.4 Coordinated Universal Time (UTC). Can
anyone speak to that and this topic? What does G
> I'm not a GPS expert. IS-GPS-200G is dense. The TAI-UTC value is
> signaled, but how its encoded is complicated, and when its updated is
> unclear to me. See 20.3.3.5.2.4 Coordinated Universal Time (UTC). Can
> anyone speak to that and this topic? What does GPS do? Is it clear? Or
> does it a
Warner Losh wrote:
>Actually it doesn't. I couldn't follow the logic on that argument at
>all,
Let me see if I can work through it more clearly, and more in the
terminology that you have used. The first case below is one that you
have addressed in detail; the others are what I derive from it usin
On 2017-02-06 12:11 PM, Warner Losh wrote:
On Mon, Feb 6, 2017 at 6:39 AM, Zefram wrote:
Warner Losh wrote:
So either there's some weird math that lets one subtract two numbers
that are different and get 0 as the answer, or the delta has to change
at the start.
To the extent that they're diff
On Mon, Feb 6, 2017 at 10:58 AM, Zefram wrote:
> Warner Losh wrote:
>>Saying that the two numbers are the same is improper. Or rather, it
>>depends on which time scale you are looking at them in if they are
>>improper.
>
> The numbers are not on any time scale. The numbers are derived from
> the
Warner Losh wrote:
>Saying that the two numbers are the same is improper. Or rather, it
>depends on which time scale you are looking at them in if they are
>improper.
The numbers are not on any time scale. The numbers are derived from
the time values, but are a different thing.
>However, if you
> Also, I'll note that bulletin C says from 0h, which is a time
> expressed to only one significant digit.
That's a lame excuse to bring up significant digits.
Everyone knows that "0h" means midnight, the one at 00:00:00 (as opposed to the
one at 24:00:00).
Are you now going to criticize a UTC(k)
On Mon, Feb 6, 2017 at 6:39 AM, Zefram wrote:
> Warner Losh wrote:
>>So either there's some weird math that lets one subtract two numbers
>>that are different and get 0 as the answer, or the delta has to change
>>at the start.
>
> To the extent that they're different, the things being subtracted a
Warner Losh wrote:
>So either there's some weird math that lets one subtract two numbers
>that are different and get 0 as the answer, or the delta has to change
>at the start.
To the extent that they're different, the things being subtracted are
not numbers. The expression "TAI - UTC" is shorthan
Warner Losh wrote:
>contend that since the mapping / linearization isn't 1:1 onto, the
>proof is not valid.
The mechanism doesn't rely on the linearisation of UTC being reversible.
That's not a problem.
-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsec
But I thought the change in delta occurred at midnight UTC.
TAI Δ UTC
23:59:580 23:59:58
23:59:590 23:59:59
00:00:000 23:59:60 <— delta is still 0.
00:00:011 00:00:00
TAI Δ UTC
23:59:58
On Sat, Feb 4, 2017 at 10:32 AM, Steve Summit wrote:
> Warner wrote:
>> I think this is the crux of my problem with Tom's answer to my first
>> leap second question. We have two times, that are obviously different
>> that when subtracted produce 0 as the answer. x-y = 0 should only be
>> true when
Warner wrote:
> I think this is the crux of my problem with Tom's answer to my first
> leap second question. We have two times, that are obviously different
> that when subtracted produce 0 as the answer. x-y = 0 should only be
> true when x and y are the same. But we get that answer when they are
On Sat, Feb 4, 2017 at 8:37 AM, Clive D.W. Feather wrote:
> Now define the "linearization" of a broken-down time as:
>
> L = D*86400 + H*3600 + M*60 + S
>
> In TAI, L is the number of seconds since 00:00:00 on the epoch date.
>
> In UTC L is *NOT* the number of seconds since anything useful, b
Warner Losh said:
> It's understanding what the weird math is that I'm having trouble with
> for people that say it is after the leap second that the delta
> changes.
[Not picking on Warner; this was just a convenient hook.]
I've been looking at this topic for work purposes and ended up doing a f
On 2017-02-03 11:24 PM, Tom Van Baak wrote:
Hi Warner,
But consider TAI and UTC when they were equal, for the sake of
argument. I know they never were, but if we look at what the first one
would look like:
That's a nice, clear example. Thanks.
23:59:58 23:59:58
happens. It's only when the time
stamp rolls over to :00, that the extra 1 moves over from the "UTC" part to the
"TAI-UTC" part of the equation.
/tvb
- Original Message -
From: "Warner Losh"
To: "Leap Second Discussion List"
Sent: Frida
On 2017-02-03 04:30 PM, Warner Losh wrote:
On Wed, Feb 1, 2017 at 11:14 PM, Warner Losh wrote:
On Wed, Feb 1, 2017 at 10:37 PM, Zefram wrote:
Warner Losh wrote:
If you are going to willfully misunderstand, then I'm done being patient.
I am not willfully misunderstanding. I have tried to un
On 2017-02-03 16:30, Warner Losh wrote:
On Wed, Feb 1, 2017 at 11:14 PM, Warner Losh wrote:
On Wed, Feb 1, 2017 at 10:37 PM, Zefram wrote:
Warner Losh wrote:
If you are going to willfully misunderstand, then I'm done being patient.
I am not willfully misunderstanding. I have tried to und
On Wed, Feb 1, 2017 at 11:14 PM, Warner Losh wrote:
> On Wed, Feb 1, 2017 at 10:37 PM, Zefram wrote:
>> Warner Losh wrote:
>>>If you are going to willfully misunderstand, then I'm done being patient.
>>
>> I am not willfully misunderstanding. I have tried to understand
>> what you're doing, and
Nice analysis, thanks.
You've looked only at the situation where the user only wants to recover
the time corresponding to the timestamp that was transmitted by the clock.
Very often a user also wants to be able to project ahead a bit, displaying
times that come some known duration after the transm
Steve Allen wrote:
>On Wed 2017-02-01T14:27:03 -0800, Tom Van Baak hath writ:
>> 6) clock sends TAI and -N, user wants UTC
>> - 6a) clock must send N1 and N2 so that user can generate UTC in all cases,
>> or
>
>I recognize this as the model chosen by GPS,
Kind of, but what GPS does isn't quite ac
On Wed, Feb 1, 2017 at 10:37 PM, Zefram wrote:
> Warner Losh wrote:
>>If you are going to willfully misunderstand, then I'm done being patient.
>
> I am not willfully misunderstanding. I have tried to understand
> what you're doing, and I've been unable to find a system that works
> consistently,
Warner Losh wrote:
>If you are going to willfully misunderstand, then I'm done being patient.
I am not willfully misunderstanding. I have tried to understand
what you're doing, and I've been unable to find a system that works
consistently, uses the labelling of leap seconds on which we are agreed
On Wed 2017-02-01T14:27:03 -0800, Tom Van Baak hath writ:
> 6) clock sends TAI and -N, user wants UTC
> - 6a) clock must send N1 and N2 so that user can generate UTC in all cases, or
I recognize this as the model chosen by GPS, and documented in
IS-GPS-200. GPS also gives the epoch at which N2 su
Here's a different take on the situation. Or maybe it's just how someone with
cesium clocks looks at the problem. Don't over think what I mean by "clock",
"user" and leap second "table" below.
Timescale / timestamp conversion in Six Easy Cases:
1) clock sends UTC, user wants UTC
- N.B. clock n
On 2017-02-01 12:46 PM, Steve Allen wrote:
On Wed 2017-02-01T10:50:12 -0500, Brooks Harris hath writ:
https://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!MSW-E.doc
Section C Coordinated universal time (UTC) says "UTC is the
time-scale maintained by the BIPM, with assistance fro
On Wed 2017-02-01T10:50:12 -0500, Brooks Harris hath writ:
> Yes, well its that "fundamentally ambiguous" part that none of us
> can stand and keeps us obsessed with the LEAPSECS discussion, I
> guess.
If only we lived in a woulda, coulda, shoulda world we might have had
a clear prescription for h
On Wed 2017-02-01T10:50:12 -0500, Brooks Harris hath writ:
> https://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!MSW-E.doc
>
> Section C Coordinated universal time (UTC) says "UTC is the
> time-scale maintained by the BIPM, with assistance from the IERS..."
>
> This says BIPM is th
On Wed, Feb 1, 2017 at 8:12 AM, Steve Summit wrote:
> Part of the problem, as Zefram has pointed out, is that when we
> attempt to compute 00:00:36 minus anything, we're subtracting a
> relative time from an absolute TAI time, which gives us another
> absolute TAI time, *not* a UTC time. So the m
Brooks Harris wrote:
> Yes, there is no uninterrupted incrementing numbering that represents UTC.
> Indeed, that's the whole point, isn't it?
Right. This is one of the fundamental aspects of the whole
situation. *Anything* you do that tries to work with UTC as if
it were, or tries to map UTC ont
On Wed, Feb 1, 2017 at 1:50 AM, Zefram wrote:
> Warner Losh wrote:
>>I'd suggest that you re-read what I wrote, because these two
>>paragraphs do not represent that at all.
>
> It certainly involves a different result from what you stated, but as
> I said, your result doesn't seem to follow from t
It's fascinating!
Even in this forum which must include some of the people in the world who's
given the subject the most thought what seems like essential details aren't
clear.
So much for "let's just wait for everyone to get their software right" if we
here don't even have clarity on "right".
On 2017-02-01 10:12 AM, Steve Summit wrote:
I wrote:
For every let's-look-at-the-arithmetic argument that suggests we
should use the "new" offset during the leap second, I can come up
with one which suggests the opposite. (Basically it depends on
whether you come at the leap second "from below"
On 2017-02-01 07:39 AM, Steve Summit wrote:
Brooks Harris wrote:
On 2017-01-31 08:21 PM, Steve Summit wrote:
I feel like I should apologize for my earlier contribution to it,
which presented a nice-looking, persuasive-sounding argument
which now looks an awful lot like it's... wrong.
Not at al
Warner Losh wrote:
> On Tue, Jan 31, 2017 at 12:13 PM, Brooks Harris wrote:
> >
> > Of course, as we've been discussing, the specifications
> > leave room for interpretation.
>
> Correct. They don't even talk about an offset. They just say that a
> leap second is counted positiviely 58, 59, 60, 0
I wrote:
> For every let's-look-at-the-arithmetic argument that suggests we
> should use the "new" offset during the leap second, I can come up
> with one which suggests the opposite. (Basically it depends on
> whether you come at the leap second "from below" or "from above".
> I'll send the longw
GERRY ASHTON wrote:
>I guess "reduced to scalar value" means applying a procedure such as:
Yes, that's about it. I wouldn't describe the day spans as "seconds
excluding leap seconds"; better to put it as "86400 times the number
of days". I would use an expression such as "86400*MJDN + 3600*H +
6
On 01/02/17 08:39 AM, Steve Summit wrote:
On further reflection, I think we're all right. For every
let's-look-at-the-arithmetic argument that suggests we should
use the "new" offset during the leap second, I can come up with
one which suggests the opposite. (Basically it depends on
whether you
Brooks Harris wrote:
> On 2017-01-31 08:21 PM, Steve Summit wrote:
> > I feel like I should apologize for my earlier contribution to it,
> > which presented a nice-looking, persuasive-sounding argument
> > which now looks an awful lot like it's... wrong.
>
> Not at all. Its an informed contribution
On 2017-01-31 14:13, Tony Finch wrote:
Y'know, if you are going to argue with one of my messages, it would be
more polite not to snip the sentence I wrote which agrees with your
points. You wrote a good pedantic analysis of the problem; a pity it
wasn't also kind.
I am sorry I was impol
> On February 1, 2017 at 3:24 AM Zefram wrote in part:
>
> The maths isn't done in the irregular radix. For the purposes of
> expressions such as "TAI - UTC" that require a UTC time to be reduced to
> a scalar value, that scalar is derived using the regular radix values.
> This means that, yes,
On 2017-02-01 05:10, Brooks Harris replied to my
scribbling:
Actually, there is just one official document
defining UTC (ITU-R Rec 460); plus of course
the Bulletins C of the IERS.
Generally I agree these are the two most relevant documents. But Rec 460 doesn't
point you to Bul
Warner Losh wrote:
>I'd suggest that you re-read what I wrote, because these two
>paragraphs do not represent that at all.
It certainly involves a different result from what you stated, but as
I said, your result doesn't seem to follow from the principle that
you stated. Rereading, my view of you
On Tue, Jan 31, 2017 at 11:02 PM, Zefram wrote:
> Warner Losh wrote:
>>Only for time_t computations.
>
> The POSIX expression for time_t, if taken entirely literally, does the
> same thing. But that's not the only use of a scalar behaving in this way.
>
>> "reducing to a scalar value
Warner Losh wrote:
>Only for time_t computations.
The POSIX expression for time_t, if taken entirely literally, does the
same thing. But that's not the only use of a scalar behaving in this way.
> "reducing to a scalar value" unfortunately doesn't map
>1-1 onto UTC.
Right. The sca
On 2017-01-31 04:15 AM, michael.deckers via LEAPSECS wrote:
On 2017-01-30 21:36, Brooks Harris wrote:
It seems to me this is where the
UTC
specifications are scattered over many documents and no one document
makes it
clear by itself, and this leaves ro
On Tue, Jan 31, 2017 at 8:24 PM, Zefram wrote:
> Warner Losh wrote:
>>changes at the start of the positive leap second, or at the start of
>>the first second after a negative label has been removed. Otherwise
>>the irregular radix math doesn't work out.
>
> The maths isn't done in the irregular ra
Warner Losh wrote:
>changes at the start of the positive leap second, or at the start of
>the first second after a negative label has been removed. Otherwise
>the irregular radix math doesn't work out.
The maths isn't done in the irregular radix. For the purposes of
expressions such as "TAI - UTC
On 2017-01-31 08:21 PM, Steve Summit wrote:
Wow. This has been quite a thread.
I feel like I should apologize for my earlier contribution to it,
which presented a nice-looking, persuasive-sounding argument
which now looks an awful lot like it's... wrong.
Not at all. Its an informed contribution
Wow. This has been quite a thread.
I feel like I should apologize for my earlier contribution to it,
which presented a nice-looking, persuasive-sounding argument
which now looks an awful lot like it's... wrong. But it seems to
have temporarily taken in (at least) Tom Van Baak and Brooks
Harris,
On 2017-01-31 04:44 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 2:20 PM, Brooks Harris wrote:
It's the only way to encode one number such that the irregular radix
math works out.
I think I'm going to need an example I can work through to fully understand
you here. When you get a chance, or
On Tue, 31 Jan 2017, Tim Shepard wrote:
Richard Clark wrote,
immediately comes to mind then it will have no difficulty handling
the non-normalized 23:59:60 and putting it 86401 seconds after
00:00:00 earlier that day. So here you can apply the new value of
(TAI-UTC) starting with the first s
On Tue, 2017-01-31 at 14:44 -0700, Warner Losh wrote:
...
> In both cases, we did need to know that 23:59 had 61 seconds, but we
> didn't need to have a special leap second flag associated with any of
> the timestamps for the math to work out right. Knowing that it has 61
> seconds sometimes is e
On 2017-01-31 04:20 PM, Tim Shepard wrote:
Richard Clark wrote,
immediately comes to mind then it will have no difficulty handling
the non-normalized 23:59:60 and putting it 86401 seconds after
00:00:00 earlier that day. So here you can apply the new value of
(TAI-UTC) starting with the first
On Tue, Jan 31, 2017 at 2:20 PM, Brooks Harris wrote:
>> It's the only way to encode one number such that the irregular radix
>> math works out.
>
> I think I'm going to need an example I can work through to fully understand
> you here. When you get a chance, or can point me to something, thanks.
Richard Clark wrote,
> immediately comes to mind then it will have no difficulty handling
> the non-normalized 23:59:60 and putting it 86401 seconds after
> 00:00:00 earlier that day. So here you can apply the new value of
> (TAI-UTC) starting with the first second after the leap second.
It se
On 2017-01-31 03:52 PM, GERRY ASHTON wrote:
How I would interpret "offset":
Bulletin C 52
The difference between UTC and the International Atomic Time TAI is:
from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
from 2017 January 1, 0h UTC, until further notice: UTC
On 2017-01-31 02:53 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 12:41 PM, Brooks Harris wrote:
On 2017-01-31 02:04 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris wrote:
On 2017-01-31 12:33 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit wrote
How I would interpret "offset":
Bulletin C 52
The difference between UTC and the International Atomic Time TAI is:
from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s
___
List
Subject: Re: [LEAPSECS] BBC radio Crowd Science
On Tue 2017-01-31T13:58:15 -0500, Brooks Harris hath writ:
> Ah, so who's right?
I prefer to think of a leap second as being truly intercalary.
It is saying to atomic clock "It's not tomorrow yet, wait a second."
It is betw
On Tue, Jan 31, 2017 at 12:57 PM, Brooks Harris wrote:
> On 2017-01-31 02:50 PM, GERRY ASHTON wrote:
>>>
>>> ...On January 31, 2017 at 7:08 PM Steve Allen wrote in
>>> part:
>>> I prefer to think of a leap second as being truly intercalary.
>>> It is saying to atomic clock "It's not tomorrow yet,
On Tue, Jan 31, 2017 at 12:50 PM, Brooks Harris wrote:
> On 2017-01-31 02:19 PM, Warner Losh wrote:
>>
>> On Tue, Jan 31, 2017 at 12:08 PM, Steve Allen wrote:
>>>
>>> On Tue 2017-01-31T13:58:15 -0500, Brooks Harris hath writ:
Ah, so who's right?
>>>
>>> I prefer to think of a leap secon
On 2017-01-31 02:50 PM, GERRY ASHTON wrote:
...On January 31, 2017 at 7:08 PM Steve Allen wrote in part:
I prefer to think of a leap second as being truly intercalary.
It is saying to atomic clock "It's not tomorrow yet, wait a second."
It is between one calendar day of UTC and the next calendar
On 2017-01-31 02:32 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 12:13 PM, Brooks Harris wrote:
On 2017-01-31 01:52 PM, Warner Losh wrote:
On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak wrote:
2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
What kind of arithmetic is that?
Hi Mi
On Tue, Jan 31, 2017 at 12:41 PM, Brooks Harris wrote:
> On 2017-01-31 02:04 PM, Warner Losh wrote:
>>
>> On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris wrote:
>>>
>>> On 2017-01-31 12:33 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit wrote:
>
> Tom Van B
On 2017-01-31 02:19 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 12:08 PM, Steve Allen wrote:
On Tue 2017-01-31T13:58:15 -0500, Brooks Harris hath writ:
Ah, so who's right?
I prefer to think of a leap second as being truly intercalary.
It is saying to atomic clock "It's not tomorrow yet, wa
> ...On January 31, 2017 at 7:08 PM Steve Allen wrote in
> part:
> I prefer to think of a leap second as being truly intercalary.
> It is saying to atomic clock "It's not tomorrow yet, wait a second."
> It is between one calendar day of UTC and the next calendar day of UTC.
> It belongs to neith
It seems like it depends which direction you are trying to convert.
TAI to UTC does require knowledge of both the the current (TAI-UTC)
and that a leap second is in progress.
As long as we only have positive leap seconds you can get away with
applying the new value of (TAI-UTC) after the leap se
On 2017-01-31 02:04 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris wrote:
On 2017-01-31 12:33 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit wrote:
Tom Van Baak and Michael Decker wrote:
2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
What
On Tue, Jan 31, 2017 at 12:13 PM, Brooks Harris wrote:
> On 2017-01-31 01:52 PM, Warner Losh wrote:
>>
>> On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak wrote:
>
> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
What kind of arithmetic is that?
>>>
>>> Hi Michael,
>>>
>>
On Tue, Jan 31, 2017 at 12:08 PM, Steve Allen wrote:
> On Tue 2017-01-31T13:58:15 -0500, Brooks Harris hath writ:
>> Ah, so who's right?
>
> I prefer to think of a leap second as being truly intercalary.
> It is saying to atomic clock "It's not tomorrow yet, wait a second."
> It is between one cal
On 2017-01-31 01:52 PM, Warner Losh wrote:
On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak wrote:
2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
What kind of arithmetic is that?
Hi Michael,
First, there's no problem with this, right? (Thanks to Steve for catching typo)
2017-01-01T0
On Tue 2017-01-31T13:58:15 -0500, Brooks Harris hath writ:
> Ah, so who's right?
I prefer to think of a leap second as being truly intercalary.
It is saying to atomic clock "It's not tomorrow yet, wait a second."
It is between one calendar day of UTC and the next calendar day of UTC.
It belongs to
On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris wrote:
> On 2017-01-31 12:33 PM, Warner Losh wrote:
>>
>> On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit wrote:
>>>
>>> Tom Van Baak and Michael Decker wrote:
>>
>> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
>
> What kind of
On 2017-01-31 12:33 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit wrote:
Tom Van Baak and Michael Decker wrote:
2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
What kind of arithmetic is that?
I think it ends up being roughly the same kind of arithmetic
that tells
On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak wrote:
>>> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
>>What kind of arithmetic is that?
>
> Hi Michael,
>
> First, there's no problem with this, right? (Thanks to Steve for catching
> typo)
>
> 2017-01-01T00:00:35.5 TAI = 2016-12-31T23
On Tue, Jan 31, 2017 at 11:29 AM, Brooks Harris wrote:
> As Steve Summit said earlier (with his 2015 example)
>
> Positive leap second:
>
> TAI UTC TAI-UTC
> 00:00:34.023:59:59.035
> 00:00:34.523:59:59.535
> 00:00:35.023:59:60.035
>
On 2017-01-30 04:39 PM, Tom Van Baak wrote:
2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
What kind of arithmetic is that?
Hi Michael,
First, there's no problem with this, right? (Thanks to Steve for catching typo)
2017-01-01T00:00:35.5 TAI = 2016-12-31T23:59:59.5 UTC
2017-01-01T0
On Mon, Jan 30, 2017 at 6:06 AM, Tony Finch wrote:
> Michael.Deckers. via LEAPSECS wrote:
>>
>>My point was that Arias' labeling makes it clear that the
>>latest discontinuity in TAI - UTC occurred when TAI assumed
>>the value 2017-01-01 + 36 s. The ITU labeling (nor any
>>other s
On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit wrote:
> Tom Van Baak and Michael Decker wrote:
2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
>>> What kind of arithmetic is that?
>
> I think it ends up being roughly the same kind of arithmetic
> that tells you that the 60th day of the ye
Tom Van Baak and Michael Decker wrote:
>>> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
>> What kind of arithmetic is that?
I think it ends up being roughly the same kind of arithmetic
that tells you that the 60th day of the year is March 1.
Or maybe February 29.
[in a later message]
> I
Michael.Deckers. via LEAPSECS wrote:
>
>On 2017-01-30 13:06, Tony Finch wrote:
>
> > It's tricky. Bulletin C is pretty clear about when it thinks TAI-UTC
> > changes:
> >
> >from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
> >from 2017 January 1, 0h UTC, until fur
On 2017-01-30 21:39, Tom Van Baak wrote:
2017-01-01T00:00:35.5 TAI = 2016-12-31T23:59:59.5 UTC
I do have problems with your notation.
You apparently want to say that
"whenever TAI assumes the value 2017-01-01T00:00:35.5,
then UTC assumes the value 2016-12-31T23:59:59.5
On 2017-01-30 21:36, Brooks Harris wrote:
It seems to me this is where the UTC
specifications are scattered over many documents and no one document makes it
clear by itself, and this leaves room for misunderstanding.
Actually, there is just one offic
Brooks Harris wrote:
>It seems to me Tz Database does a great job of describing the meanings of
>local time after 1972,
The scope of the tz database is yet another thing that doesn't start
in 1972. Though it's close. The project actually aims to fully
cover 1970 onwards, and decisions about whet
>> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
>What kind of arithmetic is that?
Hi Michael,
First, there's no problem with this, right? (Thanks to Steve for catching typo)
2017-01-01T00:00:35.5 TAI = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI = 2016-12-31T23:59:60.5 UTC
2
On 2017-01-30 01:12 PM, Michael.Deckers. via LEAPSECS wrote:
On 2017-01-30 13:06, Tony Finch wrote:
It's tricky. Bulletin C is pretty clear about when it thinks TAI-UTC
changes:
from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = -
36s
from 2017 January 1, 0h UTC, until
On 2017-01-30 03:45 PM, Michael.Deckers. via LEAPSECS wrote:
On 2017-01-30 19:21, Tom Van Baak wrote:
2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
What kind of arithmetic is that?
Its not arithmetic. Its a YMDhms encoding of a TAI second. The Leap
Second (TAI-UTC) metadata fro
On 2017-01-30 19:21, Tom Van Baak wrote:
2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
What kind of arithmetic is that?
2017-01-01T00:00:37.5 - 37 s = 2016-12-31T00:00:00.5
The question was whether 2017-01-01T00:00:36.5 - 37 s
is < 2017-01-01 or >= 2017-01-01.
Michael
> On January 30, 2017 at 7:21 PM Tom Van Baak wrote:
>
>
> >>from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
> >>from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s
> >>
> >Pretty clear? Let's try. What does Bulletin C52 say about the
> >
>>from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
>>from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s
>>
>Pretty clear? Let's try. What does Bulletin C52 say about the
>relationship between UTC and TAI when TAI is equal to
>2017-01-01T
On 2017-01-30 13:06, Tony Finch wrote:
It's tricky. Bulletin C is pretty clear about when it thinks TAI-UTC
changes:
from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s
Pretty clear? Let's t
On 2017-01-30 10:12 AM, Steve Allen wrote:
On Mon 2017-01-30T14:14:10 +, Tony Finch hath writ:
I think what I was trying to get at (as others have already said in this
thread) is that you can use the TAI-UTC delta to translate from UTC to TAI
during a leap second, but you need more informati
On Mon 2017-01-30T14:14:10 +, Tony Finch hath writ:
> I think what I was trying to get at (as others have already said in this
> thread) is that you can use the TAI-UTC delta to translate from UTC to TAI
> during a leap second, but you need more information to make the inverse
> translation.
A
Tom Van Baak wrote:
> > it doesn't make much sense to have a defined delta for the last UTC
> > second of 2016.
>
> No.
>
> So I see no reason or need to pick on "delta" as being in an
> indeterminate state during a leap second. We have enough exceptions with
> leap second handling as it is. Let'
> It's tricky.
Yes.
> Bulletin C is pretty clear about when it thinks TAI-UTC changes:
Yes.
> However, since there isn't any TAI time with a :60 seconds label,
Yes.
> it doesn't make much sense to have a defined delta for the last UTC second of
> 2016.
No.
The delta is defined "until furth
1 - 100 of 119 matches
Mail list logo
