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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 +
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
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
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
> 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.
>
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
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
22 matches
Mail list logo