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

And somebody paid well over 10 times the market rate to lease server space that was one building closer to the NYSE computers. My idea to put an end to this bogo-trading nonsense is to add a random delay to all the trades. > Someone recently built a new fiber route

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

I'd be interested to know how 10ns less latency is useful. AFAIK, a high speed trading system consists of multiple processing nodes, which certainly could have a 10ns accurate time reference eg via PTP, but latency and jitter would limit time stamping of transactions to the microsecond level.

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

We've been dealing with speed of light issues for over 20 years in the financial world. And telecom. Someone recently built a new fiber route from Chicago to NY because it was just a touch shorter. The distances are down to hundredths of a ms. > On Jul 25, 2016, at 17:41, Bob Camp

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

A second here or there is a very big deal to those of us in the financial and database worlds. Aside from the well known instances involving electronic trading I have customers fighting over cabinet positions and cable lengths to place processors closer to disk drives and on switch paths

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

Hi In these days of computers trading with computers, the whole issue of “who did what when” can result in major money trading hands. I’m sure that at some point the financial markets will have to deal with light speed issues and geography if they have not already. Bob > On Jul 25, 2016,

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

Apple's new file system timestamps files with nanosecond resolution. A lot of Linux file systems also do that now. The nanosecond ain't what it used to be... I can imagine people wanting picosecond timestamps in the near future. Who knows, maybe we'll have something like NTP compensating

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

Hi > On Jul 25, 2016, at 10:21 AM, Martin Burnicki > wrote: > > Bob, > > Bob Camp wrote: >> Hi >> >> The practical problem with any change to leap seconds is transition from >> what we have >> to the “new system”. Anything other than dropping them altogether

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

Bob, Bob Camp wrote: > Hi > > The practical problem with any change to leap seconds is transition from what > we have > to the “new system”. Anything other than dropping them altogether involves a > *lot* of > coordination. You pretty much have to pick a date and bring everything onto > the

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

Am 22.07.2016 um 10:44 schrieb Martin Burnicki: > Tom Van Baak wrote: >> Time to mention this again... >> >> If we adopted the LSEM (Leap Second Every Month) model then none of >> this would be a problem. The idea is not to decide *if* there will be >> leap second, but to force every month to

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

Hi The practical problem with any change to leap seconds is transition from what we have to the “new system”. Anything other than dropping them altogether involves a *lot* of coordination. You pretty much have to pick a date and bring everything onto the new standard then. For testing

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

Tom Van Baak wrote: > Time to mention this again... > > If we adopted the LSEM (Leap Second Every Month) model then none of > this would be a problem. The idea is not to decide *if* there will be > leap second, but to force every month to have a leap second. The IERS > decision is then what the

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

On 7/21/2016 2:53 PM, Steve Allen wrote: > On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ: >> Time to mention this again... >> Every UTC-aware device would 1) know how to reliably insert or >> delete a leap second, because bugs would be found by developers within >> a month or two, not

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

> This idea pushes extra complexity into every implementation of low > level kernel-space software, firmware, and hardware. That's nice as a > policy for full employment of programmers, but it's hard to justify by > any other metric. Instead those low level places should be as simple > as

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

Steve Allen wrote: > This idea pushes extra complexity into every implementation of low > level kernel-space software, firmware, and hardware. That's nice as a > policy for full employment of programmers, but it's hard to justify by > any other metric. Instead those low level places should be as

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

I was inclined to agree, cynically reasoning that many implementations would argue that the leapseconds would average out in most applications and they could ignore them. But actually, it would be good for programmers to properly separate the concepts of elapsed time and clock-time. If elapsed

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

On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ: > Time to mention this again... > Every UTC-aware device would 1) know how to reliably insert or > delete a leap second, because bugs would be found by developers within > a month or two, not by end-users years or decades in the future,

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

Hi Tom, This message is an excellent example of why we invited you to speak at the Science of Time symposium ;-) It was a shame you couldn’t make it, since you would have made an excellent meeting even stronger. But future meetings in the series seem very likely and let me register an