Re: [LEAPSECS] Time Synchronization in Financial markets

[Steffen Nurpmeso]

Warner Losh  wrote:
 |On Mon, Oct 10, 2016 at 12:02 AM, Hal Murray  \
 |wrote:
  ...
 |>> Not being a traditionalist myself, I don't feel that there is anything \
 |>> wrong
 |>> with 23:59:60 as a label for a particular second.
 |>
 |> Unfortunately, POSIX says that second doesn't exist so a lot of the \
 |> software
 |> you use can't handle it.
 |
 |And a system that returns a POSIX time does undefined things for the
 |leap second by definition...

I don't understand why these persons use civil time at all.
Working with multiple clocks at a time is the reality of many.
And, as far as i understand, they seem to have the environment to
keep on going with the correct time, regardless.  I.e., they can
choose, whereas i can not (easily, at least).

(Well.  These bet on the live of the children of mothers still to
be born, they, ~25 years ago, did move more money on a single day
than entire humanity produces, exploits and generates in a whole
year, with 20 year olds who move more money a day than more than
just one entire nation generates in a whole year.  What money is
this?  It doesn't exist.  (And not even taking into account the
debt level of the U.S. at that time.)  So in my opinion it is not
responsible to give these unreflected subjects control over
resources and food, and life in general.  It is however
understandable that the necessity to assure a livelihood and or
professional ambition demands working with these people.)

It was an interesting reading (i skipped over the maths, of
course), especially so the necessity for calibration and the
interference factors that have been taken into account.  It is
fascinating to see how much we have learned, even though much of
the physics and chemistry etc. is in active use whereas not fully
understood.  (Just yesterday i've read about the Haber-Bosch
process, for example, which was in use a long time before it could
be explained in detail, as far as i have understood.)  All the
physical values that are involved, tidals, tectonics, atmosphere
denseness, earth rotation and position in the solar system,
human-caused emissions, that makes it pretty impressive to end up
with such a high accuracy, all over the world.

--steffen
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[Martin Burnicki]

Hal Murray wrote:
> 
> i...@bsdimp.com said:
>> Except, last I checked, NTP doesn't use this. And applications don't re-read
>> the zone file info when they are updated, so long running applications will
>> use the old data. Also, that file doesn't have then pending leap second this
>> December in it since the date is too old. 
> 
> ntp has code to read that file.  It takes a
>   leapfile 
> in your ntp.conf
> 
> 
> If it's time for a new one, ntpd checks for a new version every 24 hours.

Yes, but only ntpd 4.2.8 does so, and re-reads an updated file
automatically.

Earlier versions didn't re-read the file. You had to restart ntpd. Also,
ntpd 4.2.6 accepts a leap second file even if it is expired. This was
intentional by Dave Mills. As a consequence this means that ntpd 4.2.6
will *not* handle a leap second even though an upstream NTP server or a
GPS refclock provides a valid announcement, if ntpd has been provided
with an outdated leap second file.

Martin

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[Martin Burnicki]

John Sauter 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 handles leap
> seconds using a table.  As long as the table is kept up to date,
> everyone agrees on each second's name.

I don't think this is true.

On *ix systems ntpd uses the leap second table *only* as one possible
source to determine that a leap second has been scheduled. As a
consequence a leap second announcement flag is included in the replies
to the NTP clients, and is also passed to the OS kernel.

It's the kernel who actually inserts the leap second by stepping the
binary system time back, and as already mentioned in my other reply most
library functions are unable to distinguish the leap second from the
"normal" second, and thus yield the same time 23:59:59 twice.

This is similar to the end of DST, where a particular hour is repeated,
and you don't know if you refer to the first or second occurrence if you
don't take the DST status into account.

Martin

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[Brooks Harris]

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 handles leap
seconds using a table.  As long as the table is kept up to date,
everyone agrees on each second's name.

  Except the one to be called -MM-DDT23:59:60.

There are 86401 pegs in the (positive) Leap Second UTC day. There are
86400 holes in traditional timescales in which to put them. Something
has to to go missing - the mapping is indeterminate. Common practice
of introducing Leap Seconds on local timescales simultaneous with its
introduction at UTC places these indeterminate labels at different
time-of-day points along each local timescale. Non standardized and
politically driven Daylight Savings rules further complicates when
these indeterminate moments occur. Meantime there is no standardized
way to keep the Leap Second tables automatically updated to begin
with.

-Brooks

Not being a traditionalist myself, I don't feel that there is anything
wrong with 23:59:60 as a label for a particular second.  Thus, I don't
feel the need to map the 86,401 seconds of the last day of 2016 into
86,400 "holes", and therefore I do not suffer any indeterminacy.
 John Sauter (john_sau...@systemeyescomputerstore.com)
You are a fortunate individual. I continue to suffer from intermittent 
lags due to temporal radiation exposure.

-Brooks



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[Warner Losh]

On Mon, Oct 10, 2016 at 12:02 AM, Hal Murray  wrote:
>
>> Meantime there is no standardized way to  keep the Leap Second tables
>> automatically updated to begin with.
>
> It's being distributed with the time zone data.  Hopefully, all the major
> distros/OSes will include it by the end of the year.  (Don't hold your
> breath.)
>
> From Debian jessie
> -rw-r--r-- 1 root root 10384 Feb 22  2016 /usr/share/zoneinfo/leap-seconds.lis
> t

Except, last I checked, NTP doesn't use this. And applications don't
re-read the zone file info when they are updated, so long running
applications will use the old data. Also, that file doesn't have then
pending leap second this December in it since the date is too old.

>> Not being a traditionalist myself, I don't feel that there is anything wrong
>> with 23:59:60 as a label for a particular second.
>
> Unfortunately, POSIX says that second doesn't exist so a lot of the software
> you use can't handle it.

And a system that returns a POSIX time does undefined things for the
leap second by definition...

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[Hal Murray]

> Meantime there is no standardized way to  keep the Leap Second tables
> automatically updated to begin with.

It's being distributed with the time zone data.  Hopefully, all the major 
distros/OSes will include it by the end of the year.  (Don't hold your 
breath.)

>From Debian jessie
-rw-r--r-- 1 root root 10384 Feb 22  2016 /usr/share/zoneinfo/leap-seconds.lis
t


> Not being a traditionalist myself, I don't feel that there is anything wrong
> with 23:59:60 as a label for a particular second.

Unfortunately, POSIX says that second doesn't exist so a lot of the software 
you use can't handle it.


-- 
These are my opinions.  I hate spam.



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[John Sauter]

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 handles leap
> > seconds using a table.  As long as the table is kept up to date,
> > everyone agrees on each second's name.
>  Except the one to be called -MM-DDT23:59:60.
> 
> There are 86401 pegs in the (positive) Leap Second UTC day. There are
> 86400 holes in traditional timescales in which to put them. Something
> has to to go missing - the mapping is indeterminate. Common practice
> of introducing Leap Seconds on local timescales simultaneous with its
> introduction at UTC places these indeterminate labels at different
> time-of-day points along each local timescale. Non standardized and
> politically driven Daylight Savings rules further complicates when
> these indeterminate moments occur. Meantime there is no standardized
> way to keep the Leap Second tables automatically updated to begin
> with.
> 
> -Brooks

Not being a traditionalist myself, I don't feel that there is anything
wrong with 23:59:60 as a label for a particular second.  Thus, I don't
feel the need to map the 86,401 seconds of the last day of 2016 into
86,400 "holes", and therefore I do not suffer any indeterminacy.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[Brooks Harris]

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
World
Financial Markets

http://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf

Market synchronization requirements today are 1s. However, in
August
2017 they become 50ms. Good thing normal market hours on the US
exchanges avoids the leap second...

Notably missing in this document is any mention of the term leap
second.
More surprising is no mention of TAI, despite the numerous
references
to the use of IEEE 1588 PTP for the timing systems.
It's like getting a tour map that describes the route but fails to
mention that along the way there's a bridge out.

Yes, it's like all the other systems I worked on that required
external UTC to be correct at all times, even when the GPS receiver
doesn't yet know the current number of leap seconds. I'll have to
pass
the leap second comment along to the author...

Warner

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 handles leap
seconds using a table.  As long as the table is kept up to date,
everyone agrees on each second's name.

Except the one to be called -MM-DDT23:59:60.

There are 86401 pegs in the (positive) Leap Second UTC day. There are 
86400 holes in traditional timescales in which to put them. Something 
has to to go missing - the mapping is indeterminate. Common practice of 
introducing Leap Seconds on local timescales simultaneous with its 
introduction at UTC places these indeterminate labels at different 
time-of-day points along each local timescale. Non standardized and 
politically driven Daylight Savings rules further complicates when these 
indeterminate moments occur. Meantime there is no standardized way to 
keep the Leap Second tables automatically updated to begin with.


-Brooks

 John Sauter (john_sau...@systemeyescomputerstore.com)


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[John Sauter]

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
> > > World
> > > Financial Markets
> > > 
> > > http://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf
> > > 
> > > Market synchronization requirements today are 1s. However, in
> > > August
> > > 2017 they become 50ms. Good thing normal market hours on the US
> > > exchanges avoids the leap second...
> > 
> > Notably missing in this document is any mention of the term leap
> > second.
> > More surprising is no mention of TAI, despite the numerous
> > references
> > to the use of IEEE 1588 PTP for the timing systems.
> > It's like getting a tour map that describes the route but fails to
> > mention that along the way there's a bridge out.
> 
> Yes, it's like all the other systems I worked on that required
> external UTC to be correct at all times, even when the GPS receiver
> doesn't yet know the current number of leap seconds. I'll have to
> pass
> the leap second comment along to the author...
> 
> Warner

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 handles leap
seconds using a table.  As long as the table is kept up to date,
everyone agrees on each second's name.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[Steve Allen]

On Fri 2016-10-07T11:48:25 -0600, Warner Losh hath writ:
> Accurate, Traceable, and Verifiable Time Synchronization for World
> Financial Markets
>
> http://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf
>
> Market synchronization requirements today are 1s. However, in August
> 2017 they become 50ms. Good thing normal market hours on the US
> exchanges avoids the leap second...

Notably missing in this document is any mention of the term leap second.
More surprising is no mention of TAI, despite the numerous references
to the use of IEEE 1588 PTP for the timing systems.
It's like getting a tour map that describes the route but fails to
mention that along the way there's a bridge out.

--
Steve Allen  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] Time Synchronization in Financial markets

[Warner Losh]

This was just published with a friend as co-author:

Accurate, Traceable, and Verifiable Time Synchronization for World
Financial Markets

http://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf

Market synchronization requirements today are 1s. However, in August
2017 they become 50ms. Good thing normal market hours on the US
exchanges avoids the leap second...

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs