Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
> Hi folks,
> 
> I've been asked off list to make the slides of my presentation at 
> FOSDEM 2015 in Brussels available and post the download link on this 
> list.
> 
> So here it is:
> 

> 
> See the "Attachment" link.

Very interesting; thanks for posting this.

I have a few questions and comments:

1.  Slide titled "Known Bugs (2)": Has support for negative leap 
seconds been restored in NTP v4?  It wasn't clear.

2.  Slide titled ""Possibilities for Future Improvements (2)":  In the 
wish list for a kernel call to ask if the kernel runs UTC or TAI, a 
couple of issues come to mind.  First, many systems set the GPS 
receiver to emit GPS System Time via NTP (and IRIG), so a GPS System 
Time option may be needed.  Second, we often have the GPS (or PTP 1588) 
receiver to emit GPS System Time, but never share this with downstream 
servers, who are configured for UTC (but strangely the leap seconds 
never come).  The difference between UTC and GPS System Time is handled 
in applications code.  The reason for this approach is so that the bulk 
of the system is free from step discontinuities, and only the 
interfaces need deal with UTC.

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

Re: [LEAPSECS] My FOSDEM slides

[Harlan Stenn]

Joseph Gwinn writes:
> On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
> > Hi folks,
> > 
> > I've been asked off list to make the slides of my presentation at 
> > FOSDEM 2015 in Brussels available and post the download link on this 
> > list.
> > 
> > So here it is:
> > 
>  agation_and_evaluation/>
> > 
> > See the "Attachment" link.
> 
> Very interesting; thanks for posting this.
> 
> I have a few questions and comments:
> 
> 1.  Slide titled "Known Bugs (2)": Has support for negative leap 
> seconds been restored in NTP v4?  It wasn't clear.

Not yet.  It's a tradeoff.

We've never needed to delete a leapsecond and depending on who you ask
it will probably never happen.

If we add the code to handle it, we increase complexity, potentially add
in a (pretty small) abuse vector (a bad actor could find a way to tell
your system to delete a second), and make some small demands on the test
framework that we want to have.

If we don't have it and we end up needing it, that causes different
problems.

There is a parallel issue about folks who cannot or do not upgrade their
software.  Over 1100 issues were addressed between 4.2.6 and 4.2.8 and
people still think 4.2.6 should be "good enough" for them.

We've probably fixed about 3000 issues since 4.2.0 and people still run
that.

We don't have numbers for the number of bugs fixed between xntp3.5f,
xntp3-5.86.5, ntp-4.0, ntp-4.1.{0,1,2}, and ntp-4.2.0.

These older releases are still running out there, too.

> 2.  Slide titled ""Possibilities for Future Improvements (2)":  In the 
> wish list for a kernel call to ask if the kernel runs UTC or TAI, a 
> couple of issues come to mind.  First, many systems set the GPS 
> receiver to emit GPS System Time via NTP (and IRIG), so a GPS System 
> Time option may be needed.  Second, we often have the GPS (or PTP 1588) 
> receiver to emit GPS System Time, but never share this with downstream 
> servers, who are configured for UTC (but strangely the leap seconds 
> never come).  The difference between UTC and GPS System Time is handled 
> in applications code.  The reason for this approach is so that the bulk 
> of the system is free from step discontinuities, and only the 
> interfaces need deal with UTC.

This issue is also address by NTF's General Timestamp API, as
"timescale" is one of the data elements of this timestamp.  We have
already done a proof-of-concept to get these timestamps used as the core
part of the kernel timekeeping API.  There is clearly more work to be
done here.  We know how to do this work, we just need technical and
financial support to make it happen.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

Harlan,

On Sun, 01 Mar 2015 20:35:20 +, Harlan Stenn wrote:
> Joseph Gwinn writes:
>> On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
>>> Hi folks,
>>> 
>>> I've been asked off list to make the slides of my presentation at 
>>> FOSDEM 2015 in Brussels available and post the download link on this 
>>> list.
>>> 
>>> So here it is:
>>> 
>> 

>>> 
>>> See the "Attachment" link.
>> 
>> Very interesting; thanks for posting this.
>> 
>> I have a few questions and comments:
>> 
>> 1.  Slide titled "Known Bugs (2)": Has support for negative leap 
>> seconds been restored in NTP v4?  It wasn't clear.
> 
> Not yet.  It's a tradeoff.
> 
> We've never needed to delete a leapsecond and depending on who you ask
> it will probably never happen.

So long as UTC can do negative leaps, and the Earth is a wobbly clock, 
the possibility is always with us.


> If we add the code to handle it, we increase complexity, potentially add
> in a (pretty small) abuse vector (a bad actor could find a way to tell
> your system to delete a second), and make some small demands on the test
> framework that we want to have.

The abuse vector argument is pretty weak -- the attacker could just as 
well add a leap second.  In both cases, one is off by a second.  So, I 
would submit that it's support for leap seconds that provides the 
attack surface, and the area of that surface is not reduced by 
elimination of negative leap seconds.

 
> If we don't have it and we end up needing it, that causes different
> problems.
> 
> There is a parallel issue about folks who cannot or do not upgrade their
> software.  Over 1100 issues were addressed between 4.2.6 and 4.2.8 and
> people still think 4.2.6 should be "good enough" for them.

Certainly in my world, changing software is a big deal, because one 
needs to rerun all the regression tests.  Changing NTP isn't as big a 
deal as changing the OS or the C++ compiler and/or libraries, but still 
people are wary.

 
> We've probably fixed about 3000 issues since 4.2.0 and people still run
> that.
> 
> We don't have numbers for the number of bugs fixed between xntp3.5f,
> xntp3-5.86.5, ntp-4.0, ntp-4.1.{0,1,2}, and ntp-4.2.0.
> 
> These older releases are still running out there, too.

And don't forget NTPv3 - bet lots of those still run.

Once people get a system to work, they don't tend to go fixing things 
that ain't broke.

 
>> 2.  Slide titled ""Possibilities for Future Improvements (2)":  In the 
>> wish list for a kernel call to ask if the kernel runs UTC or TAI, a 
>> couple of issues come to mind.  First, many systems set the GPS 
>> receiver to emit GPS System Time via NTP (and IRIG), so a GPS System 
>> Time option may be needed.  Second, we often have the GPS (or PTP 1588) 
>> receiver to emit GPS System Time, but never share this with downstream 
>> servers, who are configured for UTC (but strangely the leap seconds 
>> never come).  The difference between UTC and GPS System Time is handled 
>> in applications code.  The reason for this approach is so that the bulk 
>> of the system is free from step discontinuities, and only the 
>> interfaces need deal with UTC.
> 
> This issue is also address by NTF's General Timestamp API, as
> "timescale" is one of the data elements of this timestamp.  We have
> already done a proof-of-concept to get these timestamps used as the core
> part of the kernel timekeeping API.  There is clearly more work to be
> done here.  We know how to do this work, we just need technical and
> financial support to make it happen.

Great.  Is this API a parallel to the named clock interface of POSIX, 
where the OS kernel vendor can add named clocks that are not in the 
POSIX standard - what is standardized is the mechanism for defining and 
using special purpose clocks unknown to POSIX.

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

Re: [LEAPSECS] My FOSDEM slides

[Harlan Stenn]

Joseph Gwinn writes:
> On Sun, 01 Mar 2015 20:35:20 +, Harlan Stenn wrote:
> Once people get a system to work, they don't tend to go fixing things 
> that ain't broke.

There's breakage they know about and breakage they don't know about...

>>> 2.  Slide titled ""Possibilities for Future Improvements (2)":  In the 
>>> wish list for a kernel call to ask if the kernel runs UTC or TAI, a 
>>> couple of issues come to mind.  First, many systems set the GPS 
>>> receiver to emit GPS System Time via NTP (and IRIG), so a GPS System 
>>> Time option may be needed.  Second, we often have the GPS (or PTP 1588) 
>>> receiver to emit GPS System Time, but never share this with downstream 
>>> servers, who are configured for UTC (but strangely the leap seconds 
>>> never come).  The difference between UTC and GPS System Time is handled 
>>> in applications code.  The reason for this approach is so that the bulk 
>>> of the system is free from step discontinuities, and only the 
>>> interfaces need deal with UTC.
>> 
>> This issue is also address by NTF's General Timestamp API, as
>> "timescale" is one of the data elements of this timestamp.  We have
>> already done a proof-of-concept to get these timestamps used as the core
>> part of the kernel timekeeping API.  There is clearly more work to be
>> done here.  We know how to do this work, we just need technical and
>> financial support to make it happen.
> 
> Great.  Is this API a parallel to the named clock interface of POSIX, 
> where the OS kernel vendor can add named clocks that are not in the 
> POSIX standard - what is standardized is the mechanism for defining and 
> using special purpose clocks unknown to POSIX.

I haven't looked, and my instant thought is that the POSIX named
clock interface could trivially use the GTSAPI.  The timestamps provided
would include both a timescale and a "clock ID".
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

On Sun, 01 Mar 2015 22:25:36 +, Harlan Stenn wrote:
> Joseph Gwinn writes:
>> On Sun, 01 Mar 2015 20:35:20 +, Harlan Stenn wrote:
>> Once people get a system to work, they don't tend to go fixing things 
>> that ain't broke.
> 
> There's breakage they know about and breakage they don't know about...
> 
 2.  Slide titled ""Possibilities for Future Improvements (2)":  In the 
 wish list for a kernel call to ask if the kernel runs UTC or TAI, a 
 couple of issues come to mind.  First, many systems set the GPS 
 receiver to emit GPS System Time via NTP (and IRIG), so a GPS System 
 Time option may be needed.  Second, we often have the GPS (or PTP 1588) 
 receiver to emit GPS System Time, but never share this with downstream 
 servers, who are configured for UTC (but strangely the leap seconds 
 never come).  The difference between UTC and GPS System Time is handled 
 in applications code.  The reason for this approach is so that the bulk 
 of the system is free from step discontinuities, and only the 
 interfaces need deal with UTC.
>>> 
>>> This issue is also address by NTF's General Timestamp API, as
>>> "timescale" is one of the data elements of this timestamp.  We have
>>> already done a proof-of-concept to get these timestamps used as the core
>>> part of the kernel timekeeping API.  There is clearly more work to be
>>> done here.  We know how to do this work, we just need technical and
>>> financial support to make it happen.
>> 
>> Great.  Is this API a parallel to the named clock interface of POSIX, 
>> where the OS kernel vendor can add named clocks that are not in the 
>> POSIX standard - what is standardized is the mechanism for defining and 
>> using special purpose clocks unknown to POSIX.
> 
> I haven't looked, and my instant thought is that the POSIX named
> clock interface could trivially use the GTSAPI.  The timestamps provided
> would include both a timescale and a "clock ID".

Can you provide a link to where this General Timestamp API is defined?  
I'll look it over.

Thanks,

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

Re: [LEAPSECS] My FOSDEM slides

[Paul Hirose]

I recommend Leap Second Handling (1), "Enumeration of UTC seconds when 
inserting a leap second" be modified to half second steps:


2015-06-30 23:59:59.0
2015-06-30 23:59:59.5
2015-06-30 23:59:60.0
2015-06-30 23:59:60.5
2015-07-01 00:00:00.0
2015-07-01 00:00:00.5
2015-07-01 00:00:01.0

That makes clear the correct notation for events inside a leap second.

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

Re: [LEAPSECS] My FOSDEM slides

[Martin Burnicki]

Paul Hirose wrote:





I recommend Leap Second Handling (1), "Enumeration of UTC seconds when
inserting a leap second" be modified to half second steps:

2015-06-30 23:59:59.0
2015-06-30 23:59:59.5
2015-06-30 23:59:60.0
2015-06-30 23:59:60.5
2015-07-01 00:00:00.0
2015-07-01 00:00:00.5
2015-07-01 00:00:01.0

That makes clear the correct notation for events inside a leap second.


Good idea! I think I'll pick this up for future versions of the slides.

Thanks,

Martin
--
Martin Burnicki

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

Web: http://www.meinberg.de
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Martin Burnicki]

Joseph Gwinn wrote:

Harlan,

On Sun, 01 Mar 2015 20:35:20 +, Harlan Stenn wrote:

Joseph Gwinn writes:

1.  Slide titled "Known Bugs (2)": Has support for negative leap
seconds been restored in NTP v4?  It wasn't clear.


Not yet.  It's a tradeoff.

We've never needed to delete a leapsecond and depending on who you ask
it will probably never happen.


So long as UTC can do negative leaps, and the Earth is a wobbly clock,
the possibility is always with us.


I absolutely agree. It would have been better to fix this (in case it 
didn't work) than to remove the code which supported 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.


Fortunately we didn't, but I still think it's better to prepare for it, 
if possible than just ignore it and even remove existing support.


GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm 
not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has 
no flag defined to announce a negative leap second, so there would be 
major problems if one had to be inserted.



If we add the code to handle it, we increase complexity, potentially add
in a (pretty small) abuse vector (a bad actor could find a way to tell
your system to delete a second), and make some small demands on the test
framework that we want to have.


The abuse vector argument is pretty weak -- the attacker could just as
well add a leap second.  In both cases, one is off by a second.  So, I
would submit that it's support for leap seconds that provides the
attack surface, and the area of that surface is not reduced by
elimination of negative leap seconds.


Again, I strongly agree.


If we don't have it and we end up needing it, that causes different
problems.

There is a parallel issue about folks who cannot or do not upgrade their
software.  Over 1100 issues were addressed between 4.2.6 and 4.2.8 and
people still think 4.2.6 should be "good enough" for them.


Certainly in my world, changing software is a big deal, because one
needs to rerun all the regression tests.  Changing NTP isn't as big a
deal as changing the OS or the C++ compiler and/or libraries, but still
people are wary.



We've probably fixed about 3000 issues since 4.2.0 and people still run
that.

We don't have numbers for the number of bugs fixed between xntp3.5f,
xntp3-5.86.5, ntp-4.0, ntp-4.1.{0,1,2}, and ntp-4.2.0.

These older releases are still running out there, too.


And don't forget NTPv3 - bet lots of those still run.

Once people get a system to work, they don't tend to go fixing things
that ain't broke.


Yep.

Martin
--
Martin Burnicki

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

Web: http://www.meinberg.de
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Martin Burnicki]

Joseph Gwinn wrote:

On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:

Hi folks,

I've been asked off list to make the slides of my presentation at
FOSDEM 2015 in Brussels available and post the download link on this
list.

So here it is:





See the "Attachment" link.


Very interesting; thanks for posting this.

I have a few questions and comments:

1.  Slide titled "Known Bugs (2)": Has support for negative leap
seconds been restored in NTP v4?  It wasn't clear.


I have to admit that I wrote this before 4.2.8 had been released. 
Support for negative leap second has been in older NTP versions, but had 
been removed in 4.2.6.


Now in 4.2.8 the leap second code has been reworked and cleaned up, and 
a very quick look at the source code seems to indicate that this might 
work again. At least there's code which passes the announcement flag to 
the kernel, if kernel support is enabled.


I think I'll give it a try soon. I'd expect that a negative leap second 
might work if an appropriate announcement is received from a refclock or 
upstream NTP server, but it will be interesting to find out if this 
works with a NIST-style leap second file where the TAI offset decreases 
at a given date.



2.  Slide titled ""Possibilities for Future Improvements (2)":  In the
wish list for a kernel call to ask if the kernel runs UTC or TAI, a
couple of issues come to mind.  First, many systems set the GPS
receiver to emit GPS System Time via NTP (and IRIG), so a GPS System
Time option may be needed.


Yes.

Though I would prefer using TAI instead of raw GPS time if a linear time 
scale is required. What if you use a different GNSS receiver, e.g. for 
Galileo, or the Chinese Beidou?


GPS time (or whatever) is fine in closed projects/environments, but IMO 
a UTC and TAI are the "global" time scales, while GPS is specific to the 
U.S.



Second, we often have the GPS (or PTP 1588)
receiver to emit GPS System Time, but never share this with downstream
servers, who are configured for UTC (but strangely the leap seconds
never come).  The difference between UTC and GPS System Time is handled
in applications code.  The reason for this approach is so that the bulk
of the system is free from step discontinuities, and only the
interfaces need deal with UTC.


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 convert between he two scales.


Of course it's easy to convert GPS to TAI, and vice versa, but you have 
to take care that more types of conversions are required and implemented 
correctly.


Thanks for your feedback!


Martin
--
Martin Burnicki

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

Web: http://www.meinberg.de
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Hal Murray]

> GPS time (or whatever) is fine in closed projects/environments, but IMO  a
> UTC and TAI are the "global" time scales, while GPS is specific to the  U.S.

Since GPS time is a fixed offset from TAI, it's easy to convert.

My vote would be to use TAI rather than GPS wherever you are trying to avoid 
leap seconds.

(If you are dealing with GPS itself rather than time in general, it might 
make sense to use GPS time consistently throughout a project.)

-- 
These are my opinions.  I hate spam.



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

Re: [LEAPSECS] My FOSDEM slides

[Tony Finch]

Martin Burnicki  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 convert between he two scales.

I don't understand this paragraph. The three timescales you mention have
totally different formats:

TAI: -MM-DD T HH:MM:SS
PTP: SS
GPS:  SS

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

So I don't see how it makes sense to argue that PTP is more like TAI than
GPS time.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Irish Sea: West 6 to gale 8, decreasing 4. Moderate or rough. Showers. Good.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Harlan Stenn]

Hal Murray writes:
> 
> > GPS time (or whatever) is fine in closed projects/environments, but IMO  a
> > UTC and TAI are the "global" time scales, while GPS is specific to the  U.S
> .
> 
> Since GPS time is a fixed offset from TAI, it's easy to convert.
> 
> My vote would be to use TAI rather than GPS wherever you are trying to avoid 
> leap seconds.
> 
> (If you are dealing with GPS itself rather than time in general, it might 
> make sense to use GPS time consistently throughout a project.)

The Generl Timestamp API supports multiple timescales, so if there is a
GPS timescale that's easy.  If other satellite systems use different
timescales then that's perfectly OK too.

As long as there's a way to map these to/from a canonical form
(currently TAI) then we should be fine.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Tom Van Baak]

> GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm 
> not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has 
> no flag defined to announce a negative leap second, so there would be 
> major problems if one had to be inserted.

Both WWVB and DCF-77 have a single leap second warning bit. With WWVB you look 
at the sign of DUT1 to know if the leap is insert or delete. So WWVB is fine.

DCF-77 has no DUT1 or leap gender bit so, yes, there will be trouble. I'm sure 
PTB will figure something out if it ever comes to that.

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

Re: [LEAPSECS] My FOSDEM slides

[michael.deckers via LEAPSECS]

   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.


   Fortunately, this is not a matter of speculation. An easy way to
   see the trend of UT1 - UTC is to look at DUT1 (published in
   Bulletin D). DUT1 is an approximation to UT1 - UTC and has
   always stepped down (except, of course, at positive leap seconds),
   ever since the earliest Bulletin D available on the web (1991-06-20).

   Before a negative leap seconds would be scheduled, we would see
   DUT1 stepping up several times in a row, so there _is_ some
   advance warning.

   Michael Deckers.

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

Re: [LEAPSECS] My FOSDEM slides

[Brooks Harris]

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.


   Fortunately, this is not a matter of speculation. An easy way to
   see the trend of UT1 - UTC is to look at DUT1 (published in
   Bulletin D). DUT1 is an approximation to UT1 - UTC and has
   always stepped down (except, of course, at positive leap seconds),
   ever since the earliest Bulletin D available on the web (1991-06-20).

   Before a negative leap seconds would be scheduled, we would see
   DUT1 stepping up several times in a row, so there _is_ some
   advance warning.

We can't predict the future. It's fascinating to read about the many 
factors affecting Earth's rotation. It seems the largest one is the one 
we know least about - the Earth's core. I wonder what DUT1 would have 
looked like around the time of the Chicxulub impactor.


Negative Leap Seconds have been a feature of the specification since the 
beginning. It gives a little more margin to accommodate the unknown, and 
it's not an onerous complication. I hope we concentrate on helping get 
implementations to conform to the UTC specs as they stand rather than 
look for justifications to over simplify the problem.


-Brooks


Michael Deckers.

___
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] My FOSDEM slides

[Steffen Nurpmeso]

 |> GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm 
 |> not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has 
 |> no flag defined to announce a negative leap second, so there would be 
 |> major problems if one had to be inserted.
 |
 |Both WWVB and DCF-77 have a single leap second warning bit. \
 |With WWVB you look at the sign of DUT1 to know if the leap \
 |is insert or delete. So WWVB is fine.
 |
 |DCF-77 has no DUT1 or leap gender bit so, yes, there will \
 |be trouble. I'm sure PTB will figure something out if it ever comes to that.

While at it the PTB could take the leadership and, after having
dropped distributing the signed UT1-UT difference in 1977 (says
Wikipedia), start distributing the TAI-UTC difference in the same
slot, thus offering atomic time and civil time over DCF-77.

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

Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote:
> Joseph Gwinn wrote:
>> On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
>>> Hi folks,
>>> 
>>> I've been asked off list to make the slides of my presentation at
>>> FOSDEM 2015 in Brussels available and post the download link on this
>>> list.
>>> 
>>> So here it is:
>>> 
>> 

>>> 
>>> See the "Attachment" link.
>> 
>> Very interesting; thanks for posting this.
>> 
>> I have a few questions and comments:
>> 
>> 1.  Slide titled "Known Bugs (2)": Has support for negative leap
>> seconds been restored in NTP v4?  It wasn't clear.
> 
> I have to admit that I wrote this before 4.2.8 had been released. 
> Support for negative leap second has been in older NTP versions, but 
> had been removed in 4.2.6.
> 
> Now in 4.2.8 the leap second code has been reworked and cleaned up, 
> and a very quick look at the source code seems to indicate that this 
> might work again. At least there's code which passes the announcement 
> flag to the kernel, if kernel support is enabled.
> 
> I think I'll give it a try soon. I'd expect that a negative leap 
> second might work if an appropriate announcement is received from a 
> refclock or upstream NTP server, but it will be interesting to find 
> out if this works with a NIST-style leap second file where the TAI 
> offset decreases at a given date.

Hell - lots of code can't handle a positive leap second, so what hope 
is there?

 
>> 2.  Slide titled ""Possibilities for Future Improvements (2)":  In the
>> wish list for a kernel call to ask if the kernel runs UTC or TAI, a
>> couple of issues come to mind.  First, many systems set the GPS
>> receiver to emit GPS System Time via NTP (and IRIG), so a GPS System
>> Time option may be needed.
> 
> Yes.
> 
> Though I would prefer using TAI instead of raw GPS time if a linear 
> time scale is required. What if you use a different GNSS receiver, 
> e.g. for Galileo, or the Chinese Beidou?
> 
> GPS time (or whatever) is fine in closed projects/environments, but 
> IMO a UTC and TAI are the "global" time scales, while GPS is specific 
> to the U.S.

While TAI would be ideal for the reasons given, the problem is that TAI 
is not yet widely supported enough.  


>> Second, we often have the GPS (or PTP 1588)
>> receiver to emit GPS System Time, but never share this with downstream
>> servers, who are configured for UTC (but strangely the leap seconds
>> never come).  The difference between UTC and GPS System Time is handled
>> in applications code.  The reason for this approach is so that the bulk
>> of the system is free from step discontinuities, and only the
>> interfaces need deal with UTC.
> 
> 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 convert between he two 
> scales.
> 
> Of course it's easy to convert GPS to TAI, and vice versa, but you 
> have to take care that more types of conversions are required and 
> implemented correctly.

Right now, GPS System Time is the best solution.  In ten years, I bet 
the answer will be TAI.

 
> Thanks for your feedback!

Quite welcome.

Joe Gwinn


> Martin
> -- 
> Martin Burnicki
> 
> MEINBERG Funkuhren GmbH & Co. KG
> Email: martin.burni...@meinberg.de
> Phone: +49 (0)5281 9309-14
> Fax: +49 (0)5281 9309-30
> 
> Lange Wand 9, 31812 Bad Pyrmont, Germany
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
> Andre Hartmann, Heiko Gerstung
> Web: http://www.meinberg.de
> ___
> 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] My FOSDEM slides

[Joseph Gwinn]

On Tue, 03 Mar 2015 14:31:13 -0800, Hal Murray wrote:
> 
>> GPS time (or whatever) is fine in closed projects/environments, but IMO  a
>> UTC and TAI are the "global" time scales, while GPS is specific to 
>> the  U.S.
> 
> Since GPS time is a fixed offset from TAI, it's easy to convert.
> 
> My vote would be to use TAI rather than GPS wherever you are trying 
> to avoid 
> leap seconds.
> 
> (If you are dealing with GPS itself rather than time in general, it might 
> make sense to use GPS time consistently throughout a project.)

GPS System Time became embedded because it was what the available GPS 
receivers supported (in addiction to UTC).

TAI would work as well, were it available in the day.  It is just now 
becoming available from GPS receivers - I saw TAI as a choice in a 
Spectracom receiver, and assume that other makes do this as well.

The key issue is to use a timescale that is free of discontinuities.


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

Re: [LEAPSECS] My FOSDEM slides

[Steve Allen]

On Wed 2015-03-04T08:54:00 -0500, Joseph Gwinn hath writ:
> >> On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
> > I think I'll give it a try soon. I'd expect that a negative leap
> > second might work if an appropriate announcement is received from a
> > refclock or upstream NTP server, but it will be interesting to find
> > out if this works with a NIST-style leap second file where the TAI
> > offset decreases at a given date.
>
> Hell - lots of code can't handle a positive leap second, so what hope
> is there?

There's a lot of hope for negative leap seconds to be inconsequential
to a lot of code.

An overloaded operating system which is timesharing may suspend a
process for a long time, so when that process wakes up it may find
that it has missed a second.  A virtual machine running on a cloud
server farm in Oregon may be saved to disk, shipped across the
continent to North Carolina, and restarted over a second later -- or
kept on disk and replicated and restarted even later, multiple times.

What happens with a negative leap second is a lot like what happens to
non-real-time processes and machines as a routine part of operation.

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

Re: [LEAPSECS] My FOSDEM slides

[Martin Burnicki]

Joseph Gwinn wrote:

On Tue, 03 Mar 2015 14:31:13 -0800, Hal Murray wrote:
TAI would work as well, were it available in the day.  It is just now
becoming available from GPS receivers - I saw TAI as a choice in a
Spectracom receiver, and assume that other makes do this as well.


Meinberg receivers support this as well. ;-)

Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

Web: http://www.meinberg.de
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Martin Burnicki]

Tony Finch wrote:

Martin Burnicki  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 convert between he two scales.


I don't understand this paragraph. The three timescales you mention have
totally different formats:

TAI: -MM-DD T HH:MM:SS
PTP: SS
GPS:  SS

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

So I don't see how it makes sense to argue that PTP is more like TAI than
GPS time.


In the strict scientific sense I agree.

However, in practice, and for "current" dates, you can convert each of 
them to a number of seconds since the epoch, and for practical purposes 
the difference is just an integral number of seconds.


For example, the IEEE Std 1588-2008 says:

"The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969 
23:59:51.18 UTC"


However, the time stamps used in the PTP packets are just binary numbers 
of seconds, and you have to apply an integral number of seconds to 
convert this to UTC.


Similarly, the comments in the NIST leap second file say:

#   The second column shows the number of seconds that
#   must be added to UTC to compute TAI for any timestamp
#   at or after that epoch.

Even though the number of seconds between TAI and GPS timestamps is 
constant, if you use all the scales TAI/GPS/UTC in an application you 
have to do more different conversions than if you had only TAI and UTC.


Just imagine a PTP grandmaster, controlled by a GPS receiver which 
outputs raw GPS time.


Tony, I'm sure you know all of the above, but I just wrote this to make 
clear what I meant.


Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

Web: http://www.meinberg.de
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Martin Burnicki]

Tom,

Tom Van Baak wrote:

GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm
not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has
no flag defined to announce a negative leap second, so there would be
major problems if one had to be inserted.


Both WWVB and DCF-77 have a single leap second warning bit. With WWVB you look 
at the sign of DUT1 to know if the leap is insert or delete. So WWVB is fine.


Thanks for the hint.


DCF-77 has no DUT1 or leap gender bit so, yes, there will be trouble. I'm sure 
PTB will figure something out if it ever comes to that.


Hm, the question is if existing receivers could handle what they figure 
out, and I wonder if existing WWVB receivers check the sign of DUT1 to 
determine if an upcoming leap second is +1 or -1.


Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

Web: http://www.meinberg.de
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Martin Burnicki]

Brooks Harris wrote:

We can't predict the future. It's fascinating to read about the many
factors affecting Earth's rotation. It seems the largest one is the one
we know least about - the Earth's core. I wonder what DUT1 would have
looked like around the time of the Chicxulub impactor.

Negative Leap Seconds have been a feature of the specification since the
beginning. It gives a little more margin to accommodate the unknown, and
it's not an onerous complication. I hope we concentrate on helping get
implementations to conform to the UTC specs as they stand rather than
look for justifications to over simplify the problem.


I totally agree.

Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

Web: http://www.meinberg.de
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Martin Burnicki]

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.


Fortunately, this is not a matter of speculation.


I know.


An easy way to
see the trend of UT1 - UTC is to look at DUT1 (published in
Bulletin D). DUT1 is an approximation to UT1 - UTC and has
always stepped down (except, of course, at positive leap seconds),
ever since the earliest Bulletin D available on the web (1991-06-20).


Yes, but if you observe that DUT1 steps down slower and slower you can 
speculate whether it would start to step up over some years.



Before a negative leap seconds would be scheduled, we would see
DUT1 stepping up several times in a row, so there _is_ some
advance warning.


Agreed.


Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

Web: http://www.meinberg.de
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Martin Burnicki]

Joseph Gwinn wrote:

On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote:

Now in 4.2.8 the leap second code has been reworked and cleaned up,
and a very quick look at the source code seems to indicate that this
might work again. At least there's code which passes the announcement
flag to the kernel, if kernel support is enabled.

I think I'll give it a try soon. I'd expect that a negative leap
second might work if an appropriate announcement is received from a
refclock or upstream NTP server, but it will be interesting to find
out if this works with a NIST-style leap second file where the TAI
offset decreases at a given date.


Hell - lots of code can't handle a positive leap second, so what hope
is there?


Should we abandon everything which can't easily be handled, or where 
developers don't work thoroughly?



Right now, GPS System Time is the best solution.  In ten years, I bet
the answer will be TAI.


Agreed.

And we might already start to think about how to get this right in mixed 
environments, e.g. using the NTF's General timestamp API, or find a way 
to determine if the kernel time is UTC, or TAI.



Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung

Web: http://www.meinberg.de
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Brooks Harris]

On 2015-03-05 08:39 AM, Martin Burnicki wrote:

Tony Finch wrote:

Martin Burnicki  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 convert between he two scales.


I don't understand this paragraph. The three timescales you mention have
totally different formats:

TAI: -MM-DD T HH:MM:SS
PTP: SS
GPS:  SS

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

So I don't see how it makes sense to argue that PTP is more like TAI 
than

GPS time.


In the strict scientific sense I agree.

However, in practice, and for "current" dates, you can convert each of 
them to a number of seconds since the epoch, and for practical 
purposes the difference is just an integral number of seconds.

I agree.

We have seen the casual term "TAI-like", meaning an "uninterrupted 
incrementing count of seconds" from some epoch. PTP and GPS are 
"TAI-like" in that sense.


For example, the IEEE Std 1588-2008 says:

"The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 
1969 23:59:51.18 UTC"


However, the time stamps used in the PTP packets are just binary 
numbers of seconds, and you have to apply an integral number of 
seconds to convert this to UTC.


Yes, that's how it must be treated.

I urge caution interpreting the meaning of the PTP Epoch as stated in 
the spec.


The first part of that sentence is correct "The PTP epoch is 1 January 
1970 00:00:00 TAI". But the  second part, "which is 31 December 1969 
23:59:51.18 UTC", is not, or, is at least very misleading.


This of course begs the all questions regarding a "proleptic UTC" 
timescale. What, exactly, is that? Did it exist before 
1972-01-01T00:00:00Z (UTC)? Does it include the "rubber-band era" 
between approximately 1961 and 1972?


The spec goes through long explanations of the relation of its epoch to 
the "POSIX algorithm". It wanders through explanation of the 
"rubber-band" era, and how the "broken down time" results are obtained 
from gmtime(). This is all wicked confusing. Apparently the IEEE PTP 
committee took "UTC" to include the "rubber-band era", and so attempted 
to reconcile the PTP epoch to it.


In an *informative* Annex B - Timescales and epochs in PTP, there is 
further (confusing) explanation, but then comes Table B.1?Relationships 
between timescales. There we find -


Table B.1?Relationships between timescales

From  | To  |  Formula
NTP Seconds   | PTP Seconds | PTP Seconds = NTP Seconds ? 2 208 
988 800 + currentUtcOffset
PTP Seconds   | NTP Seconds | NTP Seconds = PTP Seconds + 2 208 
988 800 ? currentUtcOffset

GPS Seconds = | |
(GPS Weeks| |
× 7 × 86 400) | |
+ GPSSecondsInLastWeek| |
(GPS week number must | |
include 1024 × number | |
of rollovers) | PTP Seconds | PTP Seconds = GPS Seconds + 315 
964 819
PTP Seconds   | GPS Seconds | GPS Seconds = PTP Seconds ? 315 
964 819


All the values in this table are *integral seconds* and they are correct 
with respect to the definitions other timescale Epochs. (They neglect to 
say the values for NTP are to NTP's "prime epoch of era 0", a subtle but 
important point)


These are the values you must use for a practical implementation of PTP, 
and that is the convention adopted by the PTP community. These values 
*contradict* the second part of the epoch specification sentence 
("...which is 31 December 1969 23:59:51.18 UTC") and all the rest of 
the PTP epoch explanations throughout the document.


The "rubber-band era", while historically important, is just not 
relevant to practical timekeeping applications concerned with modern UTC 
and "civil time". The scattered nature of the UTC specifications lead 
from UTU-R Rec 460 to BIPM Annual Report on Time Activities Tables 1 and 
2 that list the historical values of the "rubber-band era". This leads 
to attempting to figure out what the historical values of UTC were 
during this period. Its interesting, but its a huge distraction until 
you realize it doesn't matter for most purposes. Like many of us, the 
IEEE PTP committee fell into this trap.


You can construct a Gregorian calendar timescale that is proleptic to 
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) (note the 10s 
TAI/UTC offset) and treats the measurement unit as integral seconds. 
This is, I believe, is the timescale most often used to calculate 
offsets between timescales, but is never explicitly acknowledged or 
named. Here I'll name it "Gregorian proleptic to UTC1972".


With that you can reconcile the offsets between the epochs of NTP, TAI, 
PTP, POSIX, UTC, and GPS in integral seconds.


-

Re: [LEAPSECS] My FOSDEM slides

[Zefram]

Brooks Harris wrote:
>The first part of that sentence is correct "The PTP epoch is 1
>January 1970 00:00:00 TAI". But the  second part, "which is 31
>December 1969 23:59:51.18 UTC", is not, or, is at least very
>misleading.

It's correct to the microsecond precision given.  My only real correctness
concern there is that it implies an exact equivalence which there isn't.
However, it is somewhat misleading by virtue of failing to explicate that
it is using the rubber-seconds UTC which is otherwise irrelevant to PTP.

>Table B.1-Relationships between timescales
>From  | To  |  Formula
>NTP Seconds   | PTP Seconds | PTP Seconds = NTP Seconds - 2
>208 988 800 + currentUtcOffset
>PTP Seconds   | NTP Seconds | NTP Seconds = PTP Seconds + 2
>208 988 800 - currentUtcOffset
...
>These are the values you must use for a practical implementation of
>PTP, and that is the convention adopted by the PTP community. These
>values *contradict* the second part of the epoch specification
>sentence

No, there is no contradiction there.  The table makes no claim about
the correspondence between TAI and UTC at any particular point in time.
It makes correct claims about the correspondences between various scalar
representations of time.  The only subtlety is the "currentUtcOffset" term
in the PTP<->NTP equations.  The currentUtcOffset (meaning (TAI-UTC)/s)
is not defined for all points in time, and during the rubber-seconds
era of UTC it takes on non-integral values.  This obviously can be a bit
confusing, because for the purposes of PTP as an operational protocol,
in which context only current timestamps are relevant, currentUtcOffset
is always well-defined and integral.  For the purposes of table B.1 it
is not.

>You can construct a Gregorian calendar timescale that is proleptic to
>1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) (note the 10s
>TAI/UTC offset) and treats the measurement unit as integral seconds.
>This is, I believe, is the timescale most often used to calculate

I don't think you've succeeded in defining a particular time scale here.
Your previous messages, and the table and comments later in your present
message, suggest that you're thinking of a time scale that amounts to TAI
- 10 s prior to 1972.  But the phrases "Gregorian calendar timescale"
and "treats the measurement unit as integral seconds" don't seem to
actually imply that.  I can't make much sense of either phrase.

>With that you can reconcile the offsets between the epochs of NTP,
>TAI, PTP, POSIX, UTC, and GPS in integral seconds.

Your focus on epochs is unhealthy.  Some of the epochs don't unambiguously
correspond to particular points in time, and in context that's not
a problem.  Notice that table B.1 that you quoted doesn't make any
reference to epochs per se: it doesn't describe relationships between
epochs, it describes relationships between *scalar values*.  What matters
is that these scalar values correspond to specific points in time over the
time period that matters for the application.  Scalar value zero isn't
inherently part of the relevant time period.  Taking NTP in particular,
no one was running NTP in 1900, so it is of no significance that NTP
zero doesn't correspond to a specific point in time.

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

Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

On Thu, 05 Mar 2015 14:55:58 +0100, Martin Burnicki wrote:
> Joseph Gwinn wrote:
>> On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote:
>>> Now in 4.2.8 the leap second code has been reworked and cleaned up,
>>> and a very quick look at the source code seems to indicate that this
>>> might work again. At least there's code which passes the announcement
>>> flag to the kernel, if kernel support is enabled.
>>> 
>>> I think I'll give it a try soon. I'd expect that a negative leap
>>> second might work if an appropriate announcement is received from a
>>> refclock or upstream NTP server, but it will be interesting to find
>>> out if this works with a NIST-style leap second file where the TAI
>>> offset decreases at a given date.
>> 
>> Hell - lots of code can't handle a positive leap second, so what hope
>> is there?
> 
> Should we abandon everything which can't easily be handled, or where 
> developers don't work thoroughly?

Nahh.  I'm just saying don't get your hopes up.


>> Right now, GPS System Time is the best solution.  In ten years, I bet
>> the answer will be TAI.
> 
> Agreed.
> 
> And we might already start to think about how to get this right in 
> mixed environments, e.g. using the NTF's General timestamp API, or 
> find a way to determine if the kernel time is UTC, or TAI.

Yes.  My experience is that it can be hard to get the time community to 
agree on an approach, especially if the community must convince 
non-time communities (like POSIX) to implement something perfect but 
very complex, especially if it doesn't solve a problem important to 
non-time folk.

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

Re: [LEAPSECS] My FOSDEM slides

[Warner Losh]

> On Mar 5, 2015, at 6:30 PM, Joseph Gwinn  wrote:
> 
> On Thu, 05 Mar 2015 14:55:58 +0100, Martin Burnicki wrote:
>> 
>> And we might already start to think about how to get this right in
>> mixed environments, e.g. using the NTF's General timestamp API, or
>> find a way to determine if the kernel time is UTC, or TAI.
> 
> Yes.  My experience is that it can be hard to get the time community to
> agree on an approach, especially if the community must convince
> non-time communities (like POSIX) to implement something perfect but
> very complex, especially if it doesn't solve a problem important to
> non-time folk.

The big problem with leap seconds are they are just a second. Nobody cares
enough about a second to give it more than a passing thought. This is why
so many things implement / spec leap seconds so poorly that bugs abound.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Brooks Harris]

Hi Zefram,

>> Your focus on epochs is unhealthy.

I don't claim to be any more healthy than the many other folks I've had 
these discussions with, most of whom are *obsessed* with, and *insistent 
upon*, specifying a known *immovable* epoch.


I think I could characterize your focus on using "scalar values" as a 
bit unhinged. :-)


The difference in our thinking seems to be my objective of placing the 
various timescale epochs at fixed offsets from 1972-01-01T00:00:00Z 
(UTC) = 1972-01-01T00:00:10Z (TAI) v.s. yours that allows the epochs to 
slip with each Leap Second in the manner NTP and POSIX do, which is, as 
you call it, "scalar".


Indeed, I think one of the reasons many people feel the need to use a 
"TAI-like" timescale is that generally those timescale's epochs are 
*fixed*, whereas with the NTP and POSIX implementations of "UTC-like" 
timescales, the epochs *slip*, essentially creating a new timescale with 
a different epoch offset to 1972-01-01T00:00:00Z (UTC) = 
1972-01-01T00:00:10Z (TAI) with each Leap Second.


I've actually tried to answer your earlier emails but each time it's 
turned to a multi-page essay and I never quite completed it. I'll try to 
finish that, but here I'll try to quickly answer your comments.



On 2015-03-05 01:29 PM, Zefram wrote:

Brooks Harris wrote:

The first part of that sentence is correct "The PTP epoch is 1
January 1970 00:00:00 TAI". But the  second part, "which is 31
December 1969 23:59:51.18 UTC", is not, or, is at least very
misleading.

It's correct to the microsecond precision given.  My only real correctness
concern there is that it implies an exact equivalence which there isn't.
However, it is somewhat misleading by virtue of failing to explicate that
it is using the rubber-seconds UTC which is otherwise irrelevant to PTP.


Yes, it is "otherwise irrelevant to PTP". Thats my point. All the 
discussion about the rubber-band period and use of "the POSIX algoritm" 
is beside the point for practical implementation, and hence, only a 
misleading distraction.



Table B.1-Relationships between timescales

>From  | To  |  Formula

NTP Seconds   | PTP Seconds | PTP Seconds = NTP Seconds - 2
208 988 800 + currentUtcOffset
PTP Seconds   | NTP Seconds | NTP Seconds = PTP Seconds + 2
208 988 800 - currentUtcOffset

...

These are the values you must use for a practical implementation of
PTP, and that is the convention adopted by the PTP community. These
values *contradict* the second part of the epoch specification
sentence

No, there is no contradiction there.  The table makes no claim about
the correspondence between TAI and UTC at any particular point in time.
It does if your objective is to link PTP time to the fixed epoch of 
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI), to the NTP prime 
epoch of era 0, and to the POSIX "the Epoch".


It can *also* be interpreted as scalar offsets, as you are interpreting 
them, yes, if that's how you need to use them.



It makes correct claims about the correspondences between various scalar
representations of time.  The only subtlety is the "currentUtcOffset" term
in the PTP<->NTP equations.  The currentUtcOffset (meaning (TAI-UTC)/s)
is not defined for all points in time, and during the rubber-seconds
era of UTC it takes on non-integral values.


Not in a practical timescale implementation. The "rubber-band era" is 
just entirely irrelevant. Its historically interesting, and may be 
required for some special application concerning that period, but for 
practical "UTC-like" timekeeping its just an historical curiosity.


This fact is somewhat more apparent looking at the IERS publication 
Leap_Second_History.dat, at 
https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. There we 
see *no values* before "1 1 1972" - the "rubber-band era" is gone. 
That's correct - the "rubber band era" no long exists.


[By the way, I think this document is the most well formed information 
about TAI/UTC. By using MJD there is no mistaking on what day each Leap 
Second occurs. I haven't found any official information at IERS about 
the policies of this document's publication but I think this may be the 
best source of official Leap Second information available. Note it 
includes the upcoming 2015-07-01 Leap Second.]


In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset = 
10s.


PTP time does not exist before this date-time. Official TAI exists from 
the origin of 1958-01-01T00:00:00 (TAI). "Integral second UTC" didn't 
exist before 1972-01-01T00:00:00Z (UTC). Thats where you need a 
timescale that is an integral second measure proleptic to 
1972-01-01T00:00:00Z (UTC), the timescale I keep trying to explain. With 
that, the PTP epoch is 1970-01-01T00:00:00 (TAI) = 1969-12-31T23:59:50Z 
(UTC).


By the way, I think its unfortunate they didn't specify the epoch as 
"1970-01-01T00:00:10 (TAI)" (note the 10s) because then it would 
coincide exactly with POSIX 

Re: [LEAPSECS] My FOSDEM slides

[Paul Hirose]

On 2015-03-06 11:04, Brooks Harris wrote:

The "rubber-band era" is
just entirely irrelevant. Its historically interesting, and may be
required for some special application concerning that period, but for
practical "UTC-like" timekeeping its just an historical curiosity.

This fact is somewhat more apparent looking at the IERS publication
Leap_Second_History.dat, at
https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. There we
see *no values* before "1 1 1972" - the "rubber-band era" is gone.
That's correct - the "rubber band era" no long exists.


Since the name of the document is "leap second history", the rate 
offsets and fractional second step adjustments before 1972 aren't 
applicable. They can be found elsewhere at the IERS site:


http://hpiers.obspm.fr/eop-pc/index.php?index=UTC&lang=en

I distribute a Windows astronomical toolbox DLL which includes time 
scale conversions. Since astronomy often requires analysis of old data, 
the DLL can deal with pre-1972 UTC. I won't get into the dispute over 
whether or not that's bona fide UTC! However, the IERS and USNO 
recognize it as such, so I assume the user will expect time conversions 
to work in that era. (I have never needed that capability myself.)


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

Re: [LEAPSECS] My FOSDEM slides

[Harlan Stenn]

Paul,

Paul Hirose writes:
> I distribute a Windows astronomical toolbox DLL which includes time
> scale conversions. Since astronomy often requires analysis of old
> data, the DLL can deal with pre-1972 UTC. I won't get into the dispute
> over whether or not that's bona fide UTC! However, the IERS and USNO
> recognize it as such, so I assume the user will expect time
> conversions to work in that era. (I have never needed that capability
> myself.)

When we get a bit more down the road with NTF's General Timestamp API,
I'd appreciate your taking a look at what we're doing and helping out in
any way you are up for.  One of the issues that will need more attention
is pre-1972 stuff.
-- 
Harlan Stenn 
http://networktimefoundation.org  - be a member!
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Steve Allen]

On Sat 2015-03-07T02:02:12 +, Harlan Stenn hath writ:
> When we get a bit more down the road with NTF's General Timestamp API,
> I'd appreciate your taking a look at what we're doing and helping out in
> any way you are up for.  One of the issues that will need more attention
> is pre-1972 stuff.

Before 1972 is pretty simple.

Without some means of comparing an event with a particular radio
broadcast time signal or a particular astronomical event, everything
before 1972 is just plain UT or GMT back to 1676, and UT before that.

Any subsecond deviations from what those represent (including worries
about UT0, UT1, UT2) are only available by painstaking inspection (and
re-interpretation into modern terminology) of the tabulations in BIH
Bulletin Horaire.

Of course I'm ignoring any timezones.  That's a whole 'nother layer
of painstaking historical investigation for any given locale.

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

Re: [LEAPSECS] My FOSDEM slides

[Warner Losh]

> On Mar 6, 2015, at 7:57 PM, Steve Allen  wrote:
> 
> On Sat 2015-03-07T02:02:12 +, Harlan Stenn hath writ:
>> When we get a bit more down the road with NTF's General Timestamp API,
>> I'd appreciate your taking a look at what we're doing and helping out in
>> any way you are up for.  One of the issues that will need more attention
>> is pre-1972 stuff.
> 
> Before 1972 is pretty simple.
> 
> Without some means of comparing an event with a particular radio
> broadcast time signal or a particular astronomical event, everything
> before 1972 is just plain UT or GMT back to 1676, and UT before that.

Before 1972 there were radio signals. LORAN C was operated from the early
60’s onward, and many receivers existed to recover timing data from them.
WWV dates back to the 30’s, with the current Ft Collins transmitter dating from
the 1960’s. It started broadcasting UTC time in December 1968.

> Any subsecond deviations from what those represent (including worries
> about UT0, UT1, UT2) are only available by painstaking inspection (and
> re-interpretation into modern terminology) of the tabulations in BIH
> Bulletin Horaire.

I’m not entirely sure that’s correct. You can recover time to at least tens
of microseconds from WWV or LORAN-C, which is quite a bit better than
you need to notice the difference between UTC and UT1.  With a good cesium
standard, synchronized at NBS, running off battery power for the car ride to the
lab, WWV could keep you on frequency as well, and you could get sub-microsecond
level of performance. I got to hear many tales of the old days when they did
this sort of two-way time exchange before satellites. This allowed the frequency
broadcast by WWV to be within a few parts in e11 (day it is 100x better).

If you read the histories of WWV, they talk about the close proximity to Boulder
enabling this. The reason was that the battery backup would be enough to last
the 45 minutes or so it takes to go from Boulder to Fort Collins…  WWV followed
the frequency offset + phase steps in the rubber leap second era, which was
an attempt to keep UT1 and UTC not only synchronized, but also syntonized. I 
find
it curious that the practice of adjusting the frequency of the clocks persisted 
for
5 years after the SI second was defined.

So it isn’t outside the realm of possibilities that you’d have people making 
measurements
from the late 60’s till 1972 using UTC (and yes, it did exist in a practical 
form
before 1972, just not in the current form and the common usage often leaves some
ambiguity between the actual, realized form as broadcast by WWV, or the 
proleptic
form w/o leap seconds). Actual measurements from this time, though, were based
on something approaching the UTC as broadcast by WWV. Not sure how many data
sets from that time survive until today, and how many need to be converted from 
that
to UT1 or UT2, but evidentially there’s some...

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Steve Allen]

On Fri 2015-03-06T21:37:42 -0700, Warner Losh hath writ:
> So it isn't outside the realm of possibilities that you'd have people making 
> measurements
> from the late 60's till 1972 using UTC (and yes, it did exist in a practical 
> form
> before 1972, just not in the current form and the common usage often leaves 
> some
> ambiguity between the actual, realized form as broadcast by WWV, or the 
> proleptic
> form w/o leap seconds). Actual measurements from this time, though, were based
> on something approaching the UTC as broadcast by WWV. Not sure how many data
> sets from that time survive until today, and how many need to be converted 
> from that
> to UT1 or UT2, but evidentially there's some...

Yes and yes, but these are specialty applications for specialty datasets
which can only be reduced to a precise modern time scale if the original
observations and equipment were meticulously calibrated.
And then they must be reduced by going back to look at, e.g.
https://plus.google.com/photos/112320138481375234766/albums/6078225731350227361
Please don't try to make this part of a General Timestamp API.

Before 1972, for a general API, there is just UT.

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

Re: [LEAPSECS] My FOSDEM slides

[Warner Losh]

> On Mar 6, 2015, at 9:57 PM, Steve Allen  wrote:
> 
> On Fri 2015-03-06T21:37:42 -0700, Warner Losh hath writ:
>> So it isn't outside the realm of possibilities that you'd have people making 
>> measurements
>> from the late 60's till 1972 using UTC (and yes, it did exist in a practical 
>> form
>> before 1972, just not in the current form and the common usage often leaves 
>> some
>> ambiguity between the actual, realized form as broadcast by WWV, or the 
>> proleptic
>> form w/o leap seconds). Actual measurements from this time, though, were 
>> based
>> on something approaching the UTC as broadcast by WWV. Not sure how many data
>> sets from that time survive until today, and how many need to be converted 
>> from that
>> to UT1 or UT2, but evidentially there's some...
> 
> Yes and yes, but these are specialty applications for specialty datasets
> which can only be reduced to a precise modern time scale if the original
> observations and equipment were meticulously calibrated.
> And then they must be reduced by going back to look at, e.g.
> https://plus.google.com/photos/112320138481375234766/albums/6078225731350227361

There are a few observatories around here (being in proximity to Boulder) that 
have
data from this time. They know it is only good to a millisecond or so, but 
that’s UTC
not UT. They don’t have to recreate the calibrations or whatever today because 
they
know the data isn’t much better than that. Still, there is some of it that it 
matters to. Though
maybe by now the old professors are gone and the data is too… My data on this is
about 15 years old, and even then it was second hand...

> Please don't try to make this part of a General Timestamp API.
> 
> Before 1972, for a general API, there is just UT.

Generally yes. I agree. For most data, UT is close enough, since that also 
required a lot
of specialty data that you have to look up in books if you want to covert it to 
elapsed time.
I’d make it be opt-in, but I wouldn’t make it impossible.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[G Ashton]

A general API that deals with old dates should allow for the possibility the 
original observation was stated in apparent solar time. Or, an explicit warning 
should be provided that the authors of the API believed that for the intended 
applications, given the limited accuracy of local time standards and watches, 
the difference between mean and solar time is not considered important.

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

Re: [LEAPSECS] My FOSDEM slides

[Brooks Harris]

On 2015-03-06 08:30 PM, Paul Hirose wrote:

On 2015-03-06 11:04, Brooks Harris wrote:

The "rubber-band era" is
just entirely irrelevant. Its historically interesting, and may be
required for some special application concerning that period, but for
practical "UTC-like" timekeeping its just an historical curiosity.

This fact is somewhat more apparent looking at the IERS publication
Leap_Second_History.dat, at
https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. There we
see *no values* before "1 1 1972" - the "rubber-band era" is gone.
That's correct - the "rubber band era" no long exists.


Since the name of the document is "leap second history", the rate 
offsets and fractional second step adjustments before 1972 aren't 
applicable. They can be found elsewhere at the IERS site:


http://hpiers.obspm.fr/eop-pc/index.php?index=UTC&lang=en

I distribute a Windows astronomical toolbox DLL which includes time 
scale conversions. Since astronomy often requires analysis of old 
data, the DLL can deal with pre-1972 UTC. I won't get into the dispute 
over whether or not that's bona fide UTC! However, the IERS and USNO 
recognize it as such, so I assume the user will expect time 
conversions to work in that era. (I have never needed that capability 
myself.)


Of course its important the purpose of any timescale be stated 
carefully, and I haven't done that in what I wrote in the email 
containing this paragraph. In the company of the astronomers here on the 
list I might have been a bit insensitive to lump their objectives into 
"some special application".


The challenge I'm trying to solve is to provide a deterministic 
timekeeping and labeling scheme for date and time *after* 
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI). This is 
essentially the purpose of "civil time" timekeeping as is typically 
intended. The timescale I've attempted to describe is intended to be 
single reference timescale with a *fixed epoch* at the NTP prime epoch 
era 0. (Conceptually this could be extended into the indefinite past.) 
The timescale before 1972 is an abstract proleptic Gregorian calendar 
scale for purposes of calculation convenience. On this scale, like NTP, 
PTP, and POSIX, any date-time before 1972-01-01T00:00:00Z (UTC) is 
considered either inaccurate or invalid.


It is in that sense, and with regard to that purpose, I said "The 
"rubber-band era" is just entirely irrelevant.".


-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] My FOSDEM slides

[Zefram]

Brooks Harris wrote:
>that allows the epochs to slip with each Leap Second in the manner
>NTP and POSIX do, which is, as you call it, "scalar".

I think you understand by the word "scalar" something very different from
what I mean.  By "scalar value" I mean a value consisting of a single
number, such as a Unix time_t value or an NTP time value.  Non-scalar time
values include anything that separates date from time-of-day.

> whereas with the NTP and POSIX implementations of "UTC-like"
>timescales, the epochs *slip*, essentially creating a new timescale
>with a different epoch

This is a legitimate view of the NTP and POSIX systems, which has a
certain amount of theoretical value.

>On 2015-03-05 01:29 PM, Zefram wrote:
>>Brooks Harris wrote:
>>No, there is no contradiction there.  The table makes no claim about
>>the correspondence between TAI and UTC at any particular point in time.
>It does if your objective is to link PTP time to the fixed epoch of

No, your objective doesn't fundamentally change what the table says.

>> The currentUtcOffset (meaning (TAI-UTC)/s)
>>is not defined for all points in time, and during the rubber-seconds
>>era of UTC it takes on non-integral values.
>
>Not in a practical timescale implementation.

If your concept of a "practical timescale implementation" excludes
rubber-seconds UTC, then sure, rubber-seconds UTC doesn't arise in your
"practical timescale implementation".  That still doesn't change what
happens when one *does* consider rubber-seconds UTC.  You wishing that
it didn't exist doesn't make it go away.

>In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
>= 10s.

Where do you get this idea from?  You've cited no source for it.
You appear to have plucked it from thin air.

>   Official TAI exists
>from the origin of 1958-01-01T00:00:00 (TAI).

That's a misunderstanding of the nature of the TAI `epoch'.  It is
not the case that TAI existed from the epoch onwards and did not exist
before.  TAI has existed to varying degrees from mid-1955 onwards, and
historically nothing special happened to it on 1958-01-01.  That date
only became special in retrospect, in late 1958.  That's when the time
scale was established in a form that we'd recognise (though not with its
present name), counting units of atomic seconds and labelling them by MJD
and equivalents.  The specialness of 1958-01-01 is merely that those MJD
labels were aligned such that TAI coincided with UT2(USNO) on that date.
TAI timestamps in early 1958 are necessarily retrospective (more so
than TAI timestamps from 1959 onwards are), and such retrospective TAI
timestamps can be applied all the way back to the start of continuous
atomic clock operations in 1955.

Are you just making an arbitrary decision that TAI from 1958 onwards is
"official" (even where retrospective) and that TAI prior to 1958 is "not
official" (even where well defined)?  If you are choosing an arbitrary
cutoff for the purposes of your project, you should be explicit about
that scope and about its arbitrariness.

>Thats where you need
>a timescale that is an integral second measure proleptic to
>1972-01-01T00:00:00Z (UTC), the timescale I keep trying to explain.
>With that, the PTP epoch is 1970-01-01T00:00:00 (TAI) =
>1969-12-31T23:59:50Z (UTC).

In addition to the very dubious nature of the "need" for a specific
proleptic extension of integral-seconds UTC, you here make the jump from
*a* proleptic integral UTC to *the* time scale you are constructing.
There are many possible proleptic extensions of integral-seconds UTC,
and you have consistently failed to explain why one must specifically
use the one that has no pre-1972 leap events.

>By the way, I think its unfortunate they didn't specify the epoch as
>"1970-01-01T00:00:10 (TAI)" (note the 10s) because then it would
>coincide exactly with POSIX "the Epoch".

It would coincide exactly only in the context of your fictitious
leap-seconds-but-no-actual-leaps pre-1972 UTC.  Given the fundamental
differences between PTP and POSIX time values, having the epochs coincide
to any appreciable degree invites confusion.  Having them as close as
they are (about 8 s using real UTC, 10 s using your fictitious UTC)
is bad enough; getting them as close as 2 s (and especially the exact
coincidence with your fictitious UTC) would be asking for trouble.

>I think you mean if you are attempting to map into the "rubber-band
>era" you could interpret the currentUtcOffset value to be
>non-integral, but that's not explicit in the table.

Indeed, that's not explicit.  It's implied by the basic definition of
currentUtcOffset (as the difference between TAI and UTC) combined with
the fundamental behaviour of rubber-seconds UTC.

>In fact I see
>currentUtcOffset as being defined as integral seconds.

The protocol field is defin

Re: [LEAPSECS] My FOSDEM slides

[Brooks Harris]

On 2015-03-08 12:45 PM, Zefram wrote:

Brooks Harris wrote:

that allows the epochs to slip with each Leap Second in the manner
NTP and POSIX do, which is, as you call it, "scalar".

I think you understand by the word "scalar" something very different from
what I mean.  By "scalar value" I mean a value consisting of a single
number, such as a Unix time_t value or an NTP time value.  Non-scalar time
values include anything that separates date from time-of-day.
OK, yes, we're thinking of it differently, I guess, or at least I may 
have misrepreented your meaning in my pose. But as you explain it here 
thats what I'm thinking too. Any given value of time_t or an NTP time 
value has "lost all knowledge of Leap Seconds" and so has slipped its 
epoch with each Leap Second, in effect creating multiple timescales.


I must admit I didn't understand the significance of this subtly for a 
while -


David Wells writes:

The NTP Timescale and Leap Seconds
http://www.eecis.udel.edu/~mills/leap.html

3. How NTP and POSIX Reckon with Leap Seconds
"... the conversion is in effect reset to UTC as each broadcast timecode 
is received. Thus, when a leap second is inserted in UTC and 
subsequently in NTP or POSIX, knowledge of all previous leap seconds is 
lost."


"Another way to describe this is to say there are as many NTP or POSIX 
timescales as historic leap seconds. In effect, a new timescale is 
reestablished after each new leap second. Thus, all previous leap 
seconds, not to mention the apparent origin of the timescale itself, 
lurch backward one second as each new timescale is established. ..."


I'd read that many times before it sunk in. Oh! The epochs are actually 
shifting! And so there are multiple timescales! Wow! Now I get it!


This is what I understood your use of "scalar" to be referring to.




 whereas with the NTP and POSIX implementations of "UTC-like"
timescales, the epochs *slip*, essentially creating a new timescale
with a different epoch

This is a legitimate view of the NTP and POSIX systems, which has a
certain amount of theoretical value.


I agree, "a certain amount of theoretical value", and, indeed, a fairly 
large amount of practical timekeeping capability. If implemented 
correctly, NTP and POSIX accurately represent date and time-of-day 
*except* on the Leap Seconds themselves. But, of course time_t's epoch 
is slipping about with respect to post 1972 UTC.





On 2015-03-05 01:29 PM, Zefram wrote:

Brooks Harris wrote:
No, there is no contradiction there.  The table makes no claim about
the correspondence between TAI and UTC at any particular point in time.

It does if your objective is to link PTP time to the fixed epoch of

No, your objective doesn't fundamentally change what the table says.


I didn't say it changed the table in some way. I said I'm using those 
values to calculate the offset between NTP prime epoch of era 0 and 1972 
UTC. I'm then using that as a *fixed* epoch of my timescale.





 The currentUtcOffset (meaning (TAI-UTC)/s)
is not defined for all points in time, and during the rubber-seconds
era of UTC it takes on non-integral values.

Not in a practical timescale implementation.

If your concept of a "practical timescale implementation" excludes
rubber-seconds UTC, then sure, rubber-seconds UTC doesn't arise in your
"practical timescale implementation".
Right. Same as NTP and POSIX - they don't represent accurate date-time 
before 1972.



That still doesn't change what
happens when one *does* consider rubber-seconds UTC.
Yes, you need to switch to an alternate timescale. There *is* an implied 
timescale with non-integral measures from 1961 to 1972 that doesn't have 
a name. That's what you need in that period if that's your purpose. In 
*my* timescale, and NTP and POSIX, this period lies in the "inaccurate 
proleptic integral seconds period before 1972".



You wishing that
it didn't exist doesn't make it go away.
I didn't make it go away. I ignore it for purposes of timekeeping after 
1972, replacing it with a "proleptic extrapolation of seconds prior to 
1972 for convenience of calculation" the same way NTP and POSIX do. 
time_t doesn't know anything about the rubber-band era in lies within.





In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
= 10s.

Where do you get this idea from?  You've cited no source for it.
You appear to have plucked it from thin air.


No, not from thin air, its very clear -

IEEE Std 1588-2008, 7.2.3 UTC Offset - "... 
timePropertiesDS.currentUtcOffset = TAI ─ UTC."... "NOTE—As of 0 hours 1 
January 2006 UTC, UTC was behind TAI by 33 seconds."





   Official TAI exists

>from the origin of 1958-01-01T00:00:00 (TAI).

That's a misunderstanding of the nature of the TAI `epoch'.

Not a misunderstanding, I don't think. A "recasting" of its use, perhaps.


  It is
not the case that TAI existed from the epoch onwards and did not exist
befo

Re: [LEAPSECS] My FOSDEM slides

[Zefram]

Brooks Harris wrote:
>On 2015-03-08 12:45 PM, Zefram wrote:
>>Brooks Harris wrote:
>>>In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
>>>= 10s.
>>Where do you get this idea from?  You've cited no source for it.
>>You appear to have plucked it from thin air.
>
>No, not from thin air, its very clear -
>
>IEEE Std 1588-2008, 7.2.3 UTC Offset - "...
>timePropertiesDS.currentUtcOffset = TAI - UTC."... "NOTE-As of 0
>hours 1 January 2006 UTC, UTC was behind TAI by 33 seconds."

That clause does not specify a currentUtcOffset value for 1969-12-31.
It gives a general definition, augmented with information that implies a
currentUtcOffset value for 2006-01-01 (of 33 s).  I'm really not seeing
how you get from that to a value of 10 s for 1969-12-31.  Taking UTC to
include the rubber seconds era gives a varying non-integral value near 8 s
for 1969-12-31.  Alternatively, your view that the pre-1972 history isn't
`really' UTC implies that currentUtcOffset is undefined for 1969-12-31.
Only your fictitious UTC gives currentUtcOffset = 10 s for 1969-12-31.
If you're trying to use this statement as justification for your time
scale, then this is circular reasoning; you're begging the question.

>Right. But like the "rubber-band era" they are beside the point of
>timekeeping after 1972,

They would be beside the point if you hadn't raised the issue yourself.
You're expending a lot of effort on pre-1972 times that are all irrelevant
for this purpose.  The actual time of the NTP epoch is beside the point.

>PTP's
>epoch, 1970-01-01T00:00:00 (TAI) is explicit only if you extrapolate
>proleptic TAI seconds prior to 1972-01-01 00:00:10 (TAI).

1972 is another date that doesn't mark the beginning of TAI.  The name
"TAI" arose in 1971, but the BIH had actually been operating the service
in a pretty modern form for years.  TAI times in 1970 are not proleptic.

>RFC 5905, Figure 4: Interesting Historic NTP Dates, shows this.
>
>| 1 Jan 1900 | 15020 | 0 | 0 | First day NTP |
>| 1 Jan 1972 | 41,317 | 0 | 2,272,060,800 | First day UTC |
>
>Thats 2,272,060,800 absolute seconds offset from the NTP prime epoch
>to 1972. 2272060800 / 86400 = 26297 exactly. There's no 10 second
>remainder. An initial TAI-UTC 10s offset is in effect at 1972 (by
>definition) so the seconds offset to the NTP prime epoch includes
>this, that is, the initial TAI-UTC 10s is in effect at the beginning
>of the NTP timescale.

You have misinterpreted that table.  The heading of the column you're
referring to is "NTP Timestamp".  There's no claim there that the
2272060800 is an actual number of seconds between two events.  Rather,
2272060800 is the NTP scalar value describing 1972-01-01 00:00:00 UTC.
As you have repeatedly pointed out, NTP doesn't count leap seconds.
The difference between two NTP timestamps does not reflect the number
of leap seconds that occurred in that interval.  The 2272060800 value
implies nothing at all about leap seconds between 1900 and 1972.

Also note the next entry in the table:

| 31 Dec 1999 | 51,543 | 0   | 3,155,587,200 | Last day 20th|
| || |   | Century  |

This 3155587200 value is *also* an exact multiple of 86400.  If it were
to be interpreted as a pure count of seconds, it would imply that there
were a total of zero leap seconds between 1900-01-01 and 1999-12-31, and
similarly a total of zero leap seconds between 1972-01-01 and 1999-12-31.
That would contradict the uncontroversial post-1972 leap second schedule.

>>But the NTP epoch is not so well defined.  The NTP epoch is
>>not a specific point in time,
>Sure it is. The *the prime epoch, or base date of era 0, is 0 h 1
>January 1900 UTC"

1900-01-01 00:00:00 UTC is a fictitious timestamp, because UTC doesn't
extend back that far.  The NTP epoch is, in that respect, fictitious.

>  and is 2272060800 seconds before the "First day
>UTC".

And that's your misunderstanding of the NTP table again.

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

Re: [LEAPSECS] My FOSDEM slides

[Brooks Harris]

On 2015-03-08 03:43 PM, Zefram wrote:

Brooks Harris wrote:

On 2015-03-08 12:45 PM, Zefram wrote:

Brooks Harris wrote:

In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
= 10s.

Where do you get this idea from?  You've cited no source for it.
You appear to have plucked it from thin air.

No, not from thin air, its very clear -

IEEE Std 1588-2008, 7.2.3 UTC Offset - "...
timePropertiesDS.currentUtcOffset = TAI - UTC."... "NOTE-As of 0
hours 1 January 2006 UTC, UTC was behind TAI by 33 seconds."

That clause does not specify a currentUtcOffset value for 1969-12-31.
It gives a general definition, augmented with information that implies a
currentUtcOffset value for 2006-01-01 (of 33 s).  I'm really not seeing
how you get from that to a value of 10 s for 1969-12-31.  Taking UTC to
include the rubber seconds era gives a varying non-integral value near 8 s
for 1969-12-31.
That's what the explanations say, but not what real world 
implementations do.



Alternatively, your view that the pre-1972 history isn't
`really' UTC implies that currentUtcOffset is undefined for 1969-12-31.
As a practical matter its most convenient use currentUtcOffset = 10s at 
1970-01-01T00:00:00 (TAI) = "Zero PTP Time".



Only your fictitious UTC gives currentUtcOffset = 10 s for 1969-12-31.


It not just my "fictitious UTC". That's how implementations are done. 
When you do it that way its easy, and everything is OK after 1972.



If you're trying to use this statement as justification for your time
scale, then this is circular reasoning; you're begging the question.


Right. But like the "rubber-band era" they are beside the point of
timekeeping after 1972,

They would be beside the point if you hadn't raised the issue yourself.
You're expending a lot of effort on pre-1972 times that are all irrelevant
for this purpose.  The actual time of the NTP epoch is beside the point.


PTP's
epoch, 1970-01-01T00:00:00 (TAI) is explicit only if you extrapolate
proleptic TAI seconds prior to 1972-01-01 00:00:10 (TAI).

1972 is another date that doesn't mark the beginning of TAI.  The name
"TAI" arose in 1971, but the BIH had actually been operating the service
in a pretty modern form for years.  TAI times in 1970 are not proleptic.


Yes, I know.




RFC 5905, Figure 4: Interesting Historic NTP Dates, shows this.

| 1 Jan 1900 | 15020 | 0 | 0 | First day NTP |
| 1 Jan 1972 | 41,317 | 0 | 2,272,060,800 | First day UTC |

Thats 2,272,060,800 absolute seconds offset from the NTP prime epoch
to 1972. 2272060800 / 86400 = 26297 exactly. There's no 10 second
remainder. An initial TAI-UTC 10s offset is in effect at 1972 (by
definition) so the seconds offset to the NTP prime epoch includes
this, that is, the initial TAI-UTC 10s is in effect at the beginning
of the NTP timescale.

You have misinterpreted that table.  The heading of the column you're
referring to is "NTP Timestamp".  There's no claim there that the
2272060800 is an actual number of seconds between two events.  Rather,
2272060800 is the NTP scalar value describing 1972-01-01 00:00:00 UTC.
As you have repeatedly pointed out, NTP doesn't count leap seconds.
The difference between two NTP timestamps does not reflect the number
of leap seconds that occurred in that interval.  The 2272060800 value
implies nothing at all about leap seconds between 1900 and 1972.

Also note the next entry in the table:

 | 31 Dec 1999 | 51,543 | 0   | 3,155,587,200 | Last day 20th|
 | || |   | Century  |

This 3155587200 value is *also* an exact multiple of 86400.  If it were
to be interpreted as a pure count of seconds, it would imply that there
were a total of zero leap seconds between 1900-01-01 and 1999-12-31, and
similarly a total of zero leap seconds between 1972-01-01 and 1999-12-31.
That would contradict the uncontroversial post-1972 leap second schedule.


No no no! NTP, and this table, do not address Leap Seconds at all. 
That's the point of it! There are 3155587200 seconds from the epoch of 
*that* particular NTP timescale that includes "31 Dec 1999" - its epoch 
has slipped with respect to 1972UTC because the Leap Seconds are 
unaccounted for. All NTP days are 86400 long, as you point out. When the 
count freezes over a Leap Second the second offset to 1972UTC decreases 
by one.  That's the realization that hit me like a wave when I saw it.


There *are* zero leap seconds between [ 1900-01-01 *plus 22 forgotten 
Leap Seconds* ] and 1999-12-31.


That's what David Wells is trying to point out - read that again 
carefully -


David Wells writes:

The NTP Timescale and Leap Seconds
http://www.eecis.udel.edu/~mills/leap.html

3. How NTP and POSIX Reckon with Leap Seconds
"... the conversion is in effect reset to UTC as each broadcast timecode 
is received. Thus, when a leap second is inserted in UTC and 
subsequently in NTP or POSIX, knowledge of all previous le

Re: [LEAPSECS] My FOSDEM slides

[Zefram]

Brooks Harris wrote:
>As a practical matter its most convenient use currentUtcOffset = 10s
>at 1970-01-01T00:00:00 (TAI) = "Zero PTP Time".

So your entire justification for claiming this amounts to it being a
convenient fiction.  Your reference to clauses of IEEE 1588 didn't add
anything to this argument.

>No no no! NTP, and this table, do not address Leap Seconds at all.

Right.  That's why you can't infer any particular leap second history
from that table.  Not for 1972 to 1999, and not for 1900 to 1972.

>There *are* zero leap seconds between [ 1900-01-01 *plus 22 forgotten
>Leap Seconds* ] and 1999-12-31.

If the leap seconds have been forgotten, how do you know how many
there were?  Another part of the NTP spec is explicit about the notional
pre-1972 UTC having an unknown leap history.

Applying the view that NTP scalars are actual counts of seconds from
epochs that change at every leap second, the unknown notional leap seconds
between 1900 and 1972 impose an unknown slippage of epoch between the 1900
and 1972 entries in the table.  The 1972 instant is 2272060800 seconds
from one of these epochs; there's no reason to suppose that that's the
same epoch as the one from which the 1900 instant is 0 s removed.

>On 2015-03-08 03:43 PM, Zefram wrote:
>>1900-01-01 00:00:00 UTC is a fictitious timestamp, because UTC doesn't
>>extend back that far.  The NTP epoch is, in that respect, fictitious.
>
>Yes, of course. That's what NTP says, and that's what I'm saying. Its
>proleptic, I think is the correct word.
...
>I guess you could call it "fictitious" if you want. But it seems like
>any numbering system is "fictitious" in that sense.

There's a big difference between "proleptic" and "fictitious".
Applying the Gregorian calendar to the year 1415 is proleptic, because
the Gregorian calendar hadn't been invented at the time.  But it's
not fictitious, because the Gregorian calendar serves perfectly well
to label specific days of that year.  The Battle of Agincourt happened
on a day that the proleptic Gregorian calendar labels as "1415-11-03".
We can firmly link the modern label "1415-11-03" to the day that at the
time was referred to as "25 October 1415" (using the Julian calendar)
or as "Saint Crispin's Day".

The reference to "1900-01-01 00:00:00 UTC" is fictitious because the
mechanisms of UTC do not extend back that far.  UTC cannot be used
to label specific instants in 1900.  The label "1900-01-01 00:00:00
UTC" does not refer to a specific second that we could identify using
contemporaneous terminology, or for which we could identify historical
events.

>>And that's your misunderstanding of the NTP table again.
>
>I don't think so.

You haven't dissuaded me from this position.  I don't quite grasp the
logic you're using, but it's clear that you're being inconsistent in how
you relate leap seconds to the table entries.  Your entire rationale for
this leapless pre-1972 pseudo-UTC is based on your misinterpretation of
this clarifying table in the NTP spec.

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