Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Warner Losh
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Zefram
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Steve Allen
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Tom Van Baak
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Brooks Harris
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Steve Allen
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Steve Allen
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Warner Losh
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Steve Summit
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Warner Losh
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Ask Bjørn Hansen
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Brooks Harris
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Brooks Harris
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Tony Finch
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Steve Summit
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Zefram
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 +

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Eric R. Smith
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Steve Summit
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread michael.deckers via LEAPSECS
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread GERRY ASHTON
> 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. >

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread michael.deckers via LEAPSECS
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

Re: [LEAPSECS] BBC radio Crowd Science

2017-02-01 Thread Zefram
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