Re: [LEAPSECS] My FOSDEM slides

On 2015-03-05 08:39 AM, Martin Burnicki wrote: Tony Finch wrote: Martin Burnicki martin.burni...@meinberg.de wrote: I agree, but as I've tried to point out above I think a better project design would have been to use TAI instead of GPS time. PTP works natively with TAI, and you can easily

Re: [LEAPSECS] epoch of TAI, and TAI vis a vis GPS

On 2015-03-03 09:23 PM, Steve Allen wrote: On Wed 2015-03-04T00:04:10 +, Tony Finch hath writ: They have different epochs: TAI: 1958-01-01 T 00:00:00 Z PTP: 1970-01-01 T 00:00:00 Z GPS: 1980-01-06 T 00:00:00 Z Using ISO 8601 style date and time representation on the TAI timescale and on

Re: [LEAPSECS] My FOSDEM slides

On 2015-03-04 02:12 AM, michael.deckers via LEAPSECS wrote: On 2015-03-03 21:05, Martin Burnicki wrote about negative leap seconds: In the 7 year interval where no leap second was required/scheduled I heard several people saying we might have needed a negative leap second.

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

Hi Steve, On 2015-03-07 03:01 PM, Steve Allen wrote: On Sat 2015-03-07T14:14:07 -0500, Brooks Harris hath writ: It is typically warned that date and time before 1972 cannot be accurately represented with NTP or POSIX, for examples. I would say that for PTP * all seconds are always SI seconds

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

On 2015-03-07 06:50 PM, Joseph Gwinn wrote: On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote: In the discussions I've been involved with many people argued strenuously we don't care about the past, only accurate date-time going forward!. The reason I'm choosing to ignore the subject

Re: [LEAPSECS] Bulletin C and all that

On 2015-01-25 04:57 PM, G Ashton wrote: Brooks Harris mentioned, at approximately Sun 1/25/2015 21:02 UT, a Gregorian timescale. I believe that since in Gregory's time there was no alternative to making the passage of calendar days agree with the day/night cycle, we must understand Gregorian

Re: [LEAPSECS] Bulletin C and all that

synchronized with Mean Solar Time. How about leap_second_epoch or if the term epoch is undesirable leap_seconds_origin labelled as leap00 Ok, I'll re-index to leap0 and have a new cname called origin.leapsec.com. How's that? On Jan 25, 2015, at 2:01 PM, Brooks Harris bro...@edlmax.com wrote: TAI

Re: [LEAPSECS] Bulletin C and all that

I agree with Michael. The (proper) UTC timescale does not exist before 1972-01-01T00:00:00Z (UTC). That's the beginning of modern (solar) time. There was, or is, *by definition*, an initial 10 (integral!) second TAI-UTC offset at that moment. There is no agreed on a term for these initial 10

Re: [LEAPSECS] stale leap second information

On 2015-01-13 01:44 PM, Hal Murray wrote: If I understand the provenance, BIPM is responsible for maintaining atomic time and TAI, IERS is responsible maintaining for UT1 and Leap Seconds, and ITU is responsible for time dissemination. Whats not so clear, and it would be reassuring to know,

Re: [LEAPSECS] Google, Amazon, now Microsoft

On 2015-06-03 10:55 AM, Poul-Henning Kamp wrote: In message 556f0c92.4020...@edlmax.com, Brooks Harris writes: You're saying this to the bloke who implemented a prototype adaptive optics solution for the ESO ELT on a plain, unmodified FreeBSD kernel ? I didn't know that, very

Re: [LEAPSECS] Google, Amazon, now Microsoft

On 2015-05-31 04:40 AM, Poul-Henning Kamp wrote: In message556abecf.2050...@edlmax.com, Brooks Harris writes: My question is, if Azure is doing this, what is Windows itself doing? No. for that no new information is available and the most recent guidance was that somewhere between

Re: [LEAPSECS] Google, Amazon, now Microsoft

Hi Poul-Henning, On 2015-05-31 03:33 PM, Poul-Henning Kamp wrote: In message 556b5d76.6000...@edlmax.com, Brooks Harris writes: Most Windows boxes don't run NTP. I don't think that's true. As far as I know, Windows, either personal or Server versions, synchronize using NTP, and did

Re: [LEAPSECS] Google, Amazon, now Microsoft

Hi Tom, On 2015-05-31 07:23 PM, Tom Van Baak wrote: Hi Brooks, I don't know enough about Windows timekeeping in general or versions of Windows in particular to give you any authoritative answer. But here's one data point that might help clarify what you and PHK are talking about. On Windows

Re: [LEAPSECS] Google, Amazon, now Microsoft

On 2015-06-01 12:37 PM, Tom Van Baak wrote: Tom Van Baak said: On a positive note, this means one could actually experience more than one Windows non-leap-second on June 30. Maybe this year I should try to celebrate the leap second twice, in Mountain and in Pacific time. Time to pull out the

Re: [LEAPSECS] authoritative tz project info

On 2015-06-01 03:25 PM, Steve Allen wrote: On Mon 2015-06-01T12:05:08 -0700, Tom Van Baak hath writ: Can you send me a definitive URL with global TZ rules so I can grep|sort|uniq to get a feel for when DST transitions occurs? I guess I thought it always was 2 am local (which implies jumps from

Re: [LEAPSECS] Google, Amazon, now Microsoft

Hi Tom and Rob, On 2015-05-30 06:05 PM, Tom Van Baak wrote: Perhaps one should point out that local midnight is pretty much the worst possible time for astronomers to accommodate such a change? Hi Rob, Oh, you're such an old earth+photon guy. Ask any space probe, neutrino, or gravitational

Re: [LEAPSECS] Google, Amazon, now Microsoft

On 2015-05-31 03:57 AM, Brooks Harris wrote: On 2015-05-31 02:41 AM, Poul-Henning Kamp wrote: In message 556a6bd2.50...@edlmax.com, Brooks Harris writes: I can't find any authoritative announcement or statement to this effect from Microsoft, [...] Please note that this is *only

Re: [LEAPSECS] Google, Amazon, now Microsoft

On 2015-05-31 02:41 AM, Poul-Henning Kamp wrote: In message 556a6bd2.50...@edlmax.com, Brooks Harris writes: I can't find any authoritative announcement or statement to this effect from Microsoft, [...] Please note that this is *only* about Microsofts Azure cloud service, Yes

Re: [LEAPSECS] Bong

I synced my Windows 7 using my own SNTP implementation about two minutes before 8PM New York (Eastern Daylight Time). The SNTP data reported the Windows within 0.0004 of the NTP - pretty good! I watched the Windows clock carefully. It counted up 8:00:56, 57, 58, 59 as expected with a nice one

Re: [LEAPSECS] EBML: yet another date format?

On 2015-06-29 02:19 AM, Hal Murray wrote: Looks to me they mean 128 bits? How did you get that? Er, by not thinking very clearly :-\ supported by a signed 8-octet integer in nanoseconds centered on 8*8 is 64. I didn't see anything about using two of them. Right. My obvious error. POSIX

Re: [LEAPSECS] EBML: yet another date format?

On 2015-06-28 07:31 AM, Hal Murray wrote: Can somebody do the math to figure out what range of dates would be supported by a signed 8-octet integer in nanoseconds centered on 2001-01-01? 64 bits of nanoseconds covers 584 years divide by 2 if you want signed (63 bits) Looks to me they mean 128

Re: [LEAPSECS] a new type of negative leap second

Problem solved! On 2015-06-29 01:47 PM, Tom Van Baak wrote: The folks at http://www.timeanddate.com/time/leapseconds.html have a leap second animation on the top right side of the page. I'm not sure how it displays for you, but attached are some screen shots on my end. Cute. /tvb

[LEAPSECS] 1001 ways to beat a Leap Second

ASX Management of the International Leap Second http://www.sfe.com.au/content/notices/2015/0291.15.03.pdf -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] What happened in the late 1990s to slow the rate of leap seconds?

Hi Steve, I just wanted to compliment you on the huge about of work in these pages. Its a fantastic collection of facts and your explanations and commentary are extremely helpful. Well done and thank you. -Brooks On 2015-11-08 10:15 PM, Steve Allen wrote: On Sun 2015-11-08T18:51:37 -0800,

Re: [LEAPSECS] dismaying news

LEAPSECS is back in business! -Brooks On 2015-11-18 12:25 AM, Steve Allen wrote: Last Thursday the chair of WRC-15 Special Working Group 5A3 submitted Temporary Document [68] Proposals relating to agenda item 1.14 http://www.itu.int/md/R15-WRC15-151102-TD-0068/en No further meetings of SWG 5A3

Re: [LEAPSECS] countdown to WRC-15

Thanks Steve, I was wondering what was going on (but lazily didn't go hunting). Did the question change? It seems like the current statement is more elaborate, if seemingly somewhat tangled, from earlier versions? ...LEAPSECS/ITU-R/R15-WRC15PREPWORK-C-0008!!PDF-E.pdf WRC-15 agenda item 1.14

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

On 2016-04-25 12:54 AM, John Sauter wrote: On Sun, 2016-04-24 at 20:33 -0400, Brooks Harris wrote: Hi John, I like the idea in general, even if its a solution in search of a problem. I think many fields would find it useful if it found agreement and acceptance. Consider this: For your

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

On 2016-04-25 11:11 AM, John Sauter wrote: On Mon, 2016-04-25 at 09:40 -0400, Brooks Harris wrote: Hi John, "understood and widely used ", yes. Standardized by an international standards organization, I'm not sure. Anyone know of one? There's a lot of things in timekeeping tha

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

On 2016-04-27 11:53 AM, John Sauter wrote: On Wed, 2016-04-27 at 11:41 -0400, Brooks Harris wrote: Hi, One quick comment - Couldn't we computer folks start to use the very sensible ISO 8601 date format? For example EXPIRATION_DATE=2457751 # 2016 12 28 -Brooks I used Day Month Year

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

Hi, One quick comment - Couldn't we computer folks start to use the very sensible ISO 8601 date format? For example EXPIRATION_DATE=2457751 # 2016 12 28 -Brooks On 2016-04-27 11:14 AM, John Sauter wrote: I have written the sample code that Hal suggested, along with its data file. I

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

On 2016-04-27 05:11 PM, John Sauter wrote: On Wed, 2016-04-27 at 15:13 -0400, Brooks Harris wrote: I understand. But its always seemed to me those old formats should be obsolesced, that ISO 8601 presented an attractive alternative, that the YMDhms order made such good sense. Of course

Re: [LEAPSECS] Hawking / PBS TV show about Time

Oh that is just too cool! Well done! -Brooks On 2016-05-18 01:09 PM, Tom Van Baak wrote: Slightly off-topic, but this may be of interest to some of you who aren't also on the time-nuts list. Tonight, Wednesday evening (May 18) look for a TV show on National Geographic or PBS called "Genius

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Hi Warner, On 2016-07-20 11:34 AM, Warner Losh wrote: On Wed, Jul 20, 2016 at 8:23 AM, Brooks Harris <bro...@edlmax.com> wrote: Hi Tom, A couple questions and thoughts concerning standards and nomenclature - On 2016-07-20 01:08 AM, Tom Van Baak wrote: Hi Mark, Three comments: 1) I

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Hi Tom, A couple questions and thoughts concerning standards and nomenclature - On 2016-07-20 01:08 AM, Tom Van Baak wrote: Hi Mark, Three comments: 1) I recall this is a known problem in the Z3801A status reporting, and possibly other GPS receivers of that era as well. It stems indirectly

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

On 2016-07-20 11:27 AM, Martin Burnicki wrote: Brooks Harris wrote: On 2016-07-20 01:08 AM, Tom Van Baak wrote: I recall this is a known problem in the Z3801A status reporting, and possibly other GPS receivers of that era as well. It stems indirectly from a change years ago in how far

Re: [LEAPSECS] USNO press release

"WASHINGTON, DC -- On December 31, 2016, a "leap second" will be added to the world's clocks at 23 hours, 59 minutes and 59 seconds Coordinated Universal Time (UTC). This corresponds to 6:59:59 pm Eastern Standard Time, when the extra second will be inserted at the U.S. Naval Observatory's

Re: [LEAPSECS] USNO press release

will insert this positive Leap Second in the Eastern Standard Time (UTC-05:00) timescale on 2016-December-31 immediately following the second labeled 06:59:59 pm (18:59:59) and it will be labeled 06:59:60 pm (18:59:60). -Brooks On 2016-07-11 09:45 AM, Brooks Harris wrote: "WASHINGTO

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

contribution. And I think it's not "wrong". At least not yet. I think its "right", so far. :-) But it seems to have temporarily taken in (at least) Tom Van Baak and Brooks Harris, Standby. And I'm not sure Tom and I are seeing it the same way, yet. until we've all been set str

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

On 2017-01-31 04:44 PM, Warner Losh wrote: On Tue, Jan 31, 2017 at 2:20 PM, Brooks Harris <bro...@edlmax.com> 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

Re: [LEAPSECS] BBC radio Crowd Science

s using classic POSIX gmtime() (strict time_t and gmtime() operate on integral seconds) Two Leap Second metadata variables are required to support positive Leap Seconds: 1) TAI-UTC value 2) Is Leap Second - flag marking the actual Leap Second Negative Leap Seconds are not supported Brooks

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

On 2017-01-31 02:32 PM, Warner Losh wrote: On Tue, Jan 31, 2017 at 12:13 PM, Brooks Harris <bro...@edlmax.com> wrote: On 2017-01-31 01:52 PM, Warner Losh wrote: On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak <t...@leapsecond.com> wrote: 2017-01-01T00:00:36.5 - 36 s = 2016-12-3

Re: [LEAPSECS] BBC radio Crowd Science

On 2017-01-31 02:19 PM, Warner Losh wrote: On Tue, Jan 31, 2017 at 12:08 PM, Steve Allen <s...@ucolick.org> 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

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

On 2017-01-31 02:04 PM, Warner Losh wrote: On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <bro...@edlmax.com> wrote: On 2017-01-31 12:33 PM, Warner Losh wrote: On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit <scs...@eskimo.com> wrote: Tom Van Baak and Michael Decker wrote: 2017

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] Negative TAI-UTC

On 2017-02-04 03:27 PM, Warner Losh wrote: On Sat, Feb 4, 2017 at 11:12 AM, Brooks Harris <bro...@edlmax.com> wrote: On 2017-02-04 12:24 PM, Warner Losh wrote: On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather <cl...@davros.org> wrote: Looking only into the future, not historica

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

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

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

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] Negative TAI-UTC

On 2017-02-04 12:24 PM, Warner Losh wrote: On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather wrote: Looking only into the future, not historical data, what do people think the probability is that TAI-UTC will ever be negative? Should data structures be designed to handle

Re: [LEAPSECS] BBC radio Crowd Science

On 2017-01-31 02:53 PM, Warner Losh wrote: On Tue, Jan 31, 2017 at 12:41 PM, Brooks Harris <bro...@edlmax.com> wrote: On 2017-01-31 02:04 PM, Warner Losh wrote: On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <bro...@edlmax.com> wrote: On 2017-01-31 12:33 PM, Warner Losh wrote:

Re: [LEAPSECS] BBC radio Crowd Science

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:

Re: [LEAPSECS] BBC radio Crowd Science

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 assis

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

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,

Re: [LEAPSECS] BBC radio Crowd Science

On 2017-02-09 02:28 AM, Warner Losh wrote: On Fri, Feb 3, 2017 at 4:30 PM, Brooks Harris <bro...@edlmax.com> 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 *befor

Re: [LEAPSECS] Bloomberg announced its smear

On 2016-09-26 10:23 AM, Tony Finch wrote: Brooks Harris <bro...@edlmax.com> wrote: The short of it is Windows behave just like POSIX as far as I can tell, except its epoch, represented as struct FILETIME, is 1601-01-01T00:00:00 (UTC-like), which is, apparently the COBOL epoch (I didn't

Re: [LEAPSECS] Bloomberg announced its smear

Hi Tom, Stephen and Stephen; Adding to Stephen Scott's comments... On 2016-09-24 11:39 AM, Stephen Scott wrote: Hello Tom, Stephen; On 2016-09-24 08:26, Tom Van Baak wrote: Stephen, As I've been saying for years, what we need (desperately) is a standard for smearing, aka 86400 subdivision

Re: [LEAPSECS] Bloomberg announced its smear

Warner, On 2016-09-24 06:02 PM, Warner Losh wrote: On Sat, Sep 24, 2016 at 3:46 PM, Hal Murray wrote: tvb said: Smearing is fine. It's a practical solution to an intractable problem. But forcing everyone to implement it the exact same way misses the point. You can't

Re: [LEAPSECS] A standard for leap second smearing

Hi Tom, Seems to me this conversation is drifting back and forth between objectives. It started out to explore if a common method of smear could be found for purposes as Google, AWS, and Bloomberg are using it. As I understand it, the whole point there is to "hide" the Leap Second from the

Re: [LEAPSECS] Bloomberg announced its smear

Hmmm. You wonder why they chose 2000 seconds, which gives a nice round number of seconds for the duration: 2000/60=3.3... :-| So, now there are at least 3 different smears in use by major providers to "hide" the Leap Second from downstream systems that might be upset by it. This produces

Re: [LEAPSECS] Bloomberg announced its smear

Hi Tony, On 2016-09-26 09:52 AM, Tony Finch wrote: Brooks Harris <bro...@edlmax.com> wrote: Note too the discussions of how they increment the smear so as to not upset some receiver's PPL. Is anyone other than Google doing that? All the other smears I recall (UTC-SLS, Amazon, Bloomberg

Re: [LEAPSECS] Bloomberg announced its smear

/pipermail/leapsecs/2015-May/005920.html /tvb - Original Message ----- From: Brooks Harris To:leapsecs@leapsecond.com Sent: Sunday, September 25, 2016 11:19 AM Subject: Re: [LEAPSECS] Bloomberg announced its smear Hi Gerry, On 2016-09-25 07:58 AM, GERRY ASHTON wrote: The Microsoft Azur

Re: [LEAPSECS] Bloomberg announced its smear

Hi Gerry, On 2016-09-25 07:58 AM, GERRY ASHTON wrote: The Microsoft Azure approach of moving the leap second to local midnight has been discussed. I suppose you mean at LEAPSECS? If so I've missed that and be interested in the reference. I'd be interested in any other discussions of it as

Re: [LEAPSECS] Time Synchronization in Financial markets

On 2016-10-09 11:32 PM, John Sauter wrote: On Sun, 2016-10-09 at 15:12 -0400, Brooks Harris wrote: I took the lack of mention of leap seconds to mean that leap seconds ere not a problem. The output of the NISTDC units is an astonishingly accurate 1 pulse per second. That feeds NTP, which

Re: [LEAPSECS] Time Synchronization in Financial markets

Hi John, On 2016-10-09 12:41 PM, John Sauter wrote: On Sat, 2016-10-08 at 15:58 -0600, Warner Losh wrote: On Sat, Oct 8, 2016 at 2:43 PM, Steve Allen wrote: On Fri 2016-10-07T11:48:25 -0600, Warner Losh hath writ: Accurate, Traceable, and Verifiable Time Synchronization for

Re: [LEAPSECS] The Fuzzball

We owe much to the pioneering work described in the article, and particularly to David Mills' contributions to computer timekeeping. On 2017-01-09 09:57 PM, Brooks Harris wrote: The Fuzzball https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf Ah. PDP 11 running RT11 (the RT stands

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

1-08 12:59 PM, Brooks Harris wrote: On 2017-01-08 10:15 AM, Martin Burnicki wrote: Brooks Harris wrote: On 2017-01-06 11:52 AM, Martin Burnicki wrote: - OS kernels with different features (Windows doesn't even know leap seconds, AFAIK) It is often repeated on LEAPSECS that "Windows do

[LEAPSECS] The Fuzzball

The Fuzzball https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf Ah. PDP 11 running RT11 (the RT stands for real-time, you know, and it was!). Bigger and much heavier than a breadbox it had a lot of power. Oh, wait, I mean it *used* a lot of power. And you could modify it with a

Re: [LEAPSECS] next leap second

On 2017-01-12 12:18 PM, Michael Shields via LEAPSECS wrote: On Wed, Jan 11, 2017 at 5:03 PM, Warner Losh wrote: On Wed, Jan 11, 2017 at 3:28 PM, Zefram wrote: It would be nice to have more sophisticated projections from IERS more than a year ahead. It would

Re: [LEAPSECS] next leap second

IERS Technical Note No. 36 IERS Conventions (2010) ftp://tai.bipm.org/iers/conv2010/tn36.pdf -Brooks On 2017-01-12 01:08 PM, Brooks Harris wrote: On 2017-01-12 12:18 PM, Michael Shields via LEAPSECS wrote: On Wed, Jan 11, 2017 at 5:03 PM, Warner Losh <i...@bsdimp.com> wrote: On Wed,

Re: [LEAPSECS] private smear goes public

Hi Stephen, On 2016-12-01 02:49 AM, Stephen Colebourne wrote: More details on the developer site: https://developers.google.com/time/ Notably this page: https://developers.google.com/time/smear which include "Our proposed standard smear" - "We would like to propose to the community, as the

Re: [LEAPSECS] private smear goes public

and there are different requirements of users. No single approach is likely to satisfy all. There is a requirement for a minimal set of standardized approaches. -Stephen On 2016-12-01 12:39, Brooks Harris wrote: Hi Stephen, On 2016-12-01 02:49 AM, Stephen Colebourne wrote: More details on the developer site

Re: [LEAPSECS] private smear goes public

On 2016-12-01 06:28 PM, Stephen Colebourne wrote: On 1 December 2016 at 19:45, Brooks Harris <bro...@edlmax.com> wrote: As I read it I think Google's intention is to publish their method and algorithm in the hopes others may follow it. It would be better if everybody did it the sa

Re: [LEAPSECS] private smear goes public

Hi Warner, On 2016-12-01 08:02 PM, Warner Losh wrote: On Thu, Dec 1, 2016 at 4:28 PM, Stephen Colebourne <scolebou...@joda.org> wrote: On 1 December 2016 at 19:45, Brooks Harris <bro...@edlmax.com> wrote: As I read it I think Google's intention is to publish their method a

Re: [LEAPSECS] private smear goes public

On 2016-11-30 10:23 PM, Michael Shields via LEAPSECS wrote: On Wed, Nov 30, 2016 at 7:06 PM, Brooks Harris <bro...@edlmax.com> wrote: One wishes announments like this were a bit more accurate. They say "... we'll run the clocks 0.0014% slower across the ten hours before and ten

Re: [LEAPSECS] private smear goes public

Hi Tom, Sure enough, it's there. I've got an SNTP client I built for Windows I use for simple investigations. It connects to time.google.com just fine. (And, by the way, shows a much shorter round-trip-delay than nist ntp servers I've used). One wishes announments like this were a bit more

Re: [LEAPSECS] private smear goes public

Thanks Tony, On 2016-12-02 10:03 AM, Tony Finch wrote: Brooks Harris <bro...@edlmax.com> wrote: Can you explain that copyright issue further? I was under the impression Bulletin C and related from IERS were public. There was a discussion of this issue on the tz list in February

Re: [LEAPSECS] private smear goes public

On 2016-12-02 12:57 AM, Warner Losh wrote: On Thu, Dec 1, 2016 at 6:49 PM, Brooks Harris <bro...@edlmax.com> wrote: Hi Warner, On 2016-12-01 08:02 PM, Warner Losh wrote: On Thu, Dec 1, 2016 at 4:28 PM, Stephen Colebourne <scolebou...@joda.org> wrote: On 1 December 2016 at 1

Re: [LEAPSECS] private smear goes public

Hi Tony, On 2016-12-02 08:43 AM, Tony Finch wrote: Poul-Henning Kamp wrote: I don't know what the effective latency is from IERS -> TZdata -> distros -> releases -> users -> computers, but 6 months is only going to be enough if everybody pays maximum attention *EVERY*

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2017-01-04 09:15 PM, Steve Summit wrote: Martin Burnicki wrote: If we don't look only at the kernel and ntpd, but also consider PTP, then there's still the question if if wouldn't be better to let the kernel time run on TAI, and derive true and/or smeared UTC from it. Right. At first when

Re: [LEAPSECS] Time math libraries, UTC to TAI

t; literally being a religious issue). On January 6, 2017 at 5:50 PM Brooks Harris <bro...@edlmax.com> wrote: On 2017-01-05 09:33 PM, Steve Summit wrote: Brooks Harris wrote: It seems to me infeasible to alter the basic behavior of time_t because it effects every aspect of the operating sy

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-06 11:33 AM, Martin Burnicki wrote: Brooks Harris wrote: On 2017-01-05 05:56 AM, Tony Finch wrote: Martin Burnicki<martin.burni...@burnicki.net> wrote: Please note that NTP servers not necessarily need to be providers for leap second files. There are some well known sites

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2016-12-28 04:16 PM, Steve Allen wrote: On Wed 2016-12-28T16:00:17 -0500, Brooks Harris hath writ: I don't think so. This is POSIX so-called "1970-01-01 00:00:00 UTC" not 1588/PTP. 1588/PTP epoch is 10s earlier. At 1970-01-01 the difference TAI - UTC(BIH) was 8.82 SI second

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2016-12-30 12:56 PM, Stephen Scott wrote: NOT "unintentional" -S On 2016-12-30 11:37, Brooks Harris wrote: In SMPTE standards parlance the first sentence is normative, but the "Note" is informative. The intention of the note is to inform implementers that the

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2016-12-30 12:39 PM, Steve Allen wrote: On Fri 2016-12-30T11:37:38 -0500, Brooks Harris hath writ: There is a hole in the data of these tables; Rec 460 tells us the origin of TAI is "1 January 1958" but the first TAI-UTC value listed in the tables is in 1961 - what happened be

Re: [LEAPSECS] The POSIX Time Rationale - in the Working Group's own words

On 2016-12-30 12:11 PM, Steve Allen wrote: On Fri 2016-12-30T10:49:19 -0500, Joseph Gwinn hath writ: It may prove useful to know why the POSIX Working Group (WG) excluded leap seconds, in their own words. A bit more insight comes from the 1986 draft POSIX and the 1988 first version of the

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2017-01-02 03:07 PM, Michael.Deckers. via LEAPSECS wrote: On 2017-01-02 18:55, Brooks Harris wrote about the correspondence | Date| MJD| NTP | NTP Timestamp | Epoch| | 4 Oct 1582 | -100,851 | -3 | 2,873,647,488 | Last day Julian | Ah, I

Re: [LEAPSECS] alternative to smearing

On 2017-01-05 06:26 AM, Hal Murray wrote: [do something N years in the future] Except that's not how things are programmed. Programming it that way would be very inefficient in a part of the kernel that has to be ultra-efficient. Since you don't know how many seconds it will from now, you can't

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-05 05:56 AM, Tony Finch wrote: Martin Burnicki wrote: Please note that NTP servers not necessarily need to be providers for leap second files. There are some well known sites which provide this file, and the NTP software package from ntp.org comes with

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2017-01-07 07:40 AM, Steve Summit wrote: Brooks Harris wrote: This is related to Harlan's "General Timestamp API" project, I think. What's that? General Timestamp API Project http://nwtime.org/projects/timestamp-api/ -Brooks __

Re: [LEAPSECS] Time math libraries, UTC to TAI

On 2016-12-31 01:21 AM, Zefram wrote: Brooks Harris wrote: There is a hole in the data of these tables; Rec 460 tells us the origin of TAI is "1 January 1958" but the first TAI-UTC value listed in the tables is in 1961 - what happened between 1958 and 1961? You've previously

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-08 10:15 AM, Martin Burnicki wrote: Brooks Harris wrote: On 2017-01-06 11:52 AM, Martin Burnicki wrote: - OS kernels with different features (Windows doesn't even know leap seconds, AFAIK) It is often repeated on LEAPSECS that "Windows doesn't even know leap seconds". T

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

On 2017-01-07 02:50 AM, Hal Murray wrote: leapsecs-requ...@leapsecond.com said: Right, that's where I say its incredible nothing was done since 1972. The Leap Second history is fundamental, and it seems to me an obvious missing link. How could it have gone ignored all this time? Back in the

<    1   2   3   >