Re: [LEAPSECS] private smear goes public

[Warner Losh]

I strongly urge that they get a lawyer to do write / bless something
like CC0 rather than going to the internet to get a suggestion. This
is scientific data, and the CC0 was done for that. However, I can't
say this enough: they need a lawyer that's an expert on whatever kind
of quazi-governmental agency IERS is, since the rules for them are
'special' and ever changing. In the US, it used to be the case that
all works commissioned by the government were in the public domain.
That's changed in subtle and technical ways and you need to be an
expert to know how to do things. And you need to know what you can or
can't put into the public domain based on whatever contract it may
have been produced for. All these details about the IERS are, at best,
murky and they really really really should get a lawyer that knows the
ins and outs of the laws governing thing that setup of the IERS.

Oh, and did I mention they should get competent legal advise.

Warner

On Fri, Dec 2, 2016 at 4:44 PM, Michael Wouters
 wrote:
> According to this email,
>
> http://mm.icann.org/pipermail/tz/2016-February/023209.html
>
> the IERS will be adding a copyright notice allowing free use of the
> leap second list.
>
> Guess we just have to wait for the next one.
>
> Cheers
> Michael
>
> On Sat, Dec 3, 2016 at 9:38 AM, Poul-Henning Kamp  wrote:
>> 
>> In message 
>> 

Re: [LEAPSECS] private smear goes public

[Christopher Hoover]

I'm not speaking for Google (and have no specific knowledge) ...

I think the forcing factor was cloud computing not ad networks.


On Fri, Dec 2, 2016 at 1:00 AM, Poul-Henning Kamp 
wrote:

> 
> In message <58407de7.1030...@edlmax.com>, Brooks Harris writes:
>
> > As I read it I think Google's intention is to publish their method and
> > algorithm in the hopes others may follow it. It would be better if
> > everybody did it the same way, but it will remain to be seen if others
> > will choose to follow the example.
>
> No.
>
> Googles *problem* is that they decided to smear internally, but provide
> tons if APIs for the rest of the world.
>
> The most valuable of these APIs, in terms of money, from Googles
> point of view, is the on-line, real-time bidding for ad-space in
> front of your eyes [1]
>
> Google running on private time up to half a second different from the
> rest of the world doesn't work in that scenario, so either Google
> had to drop their smear ... or make the consumers of their APIs
> use their smear too.
>
> Guess what happened...
>
> Poul-Henning
>
> [1] Ever wondered what "google tag manager" is about ?
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> 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] private smear goes public

[Michael Wouters]

According to this email,

http://mm.icann.org/pipermail/tz/2016-February/023209.html

the IERS will be adding a copyright notice allowing free use of the
leap second list.

Guess we just have to wait for the next one.

Cheers
Michael

On Sat, Dec 3, 2016 at 9:38 AM, Poul-Henning Kamp  wrote:
> 
> In message 
> 

Re: [LEAPSECS] private smear goes public

[Warner Losh]

On Fri, Dec 2, 2016 at 3:17 PM, Poul-Henning Kamp  wrote:
> 
> In message , 
> =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= writes:
>
>>> It does not have any copyright claims on it I can identify. Not
>>> do the other related files, like
>>> https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat.
>>>
>>> Seems to me any copyright claim would defeat the IERS purposes.
>>> Seems to me if there were such it would have to be stated in Bulletin
>>> C itself.
>>
>>You don't need to "claim copyright" to have it. You need to license to allow 
>>others to use your work.
>
> While that is true, there are a lot of fine print.
>
> First, licensing can and often is implied.
>
> This is generally the case if you distribute your own work widely
> with no indication of intention to enforce your copyright later on.
> If you want to assert and defend your "mercantile rights", you need
> to state that up front, with a big fat copyright notice, from day 1.
>
> Second, there are exceptions for fair use, which almost certainly
> applies here, since leap seconds have legal force in most countries.
>
> The only relevant situation where copyright matters for Bulletin-C,
> is if somebody replaces IERS name with something else.
>
> That would be an attack on IERS's (directors) "ideal right" to
> be associated with the work as its creator.
>
> The ideal rights does not require marking, because nobody who
> violates them can possible be in doubt that they didn't create
> the work themselves [1].
>
> So as long as you reproduce Bulletin C verbatim, there can not
> and will not be any copyright issues[2].
>
> Poul-Henning
>
> [1] This is where the trouble starts with music:  There are
> only so many guitar-riffs, and parallel creation is bound
> to happen.  Ask Led Zeppelin for details.
>
> [2] I wonder if anybody bothered to actually ask IERS director, or
> if this is just the usual navel-gazing and circle-jerking from
> militant FOSS license-separatists ?

It's also all boilerplate. There's no creative content, so it's quite
likely it wouldn't even qualify for copyright protection. You can't
copyright facts, and that's all that differs from report to report.

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

Re: [LEAPSECS] private smear goes public

[Poul-Henning Kamp]

In message , 
=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= writes:

>> It does not have any copyright claims on it I can identify. Not
>> do the other related files, like
>> https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat.
>> 
>> Seems to me any copyright claim would defeat the IERS purposes.
>> Seems to me if there were such it would have to be stated in Bulletin
>> C itself.
>
>You don't need to "claim copyright" to have it. You need to license to allow 
>others to use your work.

While that is true, there are a lot of fine print.

First, licensing can and often is implied.

This is generally the case if you distribute your own work widely
with no indication of intention to enforce your copyright later on.
If you want to assert and defend your "mercantile rights", you need
to state that up front, with a big fat copyright notice, from day 1.

Second, there are exceptions for fair use, which almost certainly
applies here, since leap seconds have legal force in most countries.

The only relevant situation where copyright matters for Bulletin-C,
is if somebody replaces IERS name with something else.

That would be an attack on IERS's (directors) "ideal right" to
be associated with the work as its creator.

The ideal rights does not require marking, because nobody who
violates them can possible be in doubt that they didn't create
the work themselves [1].

So as long as you reproduce Bulletin C verbatim, there can not
and will not be any copyright issues[2].

Poul-Henning

[1] This is where the trouble starts with music:  There are
only so many guitar-riffs, and parallel creation is bound
to happen.  Ask Led Zeppelin for details.

[2] I wonder if anybody bothered to actually ask IERS director, or
if this is just the usual navel-gazing and circle-jerking from
militant FOSS license-separatists ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Thanks Tony,

On 2016-12-02 10:03 AM, Tony Finch wrote:

Brooks Harris  wrote:


Can you explain that copyright issue further? I was under the impression
Bulletin C and related from IERS were public.

There was a discussion of this issue on the tz list in February:
http://mm.icann.org/pipermail/tz/2016-February/023171.html

Tony.


I see the discussion. On quick review, as I understand it, IERS Bulletin 
C is the single most official Leap Second announcement document -


Bulletin C 52
https://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.52

It does not have any copyright claims on it I can identify. Not do the 
other related files, like 
https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat.


Seems to me any copyright claim would defeat the IERS purposes. Seems to 
me if there were such it would have to be stated in Bulletin C itself.


Where did anyone learn there is some copyright issue with IERS documents?

-Brooks



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

Re: [LEAPSECS] private smear goes public

[Tony Finch]

Brooks Harris  wrote:

> Can you explain that copyright issue further? I was under the impression
> Bulletin C and related from IERS were public.

There was a discussion of this issue on the tz list in February:
http://mm.icann.org/pipermail/tz/2016-February/023171.html

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Biscay: Easterly 4 or 5, occasionally 6 in north, becoming variable 3 at times
in south. Slight or moderate. Fair. Good, occasionally moderate.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Tony,

On 2016-12-02 08:43 AM, Tony Finch wrote:

Poul-Henning Kamp  wrote:

I don't know what the effective latency is from IERS -> TZdata -> distros ->
releases -> users -> computers, but 6 months is only going to be enough
if everybody pays maximum attention *EVERY* *BLOODY* *TIME*.

The cascade actually goes IERS -> NIST -> tz because the NIST leap seconds
announcement is public domain whereas the IERS announcement has an unclear
copyright status.
Can you explain that copyright issue further? I was under the impression 
Bulletin C and related from IERS were public.

-Brooks

And since leap seconds are rather peripheral to the tz
database's purpose, they aren't pushed out amazingly swiftly.

http://mm.icann.org/pipermail/tz/2016-July/023867.html
http://mm.icann.org/pipermail/tz/2016-August/023914.html

Tony.


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

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

On 2016-12-02 12:57 AM, Warner Losh wrote:

On Thu, Dec 1, 2016 at 6:49 PM, Brooks Harris  wrote:

Hi Warner,

On 2016-12-01 08:02 PM, Warner Losh wrote:

On Thu, Dec 1, 2016 at 4:28 PM, Stephen Colebourne 
wrote:

On 1 December 2016 at 19:45, Brooks Harris  wrote:

As I read it I think Google's intention is to publish their method and
algorithm in the hopes others may follow it. It would be better if
everybody
did it the same way, but it will remain to be seen if others will choose
to
follow the example.

The page reads clearly enough to me that:

- Google will leap over 20 hours this time because it is too late to
change their plans
- They plan to leap over 24 hours next time to match Amazon and others
- The propose an informal "standard" of 24 hours leaps henceforth

If all the big IT players agree on a 24 hour leap, 12 hours either
side of midnight UTC, then we have all moved a step forward. Even more
so if they write up the approach as a formal standard.

The next issue is that there are then two types of NTP server -
smeared and non-smeared - and no way to tell the difference. Call me
naive, but that seems like a perfectly soluble problem, either within
NTP or external to it.

For the record, I think that both leap-smeared and leap-accurate
broadcast time have value, but it should be easily possible to tell
which is being received. I also desperately want there to be a name
for the proposed informal standard, so we can all talk about it.

I find the two different types of time amble evidence that leap
seconds are evil and must die. Nobody knows what to do with them. Few
get it right so we have to resort to tricks to pretend they aren't
there. And people that care wind up disappointed that more things
don't get them right. Clearly the bastard stepchild of time that
should be relegated to the dustbin of history.

I'm sure you know I'm on the other side of that opinion; that UTC with Leap
Seconds is a very good, even brilliant, solution to the inconvenient fact of
the Earth's wobbly rotation to preserve the age old tradition of timekeeping
by the sun. This in the same way Gregorian calendar 'solved' the length of
the year.

If it was solved in the same way that the Gregorian Calendar solved
the leap year problem, everybody would get it right. Leap days aren't
a big deal because there's a tiny bit of math that I can do and get it
right every time. I can get the math wrong and still be right for the
next 84 years if I don't know all the rules. The Gregorian Calendar,
though a bit complex, is 100% predictable. I know there will be a Feb
29, 2020, and there won't be a Feb 29, 2021. And I don't need an
internet connection or other data stream to know that.
Sure. I meant only that Gregorian makes an adjustment to the calendar 
counting scheme to keep it aligned to the sun and moon, while Leap 
Seconds makes a much smaller, irregular, adjustment for similar reasons.


Leap seconds are unlike this because they are irregular. They come and
go at the when of the earth's rotation and a bureaucrat's whim.
Well, it seems much more organized than a "whim" to me. An awful lot of 
work by many organizations goes into the IERS's decisions about Leap 
Seconds.

They
aren't regular. You have to know and be in the loop or you'll get them
wrong. There's no formula to look up, no regular rule. There's no math
that will save you. You have to wait for people to look out the window
and hold their thumb in the air and say "it's time". That's another
problem with leap seconds: they are irregular and there's no standard
way to get the leap second info reliably
Oh yes. This seems like an obvious missing link to me. Its been 
discussed here many times.

(though there are sources of
data on the internet that are changing that if you are connected.
From one point of view, too many. And they are not yet uniformly 
formatted nor officially backed up by IERS.


It seems to me IETF RFC 7808, Time Zone Data Distribution Service 
https://tools.ietf.org/html/rfc7808 is the closest thing to a promising 
standard, but its not yet been implemented as a service I know of. It 
seems to hold promise, but there are probably many steps toward formal 
standardization needed to assure the quality of the data before its 
really "official" and uniformly deployed.



Since they are so irregular, nobody gets them right. They aren't
generally included in discussions about time like leap days are. They
are this weird little thing at the edge of UTC that makes it necessary
to have the slewing solutions. Too few people know about how to cope
with them, and the computer standards pretend they don't exist.
Right. Its going to be a very long migration path toward truly Leap 
Second compatible applications. Today there's no coherent plan to 
accomplish that end-to-end.

Unlike
leap days, this is far from a solved problem.

Yup. That's why LEAPSECS, I guess.


I could go on at length for the reasons 

Re: [LEAPSECS] private smear goes public

[Tony Finch]

Poul-Henning Kamp  wrote:
>
> I don't know what the effective latency is from IERS -> TZdata -> distros ->
> releases -> users -> computers, but 6 months is only going to be enough
> if everybody pays maximum attention *EVERY* *BLOODY* *TIME*.

The cascade actually goes IERS -> NIST -> tz because the NIST leap seconds
announcement is public domain whereas the IERS announcement has an unclear
copyright status. And since leap seconds are rather peripheral to the tz
database's purpose, they aren't pushed out amazingly swiftly.

http://mm.icann.org/pipermail/tz/2016-July/023867.html
http://mm.icann.org/pipermail/tz/2016-August/023914.html

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Southeasterly 3 or 4, increasing 5 to 7. Moderate, occasionally
rough in west. Fair at first, then rain or showers. Good, occasionally
moderate.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Poul-Henning Kamp]

In message <20161202095852.d2017406...@ip-64-139-1-69.sjc.megapath.net>, Hal 
Murray writes:
>
>> That's another problem with leap seconds: they are irregular and there's no
>> standard way to get the leap second info reliably (though there are sources
>> of data on the internet that are changing that if you are connected. 
>
>There is a plan to distribute a leap second file as part of the time zone 
>data base.

Even though people have gotten much more aggressive about updating systems,
the fundamental problem is the less than 6-months notice we get.

I don't know what the effective latency is from IERS -> TZdata -> distros ->
releases -> users -> computers, but 6 months is only going to be enough
if everybody pays maximum attention *EVERY* *BLOODY* *TIME*.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Hal Murray]

> That's another problem with leap seconds: they are irregular and there's no
> standard way to get the leap second info reliably (though there are sources
> of data on the internet that are changing that if you are connected. 

There is a plan to distribute a leap second file as part of the time zone 
data base.

It's in Debian and Ubuntu:
  /usr/share/zoneinfo/leap-seconds.list
and FreeBSD:
  /var/db/ntpd.leap-seconds.list
Looks like they packaged it with ntp rather than zone info.

I don't see it in Fedora.

There is one in Raspbian, but it's an old version.


-- 
These are my opinions.  I hate spam.



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

Re: [LEAPSECS] private smear goes public

[Warner Losh]

On Thu, Dec 1, 2016 at 6:49 PM, Brooks Harris  wrote:
> Hi Warner,
>
> On 2016-12-01 08:02 PM, Warner Losh wrote:
>>
>> On Thu, Dec 1, 2016 at 4:28 PM, Stephen Colebourne 
>> wrote:
>>>
>>> On 1 December 2016 at 19:45, Brooks Harris  wrote:

 As I read it I think Google's intention is to publish their method and
 algorithm in the hopes others may follow it. It would be better if
 everybody
 did it the same way, but it will remain to be seen if others will choose
 to
 follow the example.
>>>
>>> The page reads clearly enough to me that:
>>>
>>> - Google will leap over 20 hours this time because it is too late to
>>> change their plans
>>> - They plan to leap over 24 hours next time to match Amazon and others
>>> - The propose an informal "standard" of 24 hours leaps henceforth
>>>
>>> If all the big IT players agree on a 24 hour leap, 12 hours either
>>> side of midnight UTC, then we have all moved a step forward. Even more
>>> so if they write up the approach as a formal standard.
>>>
>>> The next issue is that there are then two types of NTP server -
>>> smeared and non-smeared - and no way to tell the difference. Call me
>>> naive, but that seems like a perfectly soluble problem, either within
>>> NTP or external to it.
>>>
>>> For the record, I think that both leap-smeared and leap-accurate
>>> broadcast time have value, but it should be easily possible to tell
>>> which is being received. I also desperately want there to be a name
>>> for the proposed informal standard, so we can all talk about it.
>>
>> I find the two different types of time amble evidence that leap
>> seconds are evil and must die. Nobody knows what to do with them. Few
>> get it right so we have to resort to tricks to pretend they aren't
>> there. And people that care wind up disappointed that more things
>> don't get them right. Clearly the bastard stepchild of time that
>> should be relegated to the dustbin of history.
>
> I'm sure you know I'm on the other side of that opinion; that UTC with Leap
> Seconds is a very good, even brilliant, solution to the inconvenient fact of
> the Earth's wobbly rotation to preserve the age old tradition of timekeeping
> by the sun. This in the same way Gregorian calendar 'solved' the length of
> the year.

If it was solved in the same way that the Gregorian Calendar solved
the leap year problem, everybody would get it right. Leap days aren't
a big deal because there's a tiny bit of math that I can do and get it
right every time. I can get the math wrong and still be right for the
next 84 years if I don't know all the rules. The Gregorian Calendar,
though a bit complex, is 100% predictable. I know there will be a Feb
29, 2020, and there won't be a Feb 29, 2021. And I don't need an
internet connection or other data stream to know that.

Leap seconds are unlike this because they are irregular. They come and
go at the when of the earth's rotation and a bureaucrat's whim. They
aren't regular. You have to know and be in the loop or you'll get them
wrong. There's no formula to look up, no regular rule. There's no math
that will save you. You have to wait for people to look out the window
and hold their thumb in the air and say "it's time". That's another
problem with leap seconds: they are irregular and there's no standard
way to get the leap second info reliably (though there are sources of
data on the internet that are changing that if you are connected.
Since they are so irregular, nobody gets them right. They aren't
generally included in discussions about time like leap days are. They
are this weird little thing at the edge of UTC that makes it necessary
to have the slewing solutions. Too few people know about how to cope
with them, and the computer standards pretend they don't exist. Unlike
leap days, this is far from a solved problem.

I could go on at length for the reasons why. But I've ranted long enought

> But, regardless of our opinions, Leap Seconds are here to stay until at
> least 2023 and probably much longer. So, "smear" is with us to protect the
> 86400-second-day systems. There's no avoiding this, really, because those
> systems have no hole into which the 86401th peg can be put. And, I might
> add, who ever tested the systems end-to-end for a negative Leap Second?

I did when I was working on them. But I'm sure most people don't. I
know that leap seconds are with us for the foreseeable future. I don't
have to like them.

Warner

>
>>
>> Warner
>> ___
>> 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
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com

Re: [LEAPSECS] private smear goes public

[Hal Murray]

> Could someone provide an introduction to how the rates of these reference
> clocks are adjusted? What's going on inside the black box? 
...
> Can the frequency of the crystal (or whatever) oscillators be adjusted by
> applying some bias voltage? 

It's all done by software.

Each CPU has a nominal clock frequency and some counter that ticks at that 
rate.

The kernel timekeeping routine does something like:
  newcycles = readMagicRegister()
  cycles = newcycles - oldcycles
  oldcycles = newsycles
  newtime = oldtime + cycles*timePerCycle
  oldtime = newtime

The trick is that you need a lot of low bits in timePerCycle.  It's not 
simple integer arithmetic.

The kernel has a system call that ntpd uses to tweak the value of 
timePerCycle.  It's the ntpd drift parameter.  Normally it's used to correct 
for the crystal being slightly off from the nominal value due to 
manufacturing tolerances.  It also tracks minor changes due to temperature 
and aging.

Fudging it slightly to implement a leap smear fits well within reasonable 
numbers as long as the smear is spread over a long enough time slot.  20 
hours is long enough.  ntpd can't tell the difference between a leap smear 
and a temperature shift.



-- 
These are my opinions.  I hate spam.



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

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Warner,
On 2016-12-01 08:02 PM, Warner Losh wrote:

On Thu, Dec 1, 2016 at 4:28 PM, Stephen Colebourne  wrote:

On 1 December 2016 at 19:45, Brooks Harris  wrote:

As I read it I think Google's intention is to publish their method and
algorithm in the hopes others may follow it. It would be better if everybody
did it the same way, but it will remain to be seen if others will choose to
follow the example.

The page reads clearly enough to me that:

- Google will leap over 20 hours this time because it is too late to
change their plans
- They plan to leap over 24 hours next time to match Amazon and others
- The propose an informal "standard" of 24 hours leaps henceforth

If all the big IT players agree on a 24 hour leap, 12 hours either
side of midnight UTC, then we have all moved a step forward. Even more
so if they write up the approach as a formal standard.

The next issue is that there are then two types of NTP server -
smeared and non-smeared - and no way to tell the difference. Call me
naive, but that seems like a perfectly soluble problem, either within
NTP or external to it.

For the record, I think that both leap-smeared and leap-accurate
broadcast time have value, but it should be easily possible to tell
which is being received. I also desperately want there to be a name
for the proposed informal standard, so we can all talk about it.

I find the two different types of time amble evidence that leap
seconds are evil and must die. Nobody knows what to do with them. Few
get it right so we have to resort to tricks to pretend they aren't
there. And people that care wind up disappointed that more things
don't get them right. Clearly the bastard stepchild of time that
should be relegated to the dustbin of history.
I'm sure you know I'm on the other side of that opinion; that UTC with 
Leap Seconds is a very good, even brilliant, solution to the 
inconvenient fact of the Earth's wobbly rotation to preserve the age old 
tradition of timekeeping by the sun. This in the same way Gregorian 
calendar 'solved' the length of the year.


But, regardless of our opinions, Leap Seconds are here to stay until at 
least 2023 and probably much longer. So, "smear" is with us to protect 
the 86400-second-day systems. There's no avoiding this, really, because 
those systems have no hole into which the 86401th peg can be put. And, I 
might add, who ever tested the systems end-to-end for a negative Leap 
Second?


-Brooks




Warner
___
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] private smear goes public

[Brooks Harris]

On 2016-12-01 06:28 PM, Stephen Colebourne wrote:

On 1 December 2016 at 19:45, Brooks Harris  wrote:

As I read it I think Google's intention is to publish their method and
algorithm in the hopes others may follow it. It would be better if everybody
did it the same way, but it will remain to be seen if others will choose to
follow the example.

The page reads clearly enough to me that:

- Google will leap over 20 hours this time because it is too late to
change their plans
- They plan to leap over 24 hours next time to match Amazon and others
- The propose an informal "standard" of 24 hours leaps henceforth

If all the big IT players agree on a 24 hour leap, 12 hours either
side of midnight UTC, then we have all moved a step forward. Even more
so if they write up the approach as a formal standard.

That's all good, I think.


The next issue is that there are then two types of NTP server -
smeared and non-smeared - and no way to tell the difference. Call me
naive, but that seems like a perfectly soluble problem, either within
NTP or external to it.
One quick thought - the smeared NTP servers could be distinguished by 
their DNS names, something along the lines of "time.smear20.google.com" 
or "time.smear24.google.com?


For the record, I think that both leap-smeared and leap-accurate
broadcast time have value, but it should be easily possible to tell
which is being received. I also desperately want there to be a name
for the proposed informal standard, so we can all talk about it.

Hmmm. I agree, a name would be helpful.

"Smear" seems to have taken hold, if not technically exact, at least 
intuitively descriptive. I don't know what a technically proper term for 
that would be.


Above I implied names that signaled the smear's span - "smear20", 
"smear24". There might be other characteristics to incorporate in a name?


-Brooks



Stephen
___
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] private smear goes public

[Warner Losh]

On Thu, Dec 1, 2016 at 4:28 PM, Stephen Colebourne  wrote:
> On 1 December 2016 at 19:45, Brooks Harris  wrote:
>> As I read it I think Google's intention is to publish their method and
>> algorithm in the hopes others may follow it. It would be better if everybody
>> did it the same way, but it will remain to be seen if others will choose to
>> follow the example.
>
> The page reads clearly enough to me that:
>
> - Google will leap over 20 hours this time because it is too late to
> change their plans
> - They plan to leap over 24 hours next time to match Amazon and others
> - The propose an informal "standard" of 24 hours leaps henceforth
>
> If all the big IT players agree on a 24 hour leap, 12 hours either
> side of midnight UTC, then we have all moved a step forward. Even more
> so if they write up the approach as a formal standard.
>
> The next issue is that there are then two types of NTP server -
> smeared and non-smeared - and no way to tell the difference. Call me
> naive, but that seems like a perfectly soluble problem, either within
> NTP or external to it.
>
> For the record, I think that both leap-smeared and leap-accurate
> broadcast time have value, but it should be easily possible to tell
> which is being received. I also desperately want there to be a name
> for the proposed informal standard, so we can all talk about it.

I find the two different types of time amble evidence that leap
seconds are evil and must die. Nobody knows what to do with them. Few
get it right so we have to resort to tricks to pretend they aren't
there. And people that care wind up disappointed that more things
don't get them right. Clearly the bastard stepchild of time that
should be relegated to the dustbin of history.

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

Re: [LEAPSECS] private smear goes public

[Stephen Colebourne]

On 1 December 2016 at 19:45, Brooks Harris  wrote:
> As I read it I think Google's intention is to publish their method and
> algorithm in the hopes others may follow it. It would be better if everybody
> did it the same way, but it will remain to be seen if others will choose to
> follow the example.

The page reads clearly enough to me that:

- Google will leap over 20 hours this time because it is too late to
change their plans
- They plan to leap over 24 hours next time to match Amazon and others
- The propose an informal "standard" of 24 hours leaps henceforth

If all the big IT players agree on a 24 hour leap, 12 hours either
side of midnight UTC, then we have all moved a step forward. Even more
so if they write up the approach as a formal standard.

The next issue is that there are then two types of NTP server -
smeared and non-smeared - and no way to tell the difference. Call me
naive, but that seems like a perfectly soluble problem, either within
NTP or external to it.

For the record, I think that both leap-smeared and leap-accurate
broadcast time have value, but it should be easily possible to tell
which is being received. I also desperately want there to be a name
for the proposed informal standard, so we can all talk about it.

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

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Stephen,

On 2016-12-01 01:08 PM, Stephen Scott wrote:

Hello Brooks, Stephen;

What's all this discussion about precision?

Merely about the math of their smear method.


The smear has tossed the precision of the second SI out the window.
This is totally unacceptable for an application that requires a 
precise and stable frequency reference (telecommunications and 
broadcast for example).
Yes, of course, but the whole purpose of the smear is to hide the Leap 
Second from the downstream 86400-second-day systems, especially 
operating systems, that may not be prepared to cope with the Leap 
Second. As I understand it, it compromises accuracy for reliability, 
buts that the best solution to avoiding potential wide-spread problems.


Further, this is not the only smear algorithm.
A proliferation of smears could be the best reason for getting rid of 
the leap second.
As I read it I think Google's intention is to publish their method and 
algorithm in the hopes others may follow it. It would be better if 
everybody did it the same way, but it will remain to be seen if others 
will choose to follow the example.


-Brooks



The time community is not monolithic and there are different 
requirements of users.

No single approach is likely to satisfy all.
There is a requirement for a minimal set of standardized approaches.

-Stephen


On 2016-12-01 12:39, Brooks Harris wrote:

Hi Stephen,
On 2016-12-01 02:49 AM, Stephen Colebourne wrote:

More details on the developer site:
https://developers.google.com/time/

Notably this page:
https://developers.google.com/time/smear

which include "Our proposed standard smear" - "We would like to
propose to the community, as the best practice for leap seconds in the
future, a 24-hour linear smear from noon to noon UTC"

Hip hip hooray! De facto standards for the win!

Stephen

Ah, this is good. I'd missed that page yesterday.

I might suggest you good go a little further.

You say "Each second of time marked by Google's servers will be about 
13.9 μs longer than an SI second. "


Some developers may probably need to know exactly, or as exactly as 
possible, the ratio.


If I've got this right:

20 hours = 20 * 60 * 60 = 72000 seconds
Plus the Leap Second = 72001 second
So the ratio is 72001 / 72000 = 1.13889 (rounded to 10-9th 
precision, nanoseconds)

This a repeating decimal number which may be denoted 1.13(8).
Applications should be careful to provide adequate precision for the 
purpose.


-Brooks









On 30 November 2016 at 21:05, Tom Van Baak  wrote:

I'm surprised no one has posted this news yet:

"Making every (leap) second count with our new public NTP servers"
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html 



/tvb

___
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




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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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] private smear goes public

[Richard Clark]

Could someone provide an introduction to how the rates of these
reference clocks are adjusted? What's going on inside the black box?

For instance, I once tweaked the rate of a cheap sports watch by
opening it up and turning a screw that applied force on the crystal
physically altering its frequency. I'm sure this is not how these NTP
reference clocks are adjusted.

Can the frequency of the crystal (or whatever) oscillators be adjusted
by applying some bias voltage?

Or are oscillations counted and the rules for issueing 1-second
signals adjusted. A count of oscillations will be an integer so
every N seconds a 'leap oscillation' is allowed in the count for
higher precision? and for a rate adjustment?

Or is the phase of the oscillations tracked so precision finer than
the oscillator period is directly achievable?

I'm just making wild guesses here.

Or do the higher level NTP servers use their own local atomic clocks
and not quartz crystal based clocks?

Richard Clark
rcl...@noao.edu

On Thu, 1 Dec 2016, Brooks Harris wrote:


Hi Stephen,
On 2016-12-01 02:49 AM, Stephen Colebourne wrote:

More details on the developer site:
https://developers.google.com/time/

Notably this page:
https://developers.google.com/time/smear

which include "Our proposed standard smear" - "We would like to
propose to the community, as the best practice for leap seconds in the
future, a 24-hour linear smear from noon to noon UTC"

Hip hip hooray! De facto standards for the win!

Stephen

Ah, this is good. I'd missed that page yesterday.

I might suggest you good go a little further.

You say "Each second of time marked by Google's servers will be about 
13.9 μs longer than an SI second. "


Some developers may probably need to know exactly, or as exactly as 
possible, the ratio.


If I've got this right:

20 hours = 20 * 60 * 60 = 72000 seconds
Plus the Leap Second = 72001 second
So the ratio is 72001 / 72000 = 1.13889 (rounded to 10-9th 
precision, nanoseconds)

This a repeating decimal number which may be denoted 1.13(8).
Applications should be careful to provide adequate precision for the 
purpose.


-Brooks









On 30 November 2016 at 21:05, Tom Van Baak  wrote:

I'm surprised no one has posted this news yet:

"Making every (leap) second count with our new public NTP servers"


https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html


/tvb

___
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




___
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] private smear goes public

[Stephen Scott]

Hello Brooks, Stephen;

What's all this discussion about precision?

The smear has tossed the precision of the second SI out the window.
This is totally unacceptable for an application that requires a precise 
and stable frequency reference (telecommunications and broadcast for 
example).


Further, this is not the only smear algorithm.
A proliferation of smears could be the best reason for getting rid of 
the leap second.


The time community is not monolithic and there are different 
requirements of users.

No single approach is likely to satisfy all.
There is a requirement for a minimal set of standardized approaches.

-Stephen


On 2016-12-01 12:39, Brooks Harris wrote:

Hi Stephen,
On 2016-12-01 02:49 AM, Stephen Colebourne wrote:

More details on the developer site:
https://developers.google.com/time/

Notably this page:
https://developers.google.com/time/smear

which include "Our proposed standard smear" - "We would like to
propose to the community, as the best practice for leap seconds in the
future, a 24-hour linear smear from noon to noon UTC"

Hip hip hooray! De facto standards for the win!

Stephen

Ah, this is good. I'd missed that page yesterday.

I might suggest you good go a little further.

You say "Each second of time marked by Google's servers will be about 
13.9 μs longer than an SI second. "


Some developers may probably need to know exactly, or as exactly as 
possible, the ratio.


If I've got this right:

20 hours = 20 * 60 * 60 = 72000 seconds
Plus the Leap Second = 72001 second
So the ratio is 72001 / 72000 = 1.13889 (rounded to 10-9th 
precision, nanoseconds)

This a repeating decimal number which may be denoted 1.13(8).
Applications should be careful to provide adequate precision for the 
purpose.


-Brooks









On 30 November 2016 at 21:05, Tom Van Baak  wrote:

I'm surprised no one has posted this news yet:

"Making every (leap) second count with our new public NTP servers"
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html 



/tvb

___
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




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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Stephen,
On 2016-12-01 02:49 AM, Stephen Colebourne wrote:

More details on the developer site:
https://developers.google.com/time/

Notably this page:
https://developers.google.com/time/smear

which include "Our proposed standard smear" - "We would like to
propose to the community, as the best practice for leap seconds in the
future, a 24-hour linear smear from noon to noon UTC"

Hip hip hooray! De facto standards for the win!

Stephen

Ah, this is good. I'd missed that page yesterday.

I might suggest you good go a little further.

You say "Each second of time marked by Google's servers will be about 
13.9 μs longer than an SI second. "


Some developers may probably need to know exactly, or as exactly as 
possible, the ratio.


If I've got this right:

20 hours = 20 * 60 * 60 = 72000 seconds
Plus the Leap Second = 72001 second
So the ratio is 72001 / 72000 = 1.13889 (rounded to 10-9th 
precision, nanoseconds)

This a repeating decimal number which may be denoted 1.13(8).
Applications should be careful to provide adequate precision for the 
purpose.


-Brooks









On 30 November 2016 at 21:05, Tom Van Baak  wrote:

I'm surprised no one has posted this news yet:

"Making every (leap) second count with our new public NTP servers"
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html

/tvb

___
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




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

Re: [LEAPSECS] private smear goes public

[Stephen Colebourne]

More details on the developer site:
https://developers.google.com/time/

Notably this page:
https://developers.google.com/time/smear

which include "Our proposed standard smear" - "We would like to
propose to the community, as the best practice for leap seconds in the
future, a 24-hour linear smear from noon to noon UTC"

Hip hip hooray! De facto standards for the win!

Stephen


On 30 November 2016 at 21:05, Tom Van Baak  wrote:
> I'm surprised no one has posted this news yet:
>
> "Making every (leap) second count with our new public NTP servers"
> https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html
>
> /tvb
>
> ___
> 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] private smear goes public

[Brooks Harris]

On 2016-11-30 10:23 PM, Michael Shields via LEAPSECS wrote:

On Wed, Nov 30, 2016 at 7:06 PM, Brooks Harris  wrote:

One wishes announments like this were a bit more accurate. They say "...
we'll run the clocks 0.0014% slower across the ten hours before and ten
hours after the leap second ...", but I think it must be closer to
0.0013 percent. I wonder what precision they use?

It would, of course, take an infinite number of decimal digits to
represent the actual ratio.

Yes. An ever irritating fact of life.

The calculations are done at nanosecond
precision.

OK, makes sense. Thanks.
-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] private smear goes public

[Michael Shields via LEAPSECS]

On Wed, Nov 30, 2016 at 7:06 PM, Brooks Harris  wrote:
> One wishes announments like this were a bit more accurate. They say "...
> we'll run the clocks 0.0014% slower across the ten hours before and ten
> hours after the leap second ...", but I think it must be closer to
> 0.0013 percent. I wonder what precision they use?

It would, of course, take an infinite number of decimal digits to
represent the actual ratio.  The calculations are done at nanosecond
precision.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Tom,

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


One wishes announments like this were a bit more accurate. They say "... 
we'll run the clocks 0.0014% slower across the ten hours before and ten 
hours after the leap second ...", but I think it must be closer to 
0.0013 percent. I wonder what precision they use?


-Brooks


On 2016-11-30 04:05 PM, Tom Van Baak wrote:

I'm surprised no one has posted this news yet:
"Making every (leap) second count with our new public NTP servers"
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html
/tvb


___
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