Re: [LEAPSECS] Windows Server 2019

[Michael Deckers via LEAPSECS]

   On 2018-07-20 18:05, Stephen Scott wrote:



While there is no perfect answer, it seems that Microsoft Azure 
servers got it right for the last one, incorporating the leap second 
just before midnight local time.



    No, they didn't.

    A leap second describes a discontinuity in the function TAI - UTC. 
For the last leap second,
    the value TAI - UTC  was 37 s since TAI was 2017-01-01T00:00:37, 
and for some

    time before that, it was 36 s until TAI reached 2017-01-01T00:00:36.
    The standards do _not_ say when exactly TAI - UTC switched from 36 
s to 37 s, but it must have
    been between the TAI values 2017-01-01T00:00:36 and 
2017-01-01T00:00:37, inclusive, as can
    be inferred (perhaps with some good will) from IERS Bulletin C52 of 
2016-07-06 (the official

    specification of this leap second).

    The time interval between these TAI values (excluding the TAI value 
2017-01-01T00:00:37) is called
    a positive leap second; the corresponding UTC values are denoted 
(in ISO 8601 format) with

    second values >= 60 (as specified in ITU-R TF.460-6 of 2002).

    This is true everywhere near the surface of the Earth, even for 
Kiritimati. So Kiritimati
    had its last leap second when every other location on the Earth had 
it, that is,
    when TAI went from 2017-01-01T00:00:36  to just before 
2017-01-01T00:00:37,
    and  UTC went from 2016-12-31-23:59:60Z to just before 
2017-01-01T00:00:00Z; so that local time
    went from 2017-01-01T13:59:60+14 to just before 
2017-01-01T14:00:00+14 during that leap second.


    HTH.

    Michael Deckers.

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

Re: [LEAPSECS] Windows Server 2019

[Michael Deckers via LEAPSECS]

   On 2018-07-21 01:08, Steve Allen wrote:




At that same meeting IAU Comm 31 was led to yield that they had no
influence over the leap seconds that the CCIR had instituted, and IAU
Comm 31 was pressed to produce a statement declaring that leap seconds
were "the optimum solution."
http://adsabs.harvard.edu/abs/1971IAUTB..14..198W



   Thanks for that document!

   I note the typo on page 198 where it says under the heading
   "9. Designation of the epoch of steps in UTC":
  "9.1. If UTC is to be advanced, then second 00 will follow
    23h 59m 58s of the previous day."
  "9.2. If UTC is to be retarded, then the second of the previous day
    23h 59m 58s will be followed by the next second 0h 00m 00s
    of the first day of the month."

   And the text
  "9.4. The time of an event given in the old scale, before the
    leap second, will be given as a data in the previous month,
    exceeding 24h if necessary. The time of an event given in the
    scale after the step will be given as a data in the new month,
    with a negative time, if necessary."
    gives not only the leap second notation long before CCIR codified it
    in 1978, but also shows an alternative notation.



All of the above strike me as "something is seriously wrong here."

Looking deeper into the history and memoirs by folks who were involved
it becomes clear that the inception of leap seconds was the
culmination of a 20 year game of international regulatory and
scientific agency pinball.  After the CCIR introduced them that game
continued for another 10 years as other agencies and governments were
led to approve the notion of UTC with leap seconds using words like
"parfaitment recommandable".


    I do not see what you mean here. Before 1972, the BIH (under control
    of the IAU) had defined UTC. The document (above) you quoted contains
    the approval by IAU Commissions 4 and 31 to the leap second scheme as
    proposed by the CCIR. The introduction of leap seconds happened 
with the

    support of the BIH, and all the discrepancies among disseminated radio
    time scales vanished on 1972-01-01. Not much gaming.

    The recommendation of the 15th CGPM in 1975 that "this usage
    [of UTC] can be strongly endorsed" does not appear to me to have
    been forced upon the CGPM. The resolution does not even call UTC a
    time scale, it merely states what was obvious at the time:
 •  that the system called “Coordinated Universal Time” (UTC)
    is widely used,
 •  that it is broadcast in most radio transmissions of time signals,
 •  that this wide diffusion makes available to the users not only
    frequency standards but also International Atomic Time and an
    approximation to Universal Time (or, if one prefers, mean solar 
time),
 •  that this Coordinated Universal Time provides the basis of 
civil time,

    the use of which is legal in most countries.

 Compare this with the proposed resolution B of the 26th CGPM in
 2018 November which declares that:
 •  UTC produced by the BIPM, based on TAI, is the only recommended
    time scale for international reference and the basis of civil
    time in most countries,
 This latter resolution can in fact be seen as the BIPM claiming
 the defining authority for UTC from ITU-R, by making it clear that
 the realization of UTC (except for the encoding of time signals)
 is already completely controlled by data from Bulletin T of
 the BIPM. If I were looking for a competition between
 standardizing bodies, I would rather point to this resolution.



I have found nothing that directly explains why it was repeatedly
deemed impossible for any of these agencies to explain and recommend
the existence of two kinds of time scales, but it seems clear that
the legal considerations led toward the notion of a compromise.



    I do not think that there was any disagreement around 1970 about
    the need for multiple time scales, neither among astronomers
    (who used many more time scales than just two) nor among radio
    people (who would at least distinguish TAI, UT0, UT1, UT2 and UTC).

    The CCIR wanted to select a reference time scale to be disseminated
    world-wide in order to achieve global synchronization in phase and
    frequency.  Disseminating two different reference time scales
    for that purpose does not make sense: a single globally available
    reference time scale allows for the dissemination and comparison of
    the readings of any number of time scales across the globe (up to
    the uncertainty of the rate of the reference time scale and only
    as far as these time scales use the same concept of synchronicity
    near the surface of the Earth).




So we have betrayal, eroded trust, and reduced usefulness because some
folks wanted to take what looked like a politically expedient shortcut
which was full of unexplained 

Re: [LEAPSECS] Windows Server 2019

[Steve Allen]

On Mon 2018-07-23T13:18:22-0600 Warner Losh hath writ:
> In the absence of setting a local time for the leap
> second, the offset is controlling and therefore it happens at UTC midnight,
> since it's definitely and unambiguously defined in ITU-R TF 460-6 as such
> (all known earlier revisions too, I believe was the conclusion when a
> similar issue was raised years ago on this list, though I think -3 was the
> oldest that could be found at that time).

We have managed to obtain scans of varying rattiness of all versions.
More interesting than the versions themselves are the related
recommendations (some since withdrawn) and the transcripts of the
discussion in the voting sessions.  Those give some clues into
what had and had not been presented to the general assembly in
order to motivate their approval of the new versions.  E.g.,
from 1974 through 1997 the ITU-R recommeded using either UTC
or TAI as appropriate.
https://www.itu.int/rec/R-REC-TF.485/en

CCIR Rec 460 had no details other than 1 second leaps.
This original (version "0") Rec was reprinted in various places
including by US NBS in Monograph 140, so it is online in scanned
documents.

The rules were worked out in CCIR Report 517 (Question 1/7, Resolution 53)
by Study Group 7 during 1971-02-17/23.  This put the leap second at UTC
midnight.  It is also reprinted in NBS Monograph 140.

This was incorporated into Rec 460-1 by the CCIR general assembly
between 1971-02-17/23 and remains the same in all subsequent revisions.

CCIR and ITU-R documents mention UTC, UT[012], and TAI, and they refer
the reader to other agencies for definitions of those terms.
They do not mention local civil time,

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

Re: [LEAPSECS] Windows Server 2019

[Warner Losh]

On Mon, Jul 23, 2018 at 12:52 PM, Steve Allen  wrote:

> On Mon 2018-07-23T13:58:49-0400 Stephen Scott hath writ:
> > I have not found any specifications or official documents that specify
> that
> > the leap second shall be incorporated just before the time instant
> midnight
> > UTC for all UTC offset timescales.
>
> There is no authority for "all UTC offset timescales."
> All local times are decided by local jurisdictions.
> This is an issue long treated in the IANA tz mail list which
> is a community effort that makes best effort to track every
> little change made by every legislature and bureaucrat.


This is more an absence of a thing. There's plenty of laws that say it's a
fixed offset from UTC or some other approximation of Mean Solar Time which
everybody construes to mean UTC these days (even if a pedantic reading
doesn't lean one here). In the absence of setting a local time for the leap
second, the offset is controlling and therefore it happens at UTC midnight,
since it's definitely and unambiguously defined in ITU-R TF 460-6 as such
(all known earlier revisions too, I believe was the conclusion when a
similar issue was raised years ago on this list, though I think -3 was the
oldest that could be found at that time).

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

Re: [LEAPSECS] Windows Server 2019

[Steve Allen]

On Mon 2018-07-23T13:58:49-0400 Stephen Scott hath writ:
> I have not found any specifications or official documents that specify that
> the leap second shall be incorporated just before the time instant midnight
> UTC for all UTC offset timescales.

There is no authority for "all UTC offset timescales."
All local times are decided by local jurisdictions.
This is an issue long treated in the IANA tz mail list which
is a community effort that makes best effort to track every
little change made by every legislature and bureaucrat.

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

Re: [LEAPSECS] Windows Server 2019

[Stephen Scott]

All;

What I was trying to get an answer to is "Why is the one leap second 
treated any different from the other 86400 seconds in the day when 
offsetting the UTC time to a UTC offset time zone?"


Yes, ITU-R TF 460-6 defines the timing of the leap second in UTC.

I have not found any specifications or official documents that specify 
that the leap second shall be incorporated just before the time instant 
midnight UTC for all UTC offset timescales.


Stephen

On 2018-07-23 11:40, Steve Allen wrote:

On Fri 2018-07-20T12:16:07-0600 Warner Losh hath writ:

Unless you are at UTC+0, I don't see how this can be right... Leap seconds
happen during the day for most time zones...

On Fri 2018-07-20T16:11:12-0400 Stephen Scott hath writ:

What I am asking is WHY.
Where is the standard for that?
Or at least some document that specifies that?

On Mon 2018-07-23T14:05:13+0100 Tony Finch hath writ:

The standard for leap seconds is ITU-R TF.460

https://www.itu.int/rec/R-REC-TF.460/en

Most legislation and decrees about legal time specifies that the local
civil time is some number of hours and minutes different from GMT or
UTC.  Taking the simplest interpretation on January 1
on every other day  23:59:59 UTC is 15:59:59 PST
on every other day  00:00:00 UTC is 16:00:00 PST
so most simply  23:59:60 UTC is 15:59:60 PST
If the base time in the law or decree is GMT (as it was in the US
until 2007) then all of this is by convention following whatever
official metrology agency is tasked with providing legal time for that
jurisdiction.

A law could specify what Microsoft reportedly did in Azure, that is,
Kiribati could apply the leap at the begin of their January 1 13 hours
before of 0h UTC, and Hawaii could apply the leap 11 hours after 0h
UTC, but it is hard to imagine legislators and bureaucrats getting
that specific unless their metrology agencies provided powerful
technical arguments about why being off by one second for all of those
hours was less harmful than taking the leap second in the middle of
the day.  That might happen if some international regulatory or
scientific agency produced a recommendation saying that every nation
should do leap seconds at local midnight, but that just moves the
"hard to imagine" into a different arena.

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




---
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] Windows Server 2019

[Warner Losh]

On Mon, Jul 23, 2018 at 9:40 AM, Steve Allen  wrote:

> On Fri 2018-07-20T12:16:07-0600 Warner Losh hath writ:
> > Unless you are at UTC+0, I don't see how this can be right... Leap
> seconds
> > happen during the day for most time zones...
>
> On Fri 2018-07-20T16:11:12-0400 Stephen Scott hath writ:
> > What I am asking is WHY.
> > Where is the standard for that?
> > Or at least some document that specifies that?
>
> On Mon 2018-07-23T14:05:13+0100 Tony Finch hath writ:
> > The standard for leap seconds is ITU-R TF.460
> >
> > https://www.itu.int/rec/R-REC-TF.460/en
>
> Most legislation and decrees about legal time specifies that the local
> civil time is some number of hours and minutes different from GMT or
> UTC.  Taking the simplest interpretation on January 1
> on every other day  23:59:59 UTC is 15:59:59 PST
> on every other day  00:00:00 UTC is 16:00:00 PST
> so most simply  23:59:60 UTC is 15:59:60 PST
> If the base time in the law or decree is GMT (as it was in the US
> until 2007) then all of this is by convention following whatever
> official metrology agency is tasked with providing legal time for that
> jurisdiction.
>
> A law could specify what Microsoft reportedly did in Azure, that is,
> Kiribati could apply the leap at the begin of their January 1 13 hours
> before of 0h UTC, and Hawaii could apply the leap 11 hours after 0h
> UTC, but it is hard to imagine legislators and bureaucrats getting
> that specific unless their metrology agencies provided powerful
> technical arguments about why being off by one second for all of those
> hours was less harmful than taking the leap second in the middle of
> the day.  That might happen if some international regulatory or
> scientific agency produced a recommendation saying that every nation
> should do leap seconds at local midnight, but that just moves the
> "hard to imagine" into a different arena.
>

When this has come up in the past, no examples of that were offered.
There's some niggles for a couple places that still use "local solar time"
(whatever that means, since it specifically isn't UT1 or a mean solar
time), but those places don't use leap seconds. No examples have been
brought forward, and I'm with Steve on this: Local bureaucrats likely don't
care enough to specify that detail, and most certainly wouldn't stick their
neck out to be the odd-man-out in this arena.

I do know it is certainly the case that in the US, EU, China, Japan, NZ and
AU that local authorities construe their laws to mean the leap second
happens at midnight UTC, but I have have no specific documentation or
regulations I can point to for that. Just the conversations with Judah
Levine I had years ago when they were looking at getting rid of leap
seconds because they were troublesome in Asia where they happened in the
middle of the day... I believe the issue was documented in many of the
"Turin" meeting docs.

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

Re: [LEAPSECS] Windows Server 2019

[Steve Allen]

On Fri 2018-07-20T12:16:07-0600 Warner Losh hath writ:
> Unless you are at UTC+0, I don't see how this can be right... Leap seconds
> happen during the day for most time zones...

On Fri 2018-07-20T16:11:12-0400 Stephen Scott hath writ:
> What I am asking is WHY.
> Where is the standard for that?
> Or at least some document that specifies that?

On Mon 2018-07-23T14:05:13+0100 Tony Finch hath writ:
> The standard for leap seconds is ITU-R TF.460
>
> https://www.itu.int/rec/R-REC-TF.460/en

Most legislation and decrees about legal time specifies that the local
civil time is some number of hours and minutes different from GMT or
UTC.  Taking the simplest interpretation on January 1
on every other day  23:59:59 UTC is 15:59:59 PST
on every other day  00:00:00 UTC is 16:00:00 PST
so most simply  23:59:60 UTC is 15:59:60 PST
If the base time in the law or decree is GMT (as it was in the US
until 2007) then all of this is by convention following whatever
official metrology agency is tasked with providing legal time for that
jurisdiction.

A law could specify what Microsoft reportedly did in Azure, that is,
Kiribati could apply the leap at the begin of their January 1 13 hours
before of 0h UTC, and Hawaii could apply the leap 11 hours after 0h
UTC, but it is hard to imagine legislators and bureaucrats getting
that specific unless their metrology agencies provided powerful
technical arguments about why being off by one second for all of those
hours was less harmful than taking the leap second in the middle of
the day.  That might happen if some international regulatory or
scientific agency produced a recommendation saying that every nation
should do leap seconds at local midnight, but that just moves the
"hard to imagine" into a different arena.

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

Re: [LEAPSECS] Windows Server 2019

[Tony Finch]

Stephen Scott  wrote:

> Where is the standard for that?
> Or at least some document that specifies that?

The standard for leap seconds is ITU-R TF.460

https://www.itu.int/rec/R-REC-TF.460/en

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
disperse power, foster diversity, and nurture creativity
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Windows Server 2019

[Steve Allen]

On Fri 2018-07-20T14:23:38+ Nero Imhard hath writ:
> Leap second smearing by an NTP server effectively means that it uses
> a different time. Without a way to indicate, within the protocol,
> what time a server uses (and there isn't because UTC is implicit) this
> seems a really bad idea.
>
> On another level, I regard it as some sort of "technical betrayal"
> which erodes trust in protocols and standards, rendering them less
> useful than they could be.
>
> Isolate your workarounds and don't let them pollute your environment.

In the arena of leap seconds, technical betrayal and dilution of the
protocols and standards began before the inception date.

Gernot Winkler of USNO is credited as one of the people who suggested
that the leap second could be the solution to the problem.  Gernot
Winkler reported that radio broadcast time signals operated by the
USNO would follow TAI and not implement leap seconds, while at the
same time the USNO Nautical Almanac tabulated events in Ephemeris Time
and UT1.  This is clearly the USNO making use of the "two time scales"
scheme that since 1948 astronomers had been saying would be necessary,
and not following international protocols and standards.
https://www.ucolick.org/~sla/leapsecs/leapincept.html
Gernot Winkler was co-author of the 1970 report to the IAU that said
leap seconds would cause problems for automated navigation systems.
http://adsabs.harvard.edu/abs/1970IAUTA..14..343Z
At the 1970 IAU Comm 31 meeting Gernot Winkler was acting president
where in the transcript it is clear that at least one paragraph has
been omitted about the response in the IAU meeting when the CCIR
decision to implement leap seconds was announced.
http://adsabs.harvard.edu/abs/1971IAUTB..14..193W
At that same meeting IAU Comm 31 was led to yield that they had no
influence over the leap seconds that the CCIR had instituted, and IAU
Comm 31 was pressed to produce a statement declaring that leap seconds
were "the optimum solution."
http://adsabs.harvard.edu/abs/1971IAUTB..14..198W

All of the above strike me as "something is seriously wrong here."

Looking deeper into the history and memoirs by folks who were involved
it becomes clear that the inception of leap seconds was the
culmination of a 20 year game of international regulatory and
scientific agency pinball.  After the CCIR introduced them that game
continued for another 10 years as other agencies and governments were
led to approve the notion of UTC with leap seconds using words like
"parfaitment recommandable".

The game started when the IAU produced a recommendation for radio
broadcast time signals that was not implementable within available
resources.  Another agency produced a recommendation based on criteria
which were relevant to its particular mission.  At subsequent meetings
of other agencies the agreements made by previous agencies were
represented as the basis for further recommendations.  One of the
agreements used in this game was achieved not at an international
meeting, but in the living room of one of the delegates.  This process
continued until CCIR was led to approve leap seconds without any
accompanying documentation about the technical details of how they
would be implemented.

Several documents indicate that the preparatory meetings prior to the
international assemblies discussed that changes to national laws would
be required in order to broadcast a purely atomic time scale.
I have found nothing that directly explains why it was repeatedly
deemed impossible for any of these agencies to explain and recommend
the existence of two kinds of time scales, but it seems clear that
the legal considerations led toward the notion of a compromise.
I surmise that the folks who wanted to broadcast atomic frequency were
in too much of a hurry to wait for a critical mass of nations to
legislate and allow their national metrology agencies to recognize and
broadcast purely atomic time, so they took a shortcut.
Taking that shortcut meant going to the CCIR with a proposal that did
not explain the consequences and mechanisms, neither to the delegates
who voted nor to any implementors of systems using UTC.

I am not sure whether these kinds of interaction among international
regulatory and scientific agencies are perfectly normal business as
usual, or an example of systematic abuse spanning over decades.  I am
sure that the result was dysfunctional operational systems (which
still lack solid technical underpinnings) and a trail of technical
folks who had withdrawn from the arena to have their agencies continue
using time scales that were not UTC with leap seconds.  I am also sure
that after an ensemble of international agencies have been persuaded
to approve something it becomes very difficult to unapprove it even if
its initial approval was achieved under dubious circumstances with
serious unaddressed technical questions.

So we have betrayal, eroded trust, and reduced usefulness because some
folks wanted to take what looked like 

Re: [LEAPSECS] Windows Server 2019

[Stephen Scott]

On 2018-07-20 14:16, Warner Losh wrote:



On Fri, Jul 20, 2018, 12:05 PM Stephen Scott 
mailto:stephensc...@videotron.ca>> wrote:


I would agree and I am not a fan of leap second smearing.
A.)  For an application that depends on an accurate frequency
reference smearing over 24 hours represents about a 11 ppm
frequency shift. This exceeds the tolerance specified for some
audio/video applications.
B.) It is not standardized, so maybe it is a smear of maybe its not.

There is a lack of standards and that is probably the biggest
source of most leap second problems.

I have been searching for standards, documentation on how leap
seconds must be applied in local jurisdictions.

I find it strange that for time in local time zones the time
points are shifted by the UTC offset for all 86400 seconds of the day.
But that the one leap second is treated differently and is not
shifted by the UTC offset.
The consequence is that the leap second is being incorporated at
critical times of the day in many time zones.

While there is no perfect answer, it seems that Microsoft Azure
servers got it right for the last one, incorporating the leap
second just before midnight local time.


Unless you are at UTC+0, I don't see how this can be right... Leap 
seconds happen during the day for most time zones...

What I am asking is WHY.
Where is the standard for that?
Or at least some document that specifies that?

Stephen


Warner

Control, on Time and in Sync
Stephen Scott



On 2018-07-20 08:03, Nero Imhard wrote:


scs...@eskimo.com  schreef op
2018-07-20 11:35:


The question of what happens if you try to run a leapsec-aware
kernel downstream of a smearing NTP server is an interesting one.
My preferred answer is "Don't do that."

If that translates to "don't smear ntp" I could not agree more.
Smearing is catering to those who won't clean up their act,
causing trouble for those who try to do the right thing.
N


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





Virus-free. www.avast.com




<#m_-5058450252262385288_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
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] Windows Server 2019

[Warner Losh]

On Fri, Jul 20, 2018, 12:05 PM Stephen Scott 
wrote:

> I would agree and I am not a fan of leap second smearing.
> A.)  For an application that depends on an accurate frequency reference
> smearing over 24 hours represents about a 11 ppm frequency shift. This
> exceeds the tolerance specified for some audio/video applications.
> B.) It is not standardized, so maybe it is a smear of maybe its not.
>
> There is a lack of standards and that is probably the biggest source of
> most leap second problems.
>
> I have been searching for standards, documentation on how leap seconds
> must be applied in local jurisdictions.
>
> I find it strange that for time in local time zones the time points are
> shifted by the UTC offset for all 86400 seconds of the day.
> But that the one leap second is treated differently and is not shifted by
> the UTC offset.
> The consequence is that the leap second is being incorporated at critical
> times of the day in many time zones.
>
> While there is no perfect answer, it seems that Microsoft Azure servers
> got it right for the last one, incorporating the leap second just before
> midnight local time.
>

Unless you are at UTC+0, I don't see how this can be right... Leap seconds
happen during the day for most time zones...

Warner

> Control, on Time and in Sync
> Stephen Scott
>
>
>
> On 2018-07-20 08:03, Nero Imhard wrote:
>
> scs...@eskimo.com schreef op 2018-07-20 11:35:
>
> The question of what happens if you try to run a leapsec-aware
> kernel downstream of a smearing NTP server is an interesting one.
> My preferred answer is "Don't do that."
>
>
> If that translates to "don't smear ntp" I could not agree more.
> Smearing is catering to those who won't clean up their act,
> causing trouble for those who try to do the right thing.
>
> N
>
>
> ___
> LEAPSECS mailing 
> listLEAPSECS@leapsecond.comhttps://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-5058450252262385288_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Windows Server 2019

[Stephen Scott]

I would agree and I am not a fan of leap second smearing.
A.)  For an application that depends on an accurate frequency reference 
smearing over 24 hours represents about a 11 ppm frequency shift. This 
exceeds the tolerance specified for some audio/video applications.

B.) It is not standardized, so maybe it is a smear of maybe its not.

There is a lack of standards and that is probably the biggest source of 
most leap second problems.


I have been searching for standards, documentation on how leap seconds 
must be applied in local jurisdictions.


I find it strange that for time in local time zones the time points are 
shifted by the UTC offset for all 86400 seconds of the day.
But that the one leap second is treated differently and is not shifted 
by the UTC offset.
The consequence is that the leap second is being incorporated at 
critical times of the day in many time zones.


While there is no perfect answer, it seems that Microsoft Azure servers 
got it right for the last one, incorporating the leap second just before 
midnight local time.


Control, on Time and in Sync
Stephen Scott



On 2018-07-20 08:03, Nero Imhard wrote:


scs...@eskimo.com schreef op 2018-07-20 11:35:


The question of what happens if you try to run a leapsec-aware
kernel downstream of a smearing NTP server is an interesting one.
My preferred answer is "Don't do that."

If that translates to "don't smear ntp" I could not agree more.
Smearing is catering to those who won't clean up their act,
causing trouble for those who try to do the right thing.
N


___
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] Windows Server 2019

[Martin Burnicki]

Nero Imhard wrote:
> Martin Burnicki schreef op 2018-07-20 12:52:
> 
>> Nero Imhard wrote:
>>> If that translates to "don't smear ntp" I could not agree more.
>>> Smearing is catering to those who won't clean up their act,
>>> causing trouble for those who try to do the right thing.
>>
>> Please don't blame ntpd for smearing leap seconds.
>  
> I don't. ntpd would be the victim here.

;-)
  
>> Leap second smearing by an NTP server is just an optional way to avoid
>> these problems because there's no better way to get around it.
>  
> Leap second smearing by an NTP server effectively means that it uses
> a different time. Without a way to indicate, within the protocol,
> what time a server uses (and there isn't because UTC is implicit) this
> seems a really bad idea.

Basically I agree with you, but ...

> On another level, I regard it as some sort of "technical betrayal"
> which erodes trust in protocols and standards, rendering them less
> useful than they could be.

Yes, the NTP protocol has been designed to work with UTC time stamps.

I know there are also folks who let their own NTP server transmit pure
TAI or raw GPS time instead of UTC, since some devices on their network
need this.

Also, even the NIST operates an NTP server that provides UT1 rather than
UTC.

So for specific cases, in a closed environment, it's OK IMO.
  
> Isolate your workarounds and don't let them pollute your environment. 

Especially, there shouldn't be any public/pool servers that smear leap
seconds.

If you are administrator for a huge company network you are eventually
very happy if you can just let the company's NTP server smear a leap
second, and none of the clients or applications encounter any problem.

If you don't want it, don't use it. ;-)

The problem is if there are folks that don't know (exactly) what they
are doing, e.g. use as reference one of Google's public servers that are
known to smear leap seconds.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

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
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

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

Re: [LEAPSECS] Windows Server 2019

[Nero Imhard]

Martin Burnicki schreef op 2018-07-20 12:52:

> Nero Imhard wrote: 
> 
>> If that translates to "don't smear ntp" I could not agree more.
>> Smearing is catering to those who won't clean up their act,
>> causing trouble for those who try to do the right thing.
> 
> Please don't blame ntpd for smearing leap seconds.

I don't. ntpd would be the victim here. 

> Leap second smearing by an NTP server is just an optional way to avoid 
> these problems because there's no better way to get around it.

Leap second smearing by an NTP server effectively means that it uses 
a different time. Without a way to indicate, within the protocol, 
what time a server uses (and there isn't because UTC is implicit) this 
seems a really bad idea. 

On another level, I regard it as some sort of "technical betrayal" 
which erodes trust in protocols and standards, rendering them less 
useful than they could be. 

Isolate your workarounds and don't let them pollute your environment.  

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

Re: [LEAPSECS] Windows Server 2019

[Warner Losh]

On Fri, Jul 20, 2018 at 6:03 AM, Nero Imhard  wrote:

> scs...@eskimo.com schreef op 2018-07-20 11:35:
>
> The question of what happens if you try to run a leapsec-aware
> kernel downstream of a smearing NTP server is an interesting one.
> My preferred answer is "Don't do that."
>
>
> If that translates to "don't smear ntp" I could not agree more.
> Smearing is catering to those who won't clean up their act,
> causing trouble for those who try to do the right thing.
>

I view smeared leap seconds as a wholesale repudiation of the whole concept
of leap seconds. They are too hard to get right, despite decades of trying,
so screw those time guys, we'll paper over their horrible design...

Of course, I came to this conclusion before smeared leapseconds trying to
get systems to behave perfectly. The old "but it's only a second" refrain
when I filed bug reports and talked to management showed nobody cared.

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

Re: [LEAPSECS] Windows Server 2019

[Martin Burnicki]

Nero Imhard wrote:
> scs...@eskimo.com schreef op 2018-07-20 11:35:
> 
>> The question of what happens if you try to run a leapsec-aware
>> kernel downstream of a smearing NTP server is an interesting one.
>> My preferred answer is "Don't do that."
>  
> If that translates to "don't smear ntp" I could not agree more.
> Smearing is catering to those who won't clean up their act,
> causing trouble for those who try to do the right thing.

Please don't blame ntpd for smearing leap seconds.

The leap second is inserted/handled by the kernel, and that's basically
the way it should be.

However, this is often done in a way that applications may become
confused if the system time is simply stepped back by 1 s.

If you used any other time synchronization software which just passes a
leap second announcement to the kernel then the applications will have
the same problems.

Leap second smearing by an NTP server is just an optional way to avoid
these problems because there's no better way to get around it.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

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
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

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

Re: [LEAPSECS] Windows Server 2019

[Martin Burnicki]

Steve Summit wrote:
> Steve Allen wrote:
>>> as seen on slashdot and more, Windows Server 2019 will support
>>> leap seconds.
> 
> I don't often say this, but: Good for Microsoft.
> 
> Despite the several, well known, significant difficulties, I have
> been on a quixotic on-and-off quest to implement "proper" leap
> second handling for Linux.  (As some will recall, on 2016-12-31
> I managed to post a message to this list at 23:59:60 UTC, with a
> Date: line to prove it.)  If anyone feels shamed into action by
> Microsoft's announcement, and wants to try things out under Linux,
> please feel free to pester me into finally publishing that work
> publicly. :-)
> 
> Stephen Colebourne wrote:
>> ...it needs to be possible for any of these setups to be valid
>> (and maybe more options too):
>>
>> - network clock returns UTC, OS handles UTC, application/framework handles 
>> UTC
>> - network clock returns UTC, OS handles UTC, application/framework smears
>> - network clock returns UTC, OS smears, application/framework unaware
> 
> The modified Linux kernel that I have implements these sorts of
> choices via clock_gettime().  The new clkid value CLOCK_UTC gives
> you true UTC, the new clkid value CLOCK_SMEARED gives you smeared
> time, and the existing clkid value CLOCK_REALTIME currently gives
> you whatever we used to put up with (basically a repeated second),
> but could/would be changed to return the same as CLOCK_SMEARED
> once it was confidently proved to be working.

This sounds like a real step forward to flexible leap second handling by
the kernel, and IMO it would be good if this could make it into the kernel.

> The question of what happens if you try to run a leapsec-aware
> kernel downstream of a smearing NTP server is an interesting one.
> My preferred answer is "Don't do that."  The failure modes if you
> did wouldn't be *too* bad, but "proper" handling of CLOCK_UTC in
> that case would of course require an unsmearing algorithm, which
> I for one am not interested in writing.

I think the admins had to take care that they use a reliable clock
source. If you install a GPS receiver which outputs faulty time (e.g. to
GPS week number rollovers) or output faulty leap second warnings then
you may end up with a wrong system time. Similarly, if you chose a
smearing NTP server even though you don't want the incoming time to be
smeared.

>> Getting the smear off the network and into the OS will undoubtably
>> be useful in some use cases, but they are not the only use cases.
> 
> Indeed.

However, this had to be made public so that software developers become
aware of these features and what the differences are, so they can call
clock_gettime() with the clock ID that is best suited for their
application.

If they are not aware of the differences in the clock models then their
application will probably not work as expected anyway.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

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
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

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

Re: [LEAPSECS] Windows Server 2019

[Nero Imhard]

scs...@eskimo.com schreef op 2018-07-20 11:35:

> The question of what happens if you try to run a leapsec-aware
> kernel downstream of a smearing NTP server is an interesting one.
> My preferred answer is "Don't do that."

If that translates to "don't smear ntp" I could not agree more. 
Smearing is catering to those who won't clean up their act, 
causing trouble for those who try to do the right thing. 

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

Re: [LEAPSECS] Windows Server 2019

[Steve Summit]

Steve Allen wrote:
>> as seen on slashdot and more, Windows Server 2019 will support
>> leap seconds.

I don't often say this, but: Good for Microsoft.

Despite the several, well known, significant difficulties, I have
been on a quixotic on-and-off quest to implement "proper" leap
second handling for Linux.  (As some will recall, on 2016-12-31
I managed to post a message to this list at 23:59:60 UTC, with a
Date: line to prove it.)  If anyone feels shamed into action by
Microsoft's announcement, and wants to try things out under Linux,
please feel free to pester me into finally publishing that work
publicly. :-)

Stephen Colebourne wrote:
> ...it needs to be possible for any of these setups to be valid
> (and maybe more options too):
>
> - network clock returns UTC, OS handles UTC, application/framework handles UTC
> - network clock returns UTC, OS handles UTC, application/framework smears
> - network clock returns UTC, OS smears, application/framework unaware

The modified Linux kernel that I have implements these sorts of
choices via clock_gettime().  The new clkid value CLOCK_UTC gives
you true UTC, the new clkid value CLOCK_SMEARED gives you smeared
time, and the existing clkid value CLOCK_REALTIME currently gives
you whatever we used to put up with (basically a repeated second),
but could/would be changed to return the same as CLOCK_SMEARED
once it was confidently proved to be working.

The question of what happens if you try to run a leapsec-aware
kernel downstream of a smearing NTP server is an interesting one.
My preferred answer is "Don't do that."  The failure modes if you
did wouldn't be *too* bad, but "proper" handling of CLOCK_UTC in
that case would of course require an unsmearing algorithm, which
I for one am not interested in writing.

> Getting the smear off the network and into the OS will undoubtably
> be useful in some use cases, but they are not the only use cases.

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

Re: [LEAPSECS] Windows Server 2019

[Steven Sommars]

Some direct links for the Matsakis, et al paper.
USNO:
https://tycho.usno.navy.mil/papers/ts-2018/Traceability-of-Time-Signals.pdf
NIST: https://tf.nist.gov/general/pdf/2941.pdf



On Wed, Jul 18, 2018 at 11:27 PM, Steve Allen  wrote:

> On Thu 2018-07-19T04:14:12+0100 Stephen Colebourne hath writ:
> > "In addition, there is no standard method for applying this frequency
> > adjustment, so that different implementations may disagree among
> > themselves in addition to the time error with respect to UTC."
>
> That quote is not from Microsoft, but rather from the
> ION paper by Matsakis, Levine, and Lombardi
> That can be got by ION members, or from USNO if their
> webserver recovers, or from researchgate if you can
> tolerate the javascript that will try to execute
> https://www.researchgate.net/publication/323600621_Metrological_and_legal_
> traceability_of_time_signals
>
> Microsoft seems to be documenting a new mode of OS configuration which
> actually does count the second named "60", and specifically in order
> that Microsoft systems can say they conform to MiFID II and other
> regulatory agencies that demand conformance with UTC as defined.
> Otherwise the old default configuration will have a second that lasts
> 2000 millis.
>
> --
> Steve Allen  WGS-84 (GPS)
> UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat
> +36.99855
> 1156 High Street   Voice: +1 831 459 3046 Lng
> -122.06015
> Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Windows Server 2019

[Brooks Harris]

On 2018-07-19 07:06 AM, Hal Murray wrote:

I think it does matter. I, for one, would be interested in credible
explanation of the "smears", and, if these have been coordinated, by  whom,
and how.

Here is Google's documentation:
   https://developers.google.com/time/smear

We encourage anyone smearing leap seconds to use a 24-hour linear smear from
noon to noon UTC.

We plan to use this smear for all future leap seconds. Amazon uses this smear
in AWS.



What I'm hoping will appear is a document that can be treated as a standard
(preferably at a formal standards body of some kind).

I don't think you will get more than the above.

The fundamental problem is that POSIX doesn't admit to the existence of leap
seconds.

Smearing on NTP is a hack.  It just happens to be a very useful hack.  It
covers many many systems.

People are unlikely to work on a document for something that can be described
in one line of text, especially when all the people who care have already
agreed.  The whole point of smearing is so that most users don't have to do
anything.  Why do you need documentation for that?
So there's a specification that all systems use and so is traceable to 
national time servers?


https://www.researchgate.net/publication/323600621_Metrological_and_legal_traceability_of_time_signals









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

Re: [LEAPSECS] Windows Server 2019

[Hal Murray]

> I think it does matter. I, for one, would be interested in credible
> explanation of the "smears", and, if these have been coordinated, by  whom,
> and how. 

Here is Google's documentation:
  https://developers.google.com/time/smear

We encourage anyone smearing leap seconds to use a 24-hour linear smear from 
noon to noon UTC.

We plan to use this smear for all future leap seconds. Amazon uses this smear 
in AWS.


> What I'm hoping will appear is a document that can be treated as a standard
> (preferably at a formal standards body of some kind). 

I don't think you will get more than the above.

The fundamental problem is that POSIX doesn't admit to the existence of leap 
seconds.

Smearing on NTP is a hack.  It just happens to be a very useful hack.  It 
covers many many systems.

People are unlikely to work on a document for something that can be described 
in one line of text, especially when all the people who care have already 
agreed.  The whole point of smearing is so that most users don't have to do 
anything.  Why do you need documentation for that?




-- 
These are my opinions.  I hate spam.



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

Re: [LEAPSECS] Windows Server 2019

[Martin Burnicki]

Stephen Colebourne wrote:
> On 19 July 2018 at 11:24, Martin Burnicki  wrote:
>> As far as I know, UTC-SLS is done locally on a client, and since it's
>> implemented in a Java runtime it is only "seen" by Java applications.
>>
>> This means if you get timestamps in Java and non-Java applications on
>> the same machine then they may be off by up to 1000 s at the end of the
>> UTC-SLS smear interval, isn't it?
>>
>> If you have a smearing NTP server then all clients of the same server
>> will have the same smeared time, which is of course off UTC during the
>> smear interval, but at least all Java and non-Java applications on a
>> particular machine will see the same system time.
>>
>> I think it depends on the requirements of the applications which way is
>> to be preferred.
> 
> True, but the point is that we have already, and are likely to have
> more in the future, boundaries that want different representations.
> Specifically, cases where a low level system understands and models
> leap seconds, but a high level system does not want to (for various
> perfectly good reasons). Once it is accepted that there are two
> representations, and both are valid, there is a need to convert
> between the two.
> 
> For the plan to work fully it needs to be possible for any of these
> setups to be valid (and maybe more options too):
> 
> - network clock returns UTC, OS handles UTC, application/framework handles UTC
> - network clock returns UTC, OS handles UTC, application/framework smears
> - network clock returns UTC, OS smears, application/framework unaware
> - network clock smears, OS unaware, application/framework unaware
> 
> Getting the smear off the network and into the OS will undoubtably be
> useful in some use cases, but they are not the only use cases.

I fully agree, and that's what I meant by "it depends on the
requirements of the applications". ;-)

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

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
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

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

Re: [LEAPSECS] Windows Server 2019

[Stephen Colebourne]

On 19 July 2018 at 11:24, Martin Burnicki  wrote:
> As far as I know, UTC-SLS is done locally on a client, and since it's
> implemented in a Java runtime it is only "seen" by Java applications.
>
> This means if you get timestamps in Java and non-Java applications on
> the same machine then they may be off by up to 1000 s at the end of the
> UTC-SLS smear interval, isn't it?
>
> If you have a smearing NTP server then all clients of the same server
> will have the same smeared time, which is of course off UTC during the
> smear interval, but at least all Java and non-Java applications on a
> particular machine will see the same system time.
>
> I think it depends on the requirements of the applications which way is
> to be preferred.

True, but the point is that we have already, and are likely to have
more in the future, boundaries that want different representations.
Specifically, cases where a low level system understands and models
leap seconds, but a high level system does not want to (for various
perfectly good reasons). Once it is accepted that there are two
representations, and both are valid, there is a need to convert
between the two.

For the plan to work fully it needs to be possible for any of these
setups to be valid (and maybe more options too):

- network clock returns UTC, OS handles UTC, application/framework handles UTC
- network clock returns UTC, OS handles UTC, application/framework smears
- network clock returns UTC, OS smears, application/framework unaware
- network clock smears, OS unaware, application/framework unaware

Getting the smear off the network and into the OS will undoubtably be
useful in some use cases, but they are not the only use cases.

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

Re: [LEAPSECS] Windows Server 2019

[Martin Burnicki]

Stephen Colebourne wrote:
> On 19 July 2018 at 09:44, Hal Murray  wrote:
>>> As a IT professional, and author of date/time libraries, I cannot stress
>>> enough how much a standard is needed here. We are going to have both UTC
>>> (with leap seconds) and systems that smear ("UT-Smear") and there is
>>> currently no agreed way to define the latter or move from one to the other. 
>>> I
>>> strongly suspect that Microsoft is going to have to define a smear in order
>>> to meet old APIs, but this really should be something well defined by a
>>> standard, not invented by a company.
>>
>> I think there is a semi-standard emerging for NTP.
>>
>> There are several big companies running smearing servers.  I think they have
>> all agreed to use the same parameters.  I think that's linear over 24 hours,
>> 12 before the leap and 12 after.  I'll dig deeper if it matters.
> 
> What I'm hoping will appear is a document that can be treated as a
> standard (preferably at a formal standards body of some kind).
> 
> With the changes to Java, I used UTC-SLS (linear over 1000secs). But I
> deliberately left open the possibility for Java to adopt any future
> standard for smearing that emerged.
> https://docs.oracle.com/javase/10/docs/api/java/time/Instant.html

As far as I know, UTC-SLS is done locally on a client, and since it's
implemented in a Java runtime it is only "seen" by Java applications.

This means if you get timestamps in Java and non-Java applications on
the same machine then they may be off by up to 1000 s at the end of the
UTC-SLS smear interval, isn't it?

If you have a smearing NTP server then all clients of the same server
will have the same smeared time, which is of course off UTC during the
smear interval, but at least all Java and non-Java applications on a
particular machine will see the same system time.

I think it depends on the requirements of the applications which way is
to be preferred.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

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
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

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

Re: [LEAPSECS] Windows Server 2019

[Stephen Colebourne]

On 19 July 2018 at 09:44, Hal Murray  wrote:
>> As a IT professional, and author of date/time libraries, I cannot stress
>> enough how much a standard is needed here. We are going to have both UTC
>> (with leap seconds) and systems that smear ("UT-Smear") and there is
>> currently no agreed way to define the latter or move from one to the other. I
>> strongly suspect that Microsoft is going to have to define a smear in order
>> to meet old APIs, but this really should be something well defined by a
>> standard, not invented by a company.
>
> I think there is a semi-standard emerging for NTP.
>
> There are several big companies running smearing servers.  I think they have
> all agreed to use the same parameters.  I think that's linear over 24 hours,
> 12 before the leap and 12 after.  I'll dig deeper if it matters.

What I'm hoping will appear is a document that can be treated as a
standard (preferably at a formal standards body of some kind).

With the changes to Java, I used UTC-SLS (linear over 1000secs). But I
deliberately left open the possibility for Java to adopt any future
standard for smearing that emerged.
https://docs.oracle.com/javase/10/docs/api/java/time/Instant.html

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

Re: [LEAPSECS] Windows Server 2019

[Brooks Harris]

On 2018-07-19 04:44 AM, Hal Murray wrote:

As a IT professional, and author of date/time libraries, I cannot stress
enough how much a standard is needed here. We are going to have both UTC
(with leap seconds) and systems that smear ("UT-Smear") and there is
currently no agreed way to define the latter or move from one to the other. I
strongly suspect that Microsoft is going to have to define a smear in order
to meet old APIs, but this really should be something well defined by a
standard, not invented by a company.

I think there is a semi-standard emerging for NTP.

There are several big companies running smearing servers.  I think they have
all agreed to use the same parameters.  I think that's linear over 24 hours,
12 before the leap and 12 after.  I'll dig deeper if it matters.

I think it does matter. I, for one, would be interested in credible 
explanation of the "smears", and, if these have been coordinated, by 
whom, and how.

-Brooks


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

Re: [LEAPSECS] Windows Server 2019

[Hal Murray]

> As a IT professional, and author of date/time libraries, I cannot stress
> enough how much a standard is needed here. We are going to have both UTC
> (with leap seconds) and systems that smear ("UT-Smear") and there is
> currently no agreed way to define the latter or move from one to the other. I
> strongly suspect that Microsoft is going to have to define a smear in order
> to meet old APIs, but this really should be something well defined by a
> standard, not invented by a company. 

I think there is a semi-standard emerging for NTP.

There are several big companies running smearing servers.  I think they have 
all agreed to use the same parameters.  I think that's linear over 24 hours, 
12 before the leap and 12 after.  I'll dig deeper if it matters.


-- 
These are my opinions.  I hate spam.



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

Re: [LEAPSECS] Windows Server 2019

[Martin Burnicki]

Steve Allen wrote:
> On Thu 2018-07-19T04:14:12+0100 Stephen Colebourne hath writ:
>> "In addition, there is no standard method for applying this frequency
>> adjustment, so that different implementations may disagree among
>> themselves in addition to the time error with respect to UTC."
> 
> That quote is not from Microsoft, but rather from the
> ION paper by Matsakis, Levine, and Lombardi
> That can be got by ION members, or from USNO if their
> webserver recovers, or from researchgate if you can
> tolerate the javascript that will try to execute
> https://www.researchgate.net/publication/323600621_Metrological_and_legal_traceability_of_time_signals

Thanks for the pointers.

> Microsoft seems to be documenting a new mode of OS configuration which
> actually does count the second named "60", and specifically in order
> that Microsoft systems can say they conform to MiFID II and other
> regulatory agencies that demand conformance with UTC as defined.
> Otherwise the old default configuration will have a second that lasts
> 2000 millis.

I wonder what you mean by "old configuration". The latest leap second
tests I made with Windows and w32time running showed that there was no
leap second handling at all.

This means whenever w32time polled an NTP server the next time after a
leap second (which could be up to 1 week, with a 1 week polling interval
for machines that are not members oof an Active Directory)) it simply
observed a time offset > 1 s, and adjusted the Windows time accordingly.

Slewing the Windows system time over 2 seconds is a feature of the ntpd
port for Windows (and the Meinberg time adjustment service for their PCI
cards), which implements this slewing as a workaround for windows.

If Windows starts to provide an API to handle leap seconds then these
programs should use the API, if it is available, and skip the workaround.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burni...@meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

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
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

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

Re: [LEAPSECS] Windows Server 2019

[Steve Allen]

On Thu 2018-07-19T04:14:12+0100 Stephen Colebourne hath writ:
> "In addition, there is no standard method for applying this frequency
> adjustment, so that different implementations may disagree among
> themselves in addition to the time error with respect to UTC."

That quote is not from Microsoft, but rather from the
ION paper by Matsakis, Levine, and Lombardi
That can be got by ION members, or from USNO if their
webserver recovers, or from researchgate if you can
tolerate the javascript that will try to execute
https://www.researchgate.net/publication/323600621_Metrological_and_legal_traceability_of_time_signals

Microsoft seems to be documenting a new mode of OS configuration which
actually does count the second named "60", and specifically in order
that Microsoft systems can say they conform to MiFID II and other
regulatory agencies that demand conformance with UTC as defined.
Otherwise the old default configuration will have a second that lasts
2000 millis.

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

Re: [LEAPSECS] Windows Server 2019

[Stephen Colebourne]

"In addition, there is no standard method for applying this frequency
adjustment, so that different implementations may disagree among
themselves in addition to the time error with respect to UTC."

As a IT professional, and author of date/time libraries, I cannot
stress enough how much a standard is needed here. We are going to have
both UTC (with leap seconds) and systems that smear ("UT-Smear") and
there is currently no agreed way to define the latter or move from one
to the other. I strongly suspect that Microsoft is going to have to
define a smear in order to meet old APIs, but this really should be
something well defined by a standard, not invented by a company.

Stephen



On 18 July 2018 at 23:07, Steve Allen  wrote:
> as seen on slashdot and more, Windows Server 2019 will support leap seconds.
> https://blogs.technet.microsoft.com/networking/2018/07/18/top10-ws2019-hatime/
> That blog entry points at several MSword docs for admins and devs, and
> https://aka.ms/Dev-LeapSecond
> finishes with this interesting warning:
>
> Known issues:
> Some frameworks are known to calculate time incorrectly after a leap
> second occurs.  For example, the .NET Framework uses its own internal
> logic to determine what time it is.  Its logic does not account for
> leap seconds.  So after a leap second is introduced to the Operating
> System the output of "System.DateTime.Now.ToString()" will be ahead by
> one second of the local system time.  (We are working with the .NET
> framework team on this.)
>
> In combination with the many steps that it takes to configure Windows
> this sounds like there will be some really interesting results.
>
> --
> Steve Allen  WGS-84 (GPS)
> UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
> 1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
> Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] Windows Server 2019

[Steve Allen]

as seen on slashdot and more, Windows Server 2019 will support leap seconds.
https://blogs.technet.microsoft.com/networking/2018/07/18/top10-ws2019-hatime/
That blog entry points at several MSword docs for admins and devs, and
https://aka.ms/Dev-LeapSecond
finishes with this interesting warning:

Known issues:
Some frameworks are known to calculate time incorrectly after a leap
second occurs.  For example, the .NET Framework uses its own internal
logic to determine what time it is.  Its logic does not account for
leap seconds.  So after a leap second is introduced to the Operating
System the output of "System.DateTime.Now.ToString()" will be ahead by
one second of the local system time.  (We are working with the .NET
framework team on this.)

In combination with the many steps that it takes to configure Windows
this sounds like there will be some really interesting results.

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