Re: [LEAPSECS] UT1 offset

[Warner Losh]

On Wed, Dec 27, 2023 at 6:04 AM Jim Lux  wrote:

> Let’s back of the envelope the impact of a 1 second error in a longitude
> sight.
> The Sun moves 360 degrees in 86400 seconds. A one second error is then
> about 0.004 degree.  But in equatorial km, let’s assume 40,000 km
> circumference, so 40,000 km in 86,400 seconds (yeah, it’s actually less,
> sidereal day and all that). Or an error of about 1/2 km.
>
> For the vast majority of boat driving purposes, this is sufficiently
> accurate - you need to get to within visual range of the coast, so you can
> get into the desired port.
>

This does mean, though, that there will need to be a notion of DUT1 to a
second in the future for people wishing to navigate like this. Right now
that term is 0. That implies a 100ms DUT1 error gives a navigation error of
about 50m, which is likely why it's never been broadcast better than that,
because then other errors in measurement will become a factor and all the
high-precision navigation is done by GPS or similar. The demand side for
higher precision is low, even if for some applications its need is high.


> For flying a plane by celestial navigation, you might care more, because
> the plane is flying faster than a boat moves.
>

For flying a plane, though, you have a series of different flight modes
that require either clear skies so you can do the same as above "steer
around the big mountain" or you can rely on your instruments to be exactly
where you need to be because you can't see and/or there's too much traffic.
The old VFR vs IFR divide. You care more in a plane, but there's several
layers that you can use. to mitigate the errors in the 'simpler' ones.
Still, even 50m can be a lot if you are flying over a narrow mountain pass
in a plane that can't just fly super-high above it...

Warner


> > On Dec 26, 2023, at 7:10 AM, Gary E. Miller  wrote:
> >
> > Yo Hal!
> >
> >> On Mon, 25 Dec 2023 00:25:07 -0800
> >> Hal Murray  wrote:
> >>
> >> Who uses DUT1 via radio?  Who will be using it 50 years from now?
> >>
> >> Is it needed for anything other than navigation and astronomy?
> >
> > I just asked my brother that did a lot of transoceanic navigation
> > by sextant.  He did not even know what UT1 is.  He certainly would
> > not know what to do with DUTs.
> >
> > RGDS
> > GARY
> >
> ---
> > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> >g...@rellim.com  Tel:+1 541 382 8588
> >
> >Veritas liberabit vos. -- Quid est veritas?
> >"If you can't measure it, you can't improve it." - Lord Kelvin
> > ___
> > 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] prep for WRC 23

[Warner Losh]

On Sat, Dec 23, 2023, 12:02 PM Poul-Henning Kamp  wrote:

> Michael Deckers via LEAPSECS writes:
>
> >> My Tl;dr version of the resolution is:
> >
> >> . Please keep DUT1 less than 100 seconds.
>
> >   k) that the maximum value for the difference between UT1 and UTC
> >   should be no less
> >   than 100 seconds, taking into account the constraints of the
> >   technological systems
> >   expected to be used to disseminate this value,  "
>
> You're right, I misread that.
>
> They /really/ dont want to ever see a leapsecond or leapminute, do they ?
>

I'd love for them to have 6 digits for the offset..  .99.  Iirc prior
discussions that puts us 6000 years or so in the future. 6000 years ago we
were just inventing writing, just domesticated plants and food animals and
were just starting to forge metal on a vast scale...

100s gives us until at least 2150 in all likelihood (exactly date might be
2100 or 2200 though).

So year... safely dead before any of these dates...

Warner

Ps all my examples are +/- maybe 1000 years and you can rightly quibble
with them... but it wouldn't change the main point. :).

-- 
> 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] Inside GNSS published an update of my CGSIC talk

[Warner Losh]

On Mon, Mar 20, 2023 at 2:46 PM Richard B Langley  wrote:

> "I'd also note that if GLASNOS can't be fixed by 2035 ..."
>
> Interesting slip of the tongue.
>
> Glasnos[t] was taken to mean increased openness and transparency in
> government institutions and activities in the Soviet Union (USSR). Glasnost
> reflected a commitment of the Gorbachev administration to allowing Soviet
> citizens to discuss publicly the problems of their system and potential
> solutions.
>
> Of course, GLONASS was meant. But we are reminded that in today's Russia,
> openness and transparency, not to mention freedom of speech, is a thing of
> the past.
>

ah, yes. I lisned to too many Gorby speeches back in the day, eh?

Thanks for the amusing correction...

Warner


> Sorry for being a bit off topic.
>
> -- Richard Langley
>
>
> -
> | Richard B. LangleyE-mail: l...@unb.ca
>|
> | Geodetic Research Laboratory  Web: http://gge.unb.ca
>   |
> | Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142
>  |
> | University of New Brunswick
>  |
> | Fredericton, N.B., Canada  E3B 5A3
>   |
> |Fredericton?  Where's that?  See: http://www.fredericton.ca/
>|
>
> -----
>
> 
> From: LEAPSECS  on behalf of Warner Losh
> 
> Sent: March 20, 2023 5:18 PM
> To: Leap Second Discussion List
> Subject: Re: [LEAPSECS] Inside GNSS published an update of my CGSIC talk
>
> ✉External message: Use caution.
>
>
> On Mon, Mar 20, 2023 at 1:37 PM Michael Deckers via LEAPSECS <
> leapsecs@leapsecond.com<mailto:leapsecs@leapsecond.com>> wrote:
>
> On 2023-03-20 07:54, Jürgen Appel via LEAPSECS wrote:
>
>
> > In your Conclusion, you say "the CGPM resolution also stipulates that no
> > change to current practices can occur before 2035."
> >
> > This is not how I read read the CGPM document on the BIPM website:
> > "The General Conference on Weights and Measures (CGPM), at its 27th
> meeting
> > [...] decides that the maximum value for the difference (UT1-UTC) will be
> > increased in, or before, 2035,"
> >
> > So in case the negative leap seconds become a real threat, according to
> my
> > interpretation is is an option to increase the tolerance value earlier
> than
> > 2035 to avoid trying out negative leap seconds a last and first time.
> >
> > Can someone confirm my view?
>
>
>
>  You read correctly, the French (official) version has
>
> ..."décide que la valeur maximale pour la différence
> (UT1 - UTC) sera augmentée au plus tard en 2035,"
>
>  which means "in 2035 at the latest".
>
>  Note also that the definition of UTC as approved by the
>  CGPM never mentions _any_ explict bound for |UT1 - UTC|; it
>  only says that (TAI - UTC) is an integral multiple of 1 s
>  as determined by the IERS. It is the IERS who state that
>
> "Coordinated Universal Time (UTC) a measure of time
>  that conforms, within approximately 1 s, to the mean
>  diurnal motion of the Sun and serves as the basis of
>  all civil timekeeping."
>
>  quoting the IAU "Nomenclature for Fundamental Astronomy (NFA)"
>  found at http://syrte.obspm.fr/iauWGnfa/NFA Glossary.html.
>
>  This seems to be lenient enough to allow for not scheduling
>  a negative leap second even in the case that the difference
>  (UT1 - UTC) should go a bit below -1 s before 2035.
>
> So is "approximately" here to be read in the "astronomer" sense that it's
> that, give or take an order of magnitude, or some more close reading :) For
> astronomy, often times things that are approximately the same can vary
> quite a bit, and that's fine.
>
> More seriously even 2s is approximately 1s if there's some kind of effort
> to keep it from freewheeling to 10s, 100s, or 1000s of seconds.
>
> For example, the Gregorian calendar approximates the year over the
> centuries, but any given year can deviate up to 2 days (worst case) from
> the idealized solstice dates.
>
> I'd also note that if GLASNOS can't be fixed by 2035, then a fallback to a
> schedule of leap seconds to keep the answer approximately 1s in the long
> haul could also be on the table. Having it be scheduled, rather than
> observational, has advantages: everybody gets leap years right, and will
> for the next few hundred years (

Re: [LEAPSECS] smear

[Warner Losh]

On Mon, Mar 20, 2023 at 2:10 PM Steve Allen  wrote:

> On Mon 2023-03-20T19:36:51+ Michael Deckers via LEAPSECS hath writ:
> > � This seems to be lenient enough to allow for not scheduling
> > � a negative leap second even in the case that the difference
> > � (UT1 - UTC) should go a bit below -1 s before 2035.
>
> And today in the NTP working group mail list we see that the
> big guns expect to force the issue because
>
> > From: Doug Arnold 
> > Subject: Re: [Ntp] draft-ntp-ntpv5-requirements update for IETF 116
> >
> > Re leap smearing:
> >
> > Operators from multiple data centers tell me that they intend to
> > smear leap seconds.  When I pointed out the pitfalls they were
> > undeterred.  I have come to understand that leap smearing is viewed as
> > less problematic than trying to fix leap second handing in distributed
> > database software.
>
> they have taken the stance that if leap seconds do not go away then
> they will smear.
>
> This is like Eucla Australia setting their clocks the way they
> please and daring the state government to do something about it.
>

Pragmatically, it's a lot easier to smear 3 or 4 more times than to fix all
the code that leap seconds break. Smearing is an ugly hack that allows
broken code to get things less wrong than powering through a leap second
and the result +1s or -1s errors. The trains must run on time, UTC be
damned, eh?

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

Re: [LEAPSECS] Inside GNSS published an update of my CGSIC talk

[Warner Losh]

On Mon, Mar 20, 2023 at 1:37 PM Michael Deckers via LEAPSECS <
leapsecs@leapsecond.com> wrote:

>
> On 2023-03-20 07:54, Jürgen Appel via LEAPSECS wrote:
>
>
> > In your Conclusion, you say "the CGPM resolution also stipulates that no
> > change to current practices can occur before 2035."
> >
> > This is not how I read read the CGPM document on the BIPM website:
> > "The General Conference on Weights and Measures (CGPM), at its 27th
> meeting
> > [...] decides that the maximum value for the difference (UT1-UTC) will be
> > increased in, or before, 2035,"
> >
> > So in case the negative leap seconds become a real threat, according to
> my
> > interpretation is is an option to increase the tolerance value earlier
> than
> > 2035 to avoid trying out negative leap seconds a last and first time.
> >
> > Can someone confirm my view?
>
>
>
>  You read correctly, the French (official) version has
>
> ..."décide que la valeur maximale pour la différence
> (UT1 - UTC) sera augmentée au plus tard en 2035,"
>
>  which means "in 2035 at the latest".
>
>  Note also that the definition of UTC as approved by the
>  CGPM never mentions _any_ explict bound for |UT1 - UTC|; it
>  only says that (TAI - UTC) is an integral multiple of 1 s
>  as determined by the IERS. It is the IERS who state that
>
> "Coordinated Universal Time (UTC) a measure of time
>  that conforms, within approximately 1 s, to the mean
>  diurnal motion of the Sun and serves as the basis of
>  all civil timekeeping."
>
>  quoting the IAU "Nomenclature for Fundamental Astronomy (NFA)"
>  found at http://syrte.obspm.fr/iauWGnfa/NFA Glossary.html.
>
>  This seems to be lenient enough to allow for not scheduling
>  a negative leap second even in the case that the difference
>  (UT1 - UTC) should go a bit below -1 s before 2035.
>

So is "approximately" here to be read in the "astronomer" sense that it's
that, give or take an order of magnitude, or some more close reading :) For
astronomy, often times things that are approximately the same can vary
quite a bit, and that's fine.

More seriously even 2s is approximately 1s if there's some kind of effort
to keep it from freewheeling to 10s, 100s, or 1000s of seconds.

For example, the Gregorian calendar approximates the year over the
centuries, but any given year can deviate up to 2 days (worst case) from
the idealized solstice dates.

I'd also note that if GLASNOS can't be fixed by 2035, then a fallback to a
schedule of leap seconds to keep the answer approximately 1s in the long
haul could also be on the table. Having it be scheduled, rather than
observational, has advantages: everybody gets leap years right, and will
for the next few hundred years (maybe with a glitch at 2100 and 2400). A
much lower percentage get leap seconds right because leap second knowledge
propagates imperfectly, even after all these years of trying (my first
anti-leapsecond screeds date back maybe 20 years). So my first choice is
always 'none, cope with shifting civil time on the scale of centuries' but
my second choice is 'schedule for the long-term average and don't worry
about going > 1s' .

Warner


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

Re: [LEAPSECS] leap minute or hour

[Warner Losh]

On Fri, Nov 18, 2022 at 9:34 PM Zefram via LEAPSECS 
wrote:

> Eric Scace wrote:
> >   This is much easier to deal with than writing code for future leap
> >   second changes on dates yet to be established/promulgated.
>
> It does ameliorate the problem of distribution of the leap schedule,
> but that benefit is not at all specific to the leap minute/hour system.
> The distribution is made easier by having a twenty year lead time on
> scheduling, and this feature of the system is not at all dependent on
> the nature of the schedule.  We have previously noted that there would be
> value in a multi-year lead time in scheduling leap seconds of the current
> form (individual leap seconds, making an effort to minimise |UT1-UTC|).
>
> If the intention is for UTC to track UT1 over the long term, even if it
> has a much greater tracking bound than previously, then we need to be
> prepared to handle leaps.  In this context, there is a major disadvantage
> to the leap minute/hour proposals, and even to just embargoing leap
> seconds for a century: they would result in needing to handle a leap
> when no one has experienced a leap for decades.  What are the chances
> of getting that right?  If we're going to have leaps at all, it seems
> better to keep leaps reasonably frequent, and even to insert gratuitous
> leaps to make them more frequent than at present (see the "leap second
> every month" proposal).  This way we would have a fair chance of making
> the leap-handling systems actually work.
>
> The CGPM resolution is, of course, taking the opposite approach,
> reasoning that leap seconds are just too hard to get right.  This seems
> a poor justification for abolishing a mechanism that's good for
> some applications, but if taken at face value it's even worse as a
> justification for any mechanism that would have very infrequent leaps.
> Leap seconds every couple of years are hard, true, but leaps once a
> century would be far harder to get right.  As has been previously noted
> in respect of the leap hour proposal, the CGPM resolution really looks
> like an attempt to abolish leaps entirely (which is what its rationale
> really justifies) without actually admitting that that is the aim.
> This is especially so with the proposal being so vague about what it
> intends to happen to UTC after the leapless century.
>
> The resolution has a note about TAI being insufficiently accessible to
> serve the technical purposes that require a completely regular time
> scale.  This seems like the thing to work on.  We ought to be making
> time distribution systems offer both TAI and UTC, with TAI as the more
> fundamental product and UTC explicitly layered on top of it.  That way
> the problems of leap seconds can be confined to those applications that
> actually want the UT1 tracking.  It's a lot of work, but we actually
> need to disseminate two or more time scales anyway, and it's preferable
> to do that in a well-specified way.
>

Alternatively, why does | UTC - UT1 | need to be bounded?  If we let it
accumulate
to an arbitrary level, and distributed UTC - UT1 to anybody that needed it,
then
that would accomplish the same thing that adding leap seconds does now,
without
the approximation that UTC ~ UT1. All applications that care updated to use
this value
could even have a higher level of performance without the need to hope that
the UTC
approximation is 'good enough'. This completely eliminates leap seconds
from timekeeping
while putting the onus on the applications that care to pay the freight
while removing
the leap second tax from the 99.99% of applications that don't care.

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

Re: [LEAPSECS] Alanna Mitchell in NYT

[Warner Losh]

On Mon, Nov 14, 2022 at 10:40 AM Steve Allen  wrote:

> Starting tomorrow the CGPM meets in Paris.
> Resolution D says leap seconds must die.
> CGPM will almost certainly approve that resolution.
>
> https://www.nytimes.com/2022/11/14/science/time-leap-second.html


I'm happy to see this... I talked to Judah 20-odd years ago about this and
he was hopeful then.

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

Re: [LEAPSECS] article for Metrologia

[Warner Losh]

On Sat, Oct 29, 2022, 11:49 AM Joseph Gwinn  wrote:

> General comment:
>
> The POSIX standards which unix and variants follow uses a string time
> format that looks like UTC, but is not, because leap seconds are
> never applied.  This was done precisely because an isolated unix box
> had no access to leap-second information; this was the norm in that
> day, long before networks and GPS.
>
> So, those faulty designers of yore had insufficient clairvoyance
> skills.
>

The problem is time_t can't encode a leap second uniquely, but leap seconds
had been a thing for ~20 years when the first POSIX standards came out. It
was more of a willful choice to disregard them entirely as a simplification
than lack of clairvoyance. At the time it didn't seem important but by the
late 90s the mistake was obvious to anybody who had to deliver a unix
system that pedanticly tracked time through a leapsecond or had to deal
with true UTC timestamps could attest... I found many rants in the early
2000s when I tried to ship my such system for LORAN-C timing system
refresh. It's the poster child in my mind for all the problems that I've
been mentioning that still aren't adequately addressed 20 years later.

Warner

Joe Gwinn
>
> On Sat, 29 Oct 2022 18:16:14 +0200, Steffen Nurpmeso wrote:
> > Warner Losh wrote in
> >  :
> >  |On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso 
> >  |wrote:
> >  |> Steve Allen wrote in
> >  |>  <20221028045813.ga20...@ucolick.org>:
> >  |>|On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
> >  |>|> Levine, Tavella, and Milton have an upcoming article for Metrologia
> >  |>|> on the issue of leap seconds in UTC
> >  |>|>
> >  |>|> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
> >  |>|
> >  |>|sorry, stray character appended to my cut and paste
> >  |>|
> >  |>|<https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5>
> >  |>
> >  |> That "increasing number of applications" all through the document
> >  |> makes me angry really.  I find it astonishing to read that there
> >  |> are digital clocks that cannot display a second 60 and all that.
> >  |> This is just another outcome of the trivialization and
> >  |> superficialication all around.  You need a reliable source of
> >  |> time, use TAI; or distribute the offset of UT1 and UTC
> >  |> permanently, best TAI, too.  so that changes can be detected.
> >
> > I mean yes, it may be that many languages provide a complete set
> > of functions, time spans and whatever is needed to deal with time
> > properly.  I have not really looked, and my C++ is as of pre Y2K,
> > more or less (but completely regarding the library that grew
> > enormously, that much i know).
> >
> > For plain ISO C there is nothing, and when you refer to the
> > "right" zoneinfo, then i cannot deal with this, let alone easily,
> > in a multithreaded environment, etc.
> > This is a miss of ISO C that should have been addressed maybe
> > already in the first real version beyond the labratory where it
> > was created, instead of beating onto Ritchie's nerves for mess.
> >
> >  |If you deal with time in TAI, then you must have a perfect source of
> leap
> >  |seconds due to the de-facto requirement that times be presented in UTC.
> >  |That's the biggest problem with using TAI + the 'right' files. If
> > you don't
> >  |know
> >  |the offset when the system starts, then fixing it later can be hard.
> >  |
> >  |The truth often is that UTC is available, and if you're very lucky, \
> >  |you have
> >  |a source of leap seconds that's in-band and as-reliable as UTC in a
> timely
> >  |manner. If you aren't lucky, then using TAI is a non-starter or
> requires
> >  |several orders of magnitude more effort to setup a distribution system
> of
> >  |it and you're often left with the conversion to UTC problem.
> >
> > Yes.  It was a design fault.  Why should machines be driven with
> > a time scale designed for human life?  Instead a machine time
> > should be distributed with the necessities to derive the (a) human
> > time from it.  But that ship has sailed with the satellites and
> > NTP.  So then a few bits have to be found to include the offset
> > permanently.  This could long have happened.  But changing a human
> > timescale to make badly designed machines happy, or only making
> > bad software happy that unrolls bad code because of missing
> > support in standard libraries.  I would not do this.
> >
> >
> >  |> Distribution of leap second

Re: [LEAPSECS] article for Metrologia

[Warner Losh]

On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso 
wrote:

> Steve Allen wrote in
>  <20221028045813.ga20...@ucolick.org>:
>  |On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
>  |> Levine, Tavella, and Milton have an upcoming article for Metrologia
>  |> on the issue of leap seconds in UTC
>  |>
>  |> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
>  |
>  |sorry, stray character appended to my cut and paste
>  |
>  |https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5
>
> That "increasing number of applications" all through the document
> makes me angry really.  I find it astonishing to read that there
> are digital clocks that cannot display a second 60 and all that.
> This is just another outcome of the trivialization and
> superficialication all around.  You need a reliable source of
> time, use TAI; or distribute the offset of UT1 and UTC
> permanently, best TAI, too.  so that changes can be detected.


If you deal with time in TAI, then you must have a perfect source of leap
seconds due to the de-facto requirement that times be presented in UTC.
That's the biggest problem with using TAI + the 'right' files. If you don't
know
the offset when the system starts, then fixing it later can be hard.

The truth often is that UTC is available, and if you're very lucky, you have
a source of leap seconds that's in-band and as-reliable as UTC in a timely
manner. If you aren't lucky, then using TAI is a non-starter or requires
several orders of magnitude more effort to setup a distribution system of
it and you're often left with the conversion to UTC problem.


> Distribution of leap seconds into time and date applications is
> a problem.  Clock calculations with UNIX epoch are all wrong given
> the current semantics except in the current (leap) era.
> Does this change if leaps are removed in the future.  For the
> past.  We need a reliable clock, which is TAI to me, and we need
> the leap second table in order to generate graceful dates in the
> past.  Here it is usr/share/zoneinfo/leapseconds, and it expires
> 2023-06-28 ... UTC.
>

Yes. Having two time scales is a problem due to the need for perfect
knowledge
of both parts. given the current issues that persist in gaining leap second
knowledge, that makes TAI unreliable.

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

Re: [LEAPSECS] article for Metrologia

[Warner Losh]

On Thu, Oct 27, 2022 at 8:25 PM Steve Allen  wrote:

> Levine, Tavella, and Milton have an upcoming article for Metrologia
> on the issue of leap seconds in UTC
>
> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b



"We are sorry, that page has not been found..."

Is that because I don't have creds, or is this link bad?

Warner


>
> --
> 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   https://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] fb/meta join the leap second haters

[Warner Losh]

On Tue, Jul 26, 2022 at 5:33 PM Poul-Henning Kamp 
wrote:

> So looking at the IERS LOD plot going all the way back it seems to
> me that we have been missing the big signal for about five decades:
>
>
> https://datacenter.iers.org/singlePlot.php?plotname=EOPC04_14_62-NOW_IAU2000A-LOD=224
>
> How did we not notice that earlier ?
>

The whole graph looks like a clear downward cycle. But the peak then lower
peak could be variations
in a noisy process (which LOD clearly is). If you look at the graph w/o the
last 5-10 years, the downward
trend is less pronounced because we don't have the 'lower lows' that the
whole graph seems to
show (I say "seems" to because I always hedge when looking at something
this noisy). But it does seem
like leap seconds are about to get super-duper funky for the next decade if
we don't change how
we cope...

Of course, my views since 2000 are best expressed by Cato the Elder's
speach ending catch phrase:
 "Carthago delenda est" Furthermore, leapseconds must die.

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

Re: [LEAPSECS] podcast from Orolia

[Warner Losh]

"What is a leap second and why don't we want it?"  I wonder where this is
going and if I'll like it more than my leap second rants.

Warner

On Tue, May 3, 2022 at 3:20 PM Steve Allen  wrote:

> Orolia has a 17 minute podcast about leap seconds
>
> https://www.orolia.com/place-and-time-episode-3-the-leap-second-on-trial/
>
> --
> 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   https://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] Fw: IERS Message No. 417: Questionnaire on time metrology, including leap seconds in UTC

[Warner Losh]

Sorry that was supposed to be just to Richard

Having gotten into the survey, I can say it's one of the better surveys
I've seen, though it's a bit lacking in the 'how to implement it' side of
things.

I plan on writing down the results of the debates we've had here and
submitting that, in a form that's greatly reduced in volume and rancor...

Over on the NTP list, it's become clear that there needs to be a universal
format for distributing metadata about time scales so that all use cases
can cope, not just the 'keep time in real time' case that's been a prior
focus. To disseminate time scales, one must have additional information
about them: where they deviate from some standard / benchmark and where
they have disconformities (eg leap seconds) as well as for the span of time
the information is valid over.

Warner

On Thu, Dec 17, 2020 at 11:34 AM Warner Losh  wrote:

> Thanks!
>
> Warner
>
> On Thu, Dec 17, 2020 at 10:57 AM Richard Langley  wrote:
>
>> FYI.
>> -- Richard Langley
>>
>>
>> -
>> | Richard B. LangleyE-mail: l...@unb.ca
>>|
>> | Geodetic Research Laboratory  Web: http://gge.unb.ca
>> |
>> | Dept. of Geodesy and Geomatics EngineeringPhone:+1 506
>> 453-5142   |
>> | University of New Brunswick
>>|
>> | Fredericton, N.B., Canada  E3B 5A3
>>   |
>> |Fredericton?  Where's that?  See: http://www.fredericton.ca/
>>|
>>
>> -
>>
>>
>>
>> 
>> From: central_bur...@iers.org 
>> Sent: December 16, 2020 2:53 AM
>> To: messa...@iers.org
>> Subject: IERS Message No. 417: Questionnaire on time metrology, including
>> leap seconds in UTC
>>
>> ✉External message: Use caution.
>>
>> 
>> IERS Message No. 417   December 16, 2020
>> 
>>
>>
>> Questionnaire on time metrology, including leap seconds in UTC
>>
>>
>> Dear Colleagues,
>>
>> The Consultative Committee for Time and Frequency (CCTF) has prepared a
>> questionnaire concerning many important issues of time metrology, in
>> particular the time difference between UTC and UT1, and is thus of
>> primary importance for IERS. To make sure that the needs and wishes of
>> astro-geodetic community are integrated into the general debate, you are
>> strongly invited to respond to this questionnaire.
>>
>> The four hot topics under debate are:
>>
>> 1. Updating the Roadmap for the redefinition of the second
>> 2. Leap seconds in UTC - building a consensus for a continuous timescale
>> 3. Promoting the mutual benefit of UTC and GNSS
>> 4. Sharing resources to improve international timekeeping
>>
>> Questionnaire: https://www.surveymonkey.com/r/CCTF_Survey_2020
>> Introduction letter:
>> https://www.bipm.org/cc/CCTF/Allowed/22nd-1/
>> Introduction_letter_CCTF_President_Dec_2020.pdf
>> [please note the line wrap in this link]
>>
>> Your answers, opinion and ideas are very important. They will be
>> carefully examined and taken into account by the CCTF in order to
>> provide future guidelines and recommendations. In order to make sure
>> that the needs and wishes of concerned institutional bodies and
>> stakeholder communities are integrated into the general debate, we
>> kindly ask you to answer this questionnaire before January 31, 2021.
>>
>> Noel Dimarcq,
>> President of CCTF
>>
>>
>> 
>> IERS Messages are edited and distributed by the IERS Central Bureau.
>> If not stated otherwise, the IERS is only the distributor of the message
>> and is not responsible for its content.
>> To submit texts for distribution, please write to
>> .
>> To subscribe or unsubscribe, please create an IERS account or modify it:
>> https://www.iers.org/Login/Login/EN/login_node.html
>> or write to .
>> Archives: http://www.iers.org/Messages
>> 
>>
>> ___
>> 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] LOD reaches 0 s/d

[Warner Losh]

On Thu, Nov 12, 2020 at 5:24 PM jimlux  wrote:

> On 11/12/20 3:45 PM, Poul-Henning Kamp wrote:
> > 
> >
> >>  predicts that d(UT2)/d(TAI) = 1 after 2021-11-13, ie
> >>  the rates of UTT2 and TAI are expected to agree for the
> >>  next year. This has never happened since 1961. We may
> >>  not need to abolish leap seconds for quite a while.
> >
> > Unless of course we get close enough to a negative one, that people
> > are *really* going to freak out.
> >
> > Hands in the air:  Who here besides Warner and me has ever tried to
> > test handling of negative leap-seconds ?
> >
>
> not exactly leap seconds, but I had a system that ingested time from two
> sources that were nominally synced, and one slipped behind -  it was a
> gruesome disaster. Time going backwards creates ALL sorts of problems
> with log files and locking schemes and telemetry decoding/plotting that
> assume that time is monotonically increasing. (we leave, aside, the
> whole daylight time issue - that's a "print formatting of time values"
> thing.
>
>
> It fills me with great trepidation if clock time were ever to go
> backwards.  I think what would happen is that people would hack it and
> have it sort of run slowly over some seconds, while maintaining
> monotonicity.  And then create tiger teams to fix it when someone else
> did it differently, and your financial system ingested transactions that
> appeared to end before they started.
>

Well, every positive leap second is time going backwards...  At least with
a negative leap second time just skips a beat...

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

Re: [LEAPSECS] LOD reaches 0 s/d

[Warner Losh]

On Thu, Nov 12, 2020 at 4:46 PM Poul-Henning Kamp 
wrote:

> 
>
> > predicts that d(UT2)/d(TAI) = 1 after 2021-11-13, ie
> > the rates of UTT2 and TAI are expected to agree for the
> > next year. This has never happened since 1961. We may
> > not need to abolish leap seconds for quite a while.
>
> Unless of course we get close enough to a negative one, that people
> are *really* going to freak out.
>
> Hands in the air:  Who here besides Warner and me has ever tried to
> test handling of negative leap-seconds ?
>

I'd poke my hand up, but when I tested it, it severed my arm...

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

Re: [LEAPSECS] Bulletin C number 60

[Warner Losh]

On Sun, Jul 12, 2020, 9:07 AM Poul-Henning Kamp  wrote:

> 
> Tony Finch writes:
>
> > The LOD is hovering around 0 and the UT1-UTC chart is looking remarkably
> flat.
> >
> >
> https://datacenter.iers.org/singlePlot.php?plotname=FinalsAllIAU2000A-UT1-UTC-BULA=9
> >
> >
> https://datacenter.iers.org/singlePlot.php?plotname=FinalsAllIAU2000A-LOD-BULA=9
>
> Is it time for a LEAPSECS betting pool on when the first negative leap
> second is deleted ?
>

I'll have to stock up on the popcorn for the broken things that will find...

Warner

-- 
> 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] coördinated time

[Warner Losh]

"I shall endeavor to point out all that experience has forced upon me."

Wow! If that doesn't describe the discussions on this list to a T, I don't
know what does :)

Warner

On Tue, Mar 31, 2020 at 11:12 AM Eric Scace  wrote:

>Attached are two letters discussing coördinated time:
>
>- G. B. Airy, the Astronomer Royal, from 1881 July 12
>- W. F. Allen, on behalf of certain railroads, to the mayor of New
>York City, from 1883 October 19
>
>
>Today’s issues would seem very familiar to these men.
>
>
> ___
> 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] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

[Warner Losh]

On Thu, Feb 13, 2020, 12:36 PM Tom Van Baak  wrote:

> > I thought of Loran...  but you need 2 stations for time, I thought...
>
> 2 (or more) Loran-C stations gave you more accurate time. But if you know
> where you are, and since the stations don't move, you can manually adjust
> for signal propagation delay to some extent. This is not unlike how one
> obtains time from WWV or WWVB.
>
One of the big issues with LORAN C, I thought, was that those variations
were measured in microseconds...

But I guess those average out over time so if you have a stable local
oscillator you can recover time fairly well.

Fun fact, LORAN has no leap seconds (since it is just a bunch of different
rates). So to calculate time of coincidences with UTC you had to basically
use TAI - 10s since the LORAN signal is paced with SI seconds. When I was
working on the replacement timing system for the LORAN chains, this was a
big deal since to start LORAN you needed to know both the UTC time and a
recent / near future table of leap seconds... This leads to a lot of edge
cases, especially when you needed to cope with the cold spare GPS reciever
case. :(. It's also where all the love I feel for leap seconds left my
body...

Warner

> /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] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

[Warner Losh]

On Thu, Feb 13, 2020, 11:13 AM Steve Allen  wrote:

> On Thu 2020-02-13T14:37:32+ Richard Langley hath writ:
> > https://www.gpsworld.com/gps-backup-demonstration-projects-explained/
>
> Crossing over a thread from time-nuts, the Wildwood eLoran should turn
> on its transmitter some time this week.
>

I thought of Loran...  but you need 2 stations for time, I thought...

Warner

--
> 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   https://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] Leap seconds have a larger context than POSIX

[Warner Losh]

On Thu, Feb 6, 2020 at 7:17 AM Brooks Harris  wrote:

> On 2020-02-06 9:08 AM, Warner Losh wrote:
>
>
>
> On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak  wrote:
>
>> Hi Hal,
>>
>> It's 2020. How on earth can NTP still not implement UTC correctly, in all
>> cases? Or is it a fundamental NTP design flaw?
>>
>
> Design flaw. NTP time stamps can't encode a leap second. It can therefore
> never really work in all cases. We are left with what hack do you want to
> do today.
>
> You can't fit 86401 pegs in 86400 holes. Something's got to go. No
> agreement on what goes.
>

Exactly. We have a number of different hacks that we use to keep the
problems under control, to discard potentially bad data, to filter bad data
that we can't discard, etc. It's a series of hacks that usually work well.
Not because it's well specified, but because different implementations have
programmed defensively to ensure that the current spec + unwritten policy
rules + some known past bugs are filtered so ntpd doesn't react when it's
likely a bad time. This will fail, of course, if we ever have a leap second
in March or September. It's working for the conditions we have today, which
is great, but it's not robust or resilient.

> The Z3801A issue doesn't sound like an NTP problem. This is a known legacy
>> Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected by one or
>> even two GPS WNRO problems buy now?
>>
> Known past issues are likely future problems. 40 years in software has
> taught me that we do not always learn and apply the lessons of the past.
> Every 5-10 years we swap out the coders that learned them for newer,
> cheaper labor. Or there are new players in a niche that have more hubris
> than tribal knowledge. This guarantees bugs will repeat.
>
> Especially in the absence of clear specifications.
>

Yes. That's exactly what I meant by tribal knowledge. We could all tell
long stories about how we learned all the details because of that absence...

Warner


> Warner
>
>
> /tvb
>>
>> On 2/6/2020 1:41 AM, Hal Murray wrote:
>>
>> tvb said:
>>
>> There's no ambiguity. Those are just bugs. No software should depend on  more
>> than 1 month notice of a leap second and no software should be  fooled if the
>> notice is months or even years in advance.
>>
>> There are plenty of quirks in ntp code along that line.  The APIs don't have
>> an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You
>> have most of the next day to turn it off.  The leap-pending on the wire is
>> leap-at-the-end-of-this-month.
>>
>> I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was
>> June or December.  It's a hack, but it gets the job done and the code wasn't
>> setup to ask it when the leap would happen.
>>
>>
>> tvb said:
>>
>> If you're writing a FAQ or best practices guide stay in touch. I have a
>> semi-technical leap second report in the works. UTC is actually very  simple;
>> but it's been complicated by untold levels of bad assumptions,  bad
>> execution, and bad prose.
>>
>> Are you going to say anything about POSIX?
>>
>>
>>
>>
>> ___
>> LEAPSECS mailing list
>> LEAPSECS@leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>
>
>
> ___
> LEAPSECS mailing 
> listLEAPSECS@leapsecond.comhttps://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] Leap seconds have a larger context than POSIX

[Warner Losh]

On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak  wrote:

> Hi Hal,
>
> It's 2020. How on earth can NTP still not implement UTC correctly, in all
> cases? Or is it a fundamental NTP design flaw?
>

Design flaw. NTP time stamps can't encode a leap second. It can therefore
never really work in all cases. We are left with what hack do you want to
do today.

> The Z3801A issue doesn't sound like an NTP problem. This is a known legacy
> Z3801A f/w or Motorola Oncore problem, yes? Maybe also affected by one or
> even two GPS WNRO problems buy now?
>
Known past issues are likely future problems. 40 years in software has
taught me that we do not always learn and apply the lessons of the past.
Every 5-10 years we swap out the coders that learned them for newer,
cheaper labor. Or there are new players in a niche that have more hubris
than tribal knowledge. This guarantees bugs will repeat.

Warner


/tvb
>
> On 2/6/2020 1:41 AM, Hal Murray wrote:
>
> tvb said:
>
> There's no ambiguity. Those are just bugs. No software should depend on  more
> than 1 month notice of a leap second and no software should be  fooled if the
> notice is months or even years in advance.
>
> There are plenty of quirks in ntp code along that line.  The APIs don't have
> an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You
> have most of the next day to turn it off.  The leap-pending on the wire is
> leap-at-the-end-of-this-month.
>
> I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was
> June or December.  It's a hack, but it gets the job done and the code wasn't
> setup to ask it when the leap would happen.
>
>
> tvb said:
>
> If you're writing a FAQ or best practices guide stay in touch. I have a
> semi-technical leap second report in the works. UTC is actually very  simple;
> but it's been complicated by untold levels of bad assumptions,  bad
> execution, and bad prose.
>
> Are you going to say anything about POSIX?
>
>
>
>
> ___
> 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] Leap seconds have a larger context than POSIX

[Warner Losh]

On Tue, Feb 4, 2020 at 7:31 AM Brooks Harris  wrote:

> On 2020-02-04 2:54 AM, Warner Losh wrote:
> >
> > Have I forgotten any of the other details of leap seconds that are
> > more tribal knowledge than rigorously specified?
> >
> > Warner
> >
> >
> I think another unclear topic is when the value of DTAI ("The value of
> the difference TAI – UTC") is updated. This is not clearly stated
> anywhere and I've heard many discussions about it, including here on
> this list. The question is if DTAI is updated simultaneous with the
> leap-second of after the leap-second. Rec 460 does not state this. The
> answer is evident only by *implication* in Bulletin C and other
> publications. Bulletin C 52, for example, says " UTC TIME STEP on the
> 1st of January 2017", and shows:
> from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
> from 2017 January 1, 0h UTC, until further notice : UTC-TAI = - 37s
>

That's a good point. Lord knows I've thought, in the past, that it
accumulated over the leap second. However, that's not entirely true because
the rules for the irregular radix that embodies UTC are weird and require
much careful thought that often runs against mathematical intuition. I even
had worked out the math to prove his once, only to discover that my 'proof'
was fatally flawed and the only proper way to increase the delta is by
1.0s, exactly, at the end of the leap second. This is all tricky stuff that
should be explicitly specified for a rigorous standard.


> Bulletin C does not say or indicate the value will change with the
> leap-second, but immediately after the leap-second, simultaneous with
> the following midnight. Other publications, such as
> Leap_Second_History.dat show this same relationship. But no prose says
> "the value *shall* update *after* the leap-second".
>

Yes. That's the only way I found to make the math work properly.


> Curiously Bulletin C does not call this "DTAI" as Rec 460 does, and
> gives the value in the opposite sign (Rec 460 calls it "TAI – UTC" and
> Bulletin C calls it "UTC-TAI"). This is an example of the inconsistency
> in the use of terms and nomenclature in the relevant documents at ITU-R,
> BIPM, and IERS, which does not help clarity.
>

That inconsistency doesn't help. There's also the issue that what time
geeks call "T1-T2" is computed by subtracting T2 from T1 because that's
what time counters do and that's a convention that carries over from the
metrological laboratory side of the time keeping business. I suspect that
some of this sloppiness is due to different groups having different
conventions in what they mean, and this disconnect wasn't noticed in the
drafting process.


> Find is a copy of Rec 460 I've modified at:
>
> http://edlmax.com/Common_Calendar/R-REC-TF.460-6-200202-I!!MSW-E_BEH_V1_2019-11_15.doc
>
> I've added minimal prose changes (red) and an addition to ANNEX 3,
> FIGURE 3 to clarify these two issues, 1) that TAI and UTC are to be in
> the YMDhms form, and 2) that DTAI updates after the leap-second. I feel
> if Rec 460 had these small changes it would make the use of leap-seconds
> much more clear and save many hours of discussion and angst. It took me
> a long time to have confidence in my understanding when I first
> encountered the leap-second some years ago.
>

I'll have to read through it. It sounds useful.

One bone to pick, though, is that TAI and UTC are both continuous time
scales, so applying the continuous bit to TAI  seems to imply UTC isn't
continuous. But I think it means continuous in the sense that TAI has been
maintained since that time, without interruption, and that no inference
about UTC should be made. UTC has had small jumps back and forth in the 60s
in the rubber leap second era (which were discontinuities), so perhaps the
wording is a nod to that, but an explicit nod would be better. So there's
two ways to view this and ambiguity is rarely a good thing...

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

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Warner Losh]

On Mon, Feb 3, 2020, 6:01 PM Brooks Harris  wrote:

> On 2020-02-03 10:37 AM, Michael Deckers via LEAPSECS wrote:
> >
> >
> >The 1970 report also contains the proposal that the CIPM should be
> >responsible for the definition of UTC, and 49 years later, the CGPM
> >in 2019 seems to have taken on that task with the resolution
> >[https://www.bipm.org/en/CGPM/db/26/2/] which notably has no
> >requirement that |UTC - UT1| be bounded.
> >
> >
> I'd like to point out something about the language used in this CGPM
> reference I feel contributes to confusion in some forums.
>
> It says "
> - International Atomic Time (TAI) is a continuous time scale produced by
> the BIPM based on the best realizations of the SI second. ...
> - Coordinated Universal Time (UTC) is a time scale produced by the BIPM
> with the same rate as TAI, but differing from TAI only by an integral
> number of seconds..."
>
> This seems to imply that TAI is an uninterrupted incrementing count of
> SI seconds, and that there is some corresponding form of UTC also
> delineated in uninterrupted incrementing count of SI seconds. This is
> misleading.
>
> ITU-R Recommendation 460 says:
> "TAI ... It is in the form of a continuous scale, e.g. in days, hours,
> minutes and seconds from the origin 1 January 1958"
> and
> "UTC ... corresponds exactly in rate with TAI but differs from it by an
> integer number of seconds."
>
> What is meant here, as most on this list will understand, is that both
> TAI and UTC are to be represented in YMDhms form and that UTC "differs"
> from TAI "by an integer number of seconds" *as represented in YMDhms
> form*. There is no meaningful UTC as an uninterrupted incrementing count
> of SI seconds.
>
> Recommendation 460 itself is slightly misleading in this regard. I think
> it would be better if the UTC statement made it clear that UTC is also
> in the form of YMDhms with its "23:59:60" leap-seconds. This can be
> surmised from other parts of the document, but I don't think its clear
> without careful study.
>
> I've heard many discussions where "uninterrupted incrementing count of
> SI seconds" is confused with the YMDhms representations. I wish the
> BIPM, IERS, CGPM, and ITU-R documents were more clear and used more
> consistent language and descriptions.
>

Yes. I wish it were clearer that TAI time is a regular radio expression of
time. Here regular radix means that it every day has 24 hours and every
hour 60 minutes and every minute has 60 seconds.

UTC has an irregular radix where minutes may have 59 or 61 seconds that are
published in table form or as new rows in the table. All past times have a
set and knowable table. Future times cannot be know past 1 second before
the leap second opportunity after the next announced leap second
opportunity.

At the moment there are only two opportunities to consider, though the
standard allows up to end of every month. This ambiguity has lead to bugs
when leaps were announced more than 3 months in advance. I'd feel better if
there were a commitment to these parameters for some number of years. But
it's all just convention today.

Have I forgotten any of the other details of leap seconds that are more
tribal knowledge than rigorously specified?

Warner


-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] Leap seconds have a larger context than POSIX

[Warner Losh]

On Sat, Feb 1, 2020 at 10:57 PM Seaman, Robert Lewis - (rseaman) <
rsea...@email.arizona.edu> wrote:

> Tried to send this a few days ago, but it never showed up on the list.
> Steve has provided gritty details since.
>
>
>
> Since roughly the second world war, the distinction between time-of-day
> and interval-time has become increasingly clear. But the history of this
> distinction goes back at least as far as Galileo. UTC was an attempt to
> serve both Universal Time (time-of-day) and Atomic Time (interval timing)
> using a single standard.
>

UTC is one solution, but it's :60 second is a wart it invented in 1972 with
no consultation with the rest of the world.  To say it's universal really
misses the point that it's just a good approximation of a Universal time
that's handy for some group of people, but difficult for others. It was
changed in the lifetime of many on this list. It could change again to be a
better fit with changing times. There should be nothing sacrosanct about it
as it was invented out of whole cloth 48  years ago. It was unprecedented
at the time, and for the first 35 or so years the difficulties of
implementing it for computers were unknown because computers didn't keep
time well enough for it to matter. Now they do.


> Folks in this thread are focusing on the difficulties of this scheme, but
> UTC has had significant success as well. Nobody would be trying to build on
> top of it if this were not true. One reason UTC has succeeded is because
> of  its design implementing Universal Time, not in spite of it.
>

I'd argue one reason it's been successful is that it papers over the issues
with seconds changing length to get universal time. I think the important
part of UTC is thee C part not the UT part. So long as everybody agrees on
what time it is, and that time is close to the Solar time, we're good. We
have lots of timezones, especially in Russia, that are more than an hour
different than mean solar time. This suggests that time of day relative to
the sun has a tolerance for almost everybody of around an hour, which
suggests a UTC++ plus timezones that can keep things within an hour is
fine, which leaves a lot of wiggle room, though there will be winners and
losers to any change.


> It seems bizarre to have to state that it would be wise to fully analyze
> civil timekeeping engineering requirements before making any changes. Some
> here have participated in a variety of meetings and discussions with this
> goal, but I am unaware of any external funding for such activities. Other
> communities have invested much greater time (so to speak) and money
> regarding similarly ubiquitous, yet esoteric, standards and protocols.
>

Part of that analysis should necessarily include the impact on computing as
well

If the precision timekeeping community had adopted the proposal from the
> 2003 Torino symposium to define the new time scale called TI, we would have
> had 17 years to cover the Earth like locusts. Instead the intervening
> period has been squandered trying unnecessarily to undermine UTC. Recipe
> for success:
>

>
>1. Define a new time scale and leave UTC alone for future
>compatibility. Your own systems engineering requirements likely include
>time-of-day.
>
> Except nobody will use this. We already have a dozen different time scales
without leap seconds. Nobody uses them outside a niche. Everybody inside
that niche translates the niche time scale to UTC for displaying to users.


And people have tried running kernel time in TAI time.  It didn't work.
Even when  you try  to be compatible, there's dozens of problems that make
it hard because it's not just POSIX time_t that's at issue (though within
the kernel it's bad enough). It's the fact that things like filesystems
specify an elapsed time since an epoch in a time scale without leap
seconds. Every FAT or NTFS disk around has a time like this. So conversion
of kernel TAI times to UTC or these other time scales requires perfect
knowledge of leap seconds, and conversions more than 6 months in the future
are ambiguous at best.


>
>1.
>2. There are two kinds of time and timekeeping. All successful systems
>engineering will start from this simple fact.
>
>
> Whatever POSIX does with leap seconds should be in a larger and more
> coherent global concept of timekeeping.
>

POSIX can't do leap seconds. That ship has already sailed. It's more than
just POSIX as it is baked into almost all storage formats today. Even if we
could fix that issue, there are significant operational issues with ticking
in TAI since a full leap table is required to convert TAI times to UTC.

If it were just what is returned by the kernel during a leap second, that
might be solvable (smearing NTP shows that's possible). But given the
mutually exclusive demands on timestamps and their arithmetic properties,
it's impossible to fix without significant breakage. A cost/benefit
analysis likely would conclude the cost to, say, eliminate leap 

Re: [LEAPSECS] leap seconds in POSIX

[Warner Losh]

On Sat, Feb 1, 2020 at 3:39 PM Brooks Harris  wrote:

>
> (As I understand it time_t is deprecated and replaced by struct timespec
> in modern POSIX systems. This does not eliminate the leap-second
> difficulty.)
>

Kinda sorta... the timespec  struct has a time_t inside of it.


> The leap-second modification of the Gregorian calendar YMDhms counting
> sequence presents an irreconcilable dilemma. I think most appropriate
> term to describe the UTC v.s. computer time and civil time mismatch is
> "incommensurate". You cannot map UTC into Gregorian without losing
> something, and that something is the leap-second.
>

The problem is that it has an irregular radix.

:60 is the odd-duck whose quacks are the harbingers of doom :)


> As Tom points out, the definition of the POSIX origin, "The Epoch", is
> *intentionally* vague to accommodate systems that could not accurately
> align to "1970-01-01 00:00:00". This date and time is said to be "UTC"
> but this is misleading as it is not strictly UTC because A) the count
> skips leap-seconds and B) UTC was not an integral second adjustment
> until 1972-01-01 00:00:10 (TAI) = 1972-01-01 00:00:00 (UTC) (I like to
> call this alignment point UTC1972), so the POSIX "the Epoch",
> 1972-01-01 00:00:00 (POSIX), sits in the never-never world before
> UTC1972. As I understand it modern systems try to align "the Epoch" at
> exactly 63072000s (730 86400s days) before UTC1972.
>

That's because every POSIX day  is 86400 seconds long, without exception.
:) :<

POSIX doesn't define the relationship between time_t and anything else,
other than  to prescribe a mapping. Many systems these days have a
specification that like
"Number of actual seconds since UTC1972+63072000 + negative leap seconds -
positive leap seconds." to align the time scales to time_t.

But the problem with time_t are legend. I should do a talk that lists them
all.

The biggest problem is that people think they can solve the timestamp issue
with metadata. But you can't because that metadata necessarily must be
discarded to fit within external protocol requirements.  If I do an  NFS
get file attributes, one attribute is file creation time.  Should this
occur during a leap second, there's no way to encode that metadata in
response to that request. That's even assuming the stable media encodes
things such that it is knowable, or that the OS provides a way to set that
time, or that the OS ticks through the leap second properly. And as brooks
said, you can't fit 86401 pegs into  86400 holes. One hole necessarily must
hold two pegs. Smearing breaks frequency, and accepts an offset to try to
power through the problem, but it in no way solves the problem... it just
accepts certain errors as OK to paper over the whole mess.

And even if all that were right, it assumes you can get a verified,
temper-proof list of leap seconds easily, which isn't always possible. It's
the cross product of all these issues that make leap seconds an impossible
problem to solve in  a way that doesn't discard data of some sort...

Warner


> >
> >
> > On 1/27/2020 12:59 AM, Hal Murray wrote:
> >> Does anybody know of a good writeup of how to fix POSIX to know about
> >> leap
> >> seconds and/or why POSIX hasn't done anything about it yet?
> >>
> >> I assume the basic idea would be something like switch the kernel to
> >> use TAI
> >> rather than UTC and implement conversion in some library routines.
> >>
> >>
> >> There is a discussion on the IETF ntp list with typical S/N for this
> >> topic.
> >>
> >
> > ___
> > 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] leap seconds in POSIX

[Warner Losh]

On Mon, Jan 27, 2020 at 8:17 AM Steve Summit  wrote:

> Hal Murray wrote:
> > Does anybody know of a good writeup of how to fix POSIX to know about
> > leap seconds and/or why POSIX hasn't done anything about it yet?
>
> I don't know why POSIX hasn't done anything, other than that
> (1) it's an excruciatingly hard problem, made even harder by
> (2) the ubiquity and the specific POSIX definition of time_t.
>
> > I assume the basic idea would be something like switch the kernel
> > to use TAI rather than UTC
>
> But that seems to end up being a non-starter, because
> (1) distributing updated TAI-UTC tables is really hard
> (and basically impossible for certain classes of embedded and/or
> isolated systems), and (2) everyone knows how to initialize a
> system clock to UTC at bootup, but almost no one knows how to do
> so for TAI.
>
> The other basic idea is to implement new, proper-UTC-capable
> kernel mechanisms and interfaces alongside the time_t ones.
> I'm still a big fan of the clock_gettime(CLOCK_UTC) approach
> described by e.g. Markus Kuhn at
>
> https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html
>
> , but it never seems to have caught on.  I went through the
> exercise of implementing it myself in a homebrew Linux kernel,
> which I used to post a message to this list a few years back
> with an honest-to-goodness timestamp of
>
> Date: Sat, 31 Dec 2016 18:59:60 -0500
>

You've just scratched the surface of the problem.

How do I touch a file on Sat, 31 Dec 2016 18:59:60 -0500 and have ls -l
report that as its timestamp?


> Sadly, I've never managed to properly release or publish this
> work.  And that sort of gets back to the first part of the
> question: Why does there not seem to be much urgency about
> "solving" this problem?  Besides the points I mentioned earlier,
> I can speculate on a few more:
>
> * Leap seconds are rare, and many people don't care.
>
> * The leap second drought of 1999-2006 rather nastily coincided
>   with a gradual change in the computing industry from "nobody's
>   clocks are synchronized that well anyway, so a second here or
>   there doesn't matter" to the opposite.  (But by the time we
>   realized we had a leapsecond problem, it was sort of too late
>   to fix it.)
>
> * These days, it seems everybody who has really thought about it
>   has concluded that leap seconds are impossible or a really bad
>   idea, and is sitting around waiting around for the ITU to
>   abolish them, and maybe implementing leap-smeared NTP servers
>   to tide us over in the meantime.
>
> Remarkably, though, *Microsoft* of all people seized the bull by
> the horns and announced more-or-less proper leapsecond support in
> Windows a little while back; it might be instructive to study
> that effort for lessons.
>

I wonder how it deals with the externalities problems, where protocols
specify UTC times, but then make it a simple count of seconds (ignoring
leaps) since some epoch?

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

Re: [LEAPSECS] leap seconds in POSIX

[Warner Losh]

On Mon, Jan 27, 2020 at 5:35 AM Tony Finch  wrote:

> Zefram via LEAPSECS  wrote:
> > Hal Murray wrote:
> > >I assume the basic idea would be something like switch the kernel to
> use TAI
> > >rather than UTC and implement conversion in some library routines.
> >
> > That's not a viable approach, because of the wide range of uses to which
> > time_t is put.
>
> In particular, the kernel needs time_t for compatibility with filesystems
> that need it, and other non-syscall interfaces that expose time_t. There's
> a lot of them.
>

Yes.  The problems are legend.

First, there are the 'return time' system calls or legacy routines. These
aren't so bad. You can make new ones: gettimeofday, settimeofday, time.
Then, you need gmtime and timegm except for TAI. The goal here being that
you use either all old, or all new routines.  The new routines are just
like the old, so that seems to work because there's no leap seconds.
clock_getime has the ability to have a CLOCK_TAI even.

Except that the gmtime routines are still not quite right. time_t <->
struct tm is still lossy. So, to really fix the problem you need to either
enhance struct tm to carry metadata of the sort of timezone (since UTC is
almost a time zone). and then you need to think hard about what to do with
gmtime/taitime wrt leap seconds. So you'd need to fix the 'feature' of
gmtime/timegm that you can do things like add to the different tm_* fields
to move time forward. But that starts to intrude into real code changes.
Otherwise, you can't represent a leap second.

And then there's functions like stat, utimes, futimes, that have time_t
burried in them as struct timeval or struct timespec. If you want to change
the interpretation of those values (which is currently UTC), you'd need new
versions of those system calls that return TAI time. And you'd have to be
careful too: nanosleep(2) and select(2) doesn't need a new version since
its timeval is an interval, not an absolute time. There's some like the
clock_* routines that don't need to change too. In FreeBSD I counted about
two dozen instances that would need to be audited.

And then you have to worry about filesystems. What happens if I'm building
software during the leap second? Regardless of how you shoe-horn the time
into place, you can wind up with a situation where the source is newer than
the object for things like generated files, which will confuse make. So now
you need to have a bunch of routines in the kernel to convert historical
UTC times to TAI times, which means you need all leap seconds that have
ever happened to do it right (remember, we added system calls to get this
data in TAI not UTC above). And that's not even getting into external
things like NFS that need to do this over the network (though largely, it's
the same problem).

And so now you're left with a data management problem. You have to update
the timezone files, because that's how you paper over UTC enough to make
the old routines work (except during a leap second). And you have to invent
mechanisms to keep them up to date in long running programs (otherwise
those slowly diverge in systems with long uptimes). And so you have to be
connected to the internet (or some other data stream) to make the updates.
And if you're making updates in place, you have to do it atomically so you
don't race.

And even if you do all that, it's impossible for me to get the TAI time for
any times > 6 months out (technically the other side Dec 31 or June 30)
because we have no clue what that time will be. We find out in January if
there's a leap in June, so future time values in June can't possibly be
right if you are doing them in December. Sure, you can pull out the 'use
struct tm or its replacement' for such times so far in the future, but
that's kinda arbitrary since times 3 months in the future are fine...
Unless the system has been disconnected from its data sources for some
reason...

So sure, you can half-ass something that solves some of the problems, but
it's a huge undertaking to do it all right. And there's huge resistance to
being this intrusive into the system just to fix a silly problem once every
couple of years. Why slow things down the other half billion seconds
between leap seconds.

It's not a simple problem at all to get completely right.

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

Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug

[Warner Losh]

On Wed, Jun 12, 2019 at 8:39 AM Richard Langley  wrote:

> And a further nit-pick. The leap-second information is not included in the
> GPS Almanac (as reported in news items), per se. Of course, it's in the
> navigation message, but elsewhere in the Subframe 4 and 5 data. And it is
> only needed to relate GPS Time to UTC. Most GPS receivers operate on GPS
> Time and compute positions of the satellites using Almanac data (for
> acquisition and tracking) including WN_a and t_oa (GPS Week and GPS Seconds
> of Week to get the Almanac reference epoch). Once the receiver solves for
> its clock offset (using the more accurate Ephemeris data), accurate GPS
> Time is available to the receiver and then it can compute UTC (correctly
> accounting for the leap-second offset). I guess somehow the Rockwell
> Collins receiver needs correct UTC to properly function. That's my
> interpretation anyway.
>

The almanac takes about 15-30 minutes to download depending on how smart
your GPS receiver is. And most GPS receivers these days cache much of this
information since it changes so slowly. GPS receiver can function as a
location device w/o knowing the UTC offset, and many do. However, they can
function as a timing device that provides UTC until this almanac is in
place (or you know your cached copy is good). All GPS receivers rely on GPS
time to do location computations, otherwise they will get the position
wrong... Some GPS receivers have a defective control loop that hangs until
the almanac is downloaded (thankfully those are rare). Some provide GPS
time as it it were UTC time until the almanac is downloaded (those are also
rare now-a-days). Some do crazy stuff when 1024 weeks have elapsed since
the last leap second (I'm looking at you Motorola Oncore). Some do weird
things when 128 weeks have elapsed (as is the case here). These are all
bugs in the implementation, but they are common enough that even a decade
after working on this stuff day-to-day I still can call to mind all the
exception cases I had to defensively program around because leap seconds
suck, as implemented, and should die in a fire. They are great in theory,
and serve a useful purpose, but the number of low-quality implementations
of them that persist to this day makes me despair they will ever be
implemented right enough to be universally useful w/o a 1s hick-up. I take
leap second smearing as vindication of this position, but few others see it
as the repudiation of the TF.460 I do...  so, I've got that out of my
system for another year :)

So yes, it's just a bug, true. But it shouldn't be brushed off as 'just'
anything...

Warner


> -- Richard Langley
>
>
> -
> | Richard B. LangleyE-mail: l...@unb.ca
>|
> | Geodetic Research Laboratory  Web: http://gge.unb.ca/
>|
> | Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142
>  |
> | University of New Brunswick
>  |
> | Fredericton, N.B., Canada  E3B 5A3
>   |
> |Fredericton?  Where's that?  See: http://www.fredericton.ca/
>|
>
> -
>
>
>
> > On Jun 12, 2019, at 9:49 AM, Tom Van Baak  wrote:
> >
> >
> > ✉External message: use caution.
> >
> > > However, the current GPS/UTC offset numbers before and after the
> nearest
> > > leap seconds are still 18/18, so there is no current leap second
> > > announcement, and WNlsf may be ambiguous.
> >
> > Perhaps call it "immaterial" rather than "ambiguous"? The fact that it's
> 18/18 means no positive or negative leap second is pending. Period.
> >
> > In other words, the value of WNlsf doesn't matter in this case. It's an
> 8-bit value so obviously it must always be something between 0x00 and 0xFF,
> or -128 to +127. Maybe it's a recent old value, maybe it's zero, maybe a
> future new value, or maybe random. It doesn't matter. What matters first
> are the tLS and tFLS values, which are currently 18/18 -- which means no
> leap second. Period.
> >
> > A similar issue arose in some GPS receivers during the 7 year "leap
> second drought" of 1998 to 2005. [1]
> > Here's the math:
> >   • GPS start date: 1980-01-06 (MJD 44244)
> >   • Most recent leap second: end of the day 2016-12-31 (MJD 57753)
> >   • Most recent leap second: prior to the day 2017-01-01 (MJD 57754)
> >   • Date of first Collins / GPS / ADS-B anomaly: 2019-06-09 (MJD
> 58643)
> >   • Date that Collins says their systems will start working again:
> 2019-06-16 (MJD 58650)
> > Note that (58650 - 57754) / 7 = 128.000
> > So it's a big Rockwell-Collins oops. Both the GPS receiver firmware
> engineer who wrote the embedded code and the tester using a fancy GPS
> simulator dropped the ball.
> > /tvb
> > [1] http://www.leapsecond.com/notes/leapsec256.htm
> >
> >
> > ___
> > LEAPSECS mailing list
> > 

Re: [LEAPSECS] Windows 10 time

[Warner Losh]

On Fri, Apr 12, 2019 at 9:39 AM Brooks Harris  wrote:

> Hopefully Linux will follow suit in some manner. This might be
> accompanied with updating POSIX time in some manner to support Leap
> Seconds..
>

The last 20 attempts to do that have failed, sadly. time_t is quite
pervasive and has a significant amount of both legacy code (which could
mostly be dealt with by transitioning to new interfaces, but not entirely
ushering in a new class of off by 37s bugs) but also it's stored in a
number of places that are impossible to change (timestamps in legacy
filesystems). It's relatively easy to mostly get the get/set time
interfaces to allow for leap seconds, but the data storage problem is a
hassle. Also, since the legacy interfaces don't really have leap seconds in
them at all, you still have all the hassles of repeating times for code
that's not been updated.

While I applaud Microsoft for strong-arming these changes through (and
taking the huge amount of time to chase down all the API implications),
there's no such driving force in Linux, BSD or any of the other Unixes,
with the possible exception of Apple and ios/osx. Google + android might be
able to get away with a change here, should Google decide to cope, but
since they already just smear I doubt the idea would get enough traction to
get the proper level of commitment organizationally to make it happen.

And, as always, I'd love for someone to do all the work and prove my jaded
cynicism wrong.

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

Re: [LEAPSECS] Adjusting Big Ben video (was Re: Of stepping motors and leap seconds)

[Warner Losh]

How do they keep big Ben in sync these days? Eg, who decides it is running
fast or slow? In the past I've been told they steered to Greenwich
observatory who would shoot a cannon off and drop a red ball to announce
the time to London... on my recent trip to Greenwich observatory I
discovered they no longer fire off the cannon, etc.

Warner

On Sat, Feb 9, 2019, 5:50 PM Peter Vince  Sorry Tom, that BBC news item is ten years old, and it looks like the
> video has been removed.  There are a number of videos on Youtube which talk
> about adding or removing old pennies from the pendulum to correct it.  See,
> for example:
>
> https://www.youtube.com/watch?v=_Elffjsjbio
>
> An eight-minute video extracted from the Discovery channel's "Blowing Up
> History" series, entitled:  The Mechanical Genius of Big Ben
>
>  Regards,
>
>Peter
>
>
> On Fri, 8 Feb 2019 at 13:29, Tom Van Baak  wrote:
>
>>
>> There's a wonderful BBC video showing how Big Ben is adjusted for leap
>> seconds:
>>
>> "Leap second: Slowing down Big Ben" [1]
>> http://news.bbc.co.uk/2/hi/science/nature/7792436.stm
>>
>> In this case they do not literally move the massive weight up or down,
>> but instead, by adding tiny weights (usually penny coins) they change the
>> effective center of gravity of the bob, which is all that matters. This is
>> an unexpected application of the saying that "time is money".
>>
>> /tvb
>>
>> [1] If someone (UK only?) can capture this short video as mp4 I'd
>> appreciate it.
>>
>> ___
> 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] is leap smear legal in Germany?

[Warner Losh]

On Mon, Feb 4, 2019 at 11:14 AM Kevin Birth  wrote:

> Since law significantly lags behind technology, the leap smear is probably
> not illegal in any private network in any country.  After all, UTC is still
> not the "legal" time in many countries.
>
> NTP was developed after rubber seconds.  If NTP had developed before
> rubber seconds, and if the increments lengthening the rubber seconds were
> small enough, there might never have been a leap second policy.
>

Maybe, maybe not. For some things, rubber leap seconds are fine. For
others, the error in the frequency exceeds the tolerances for control
systems that care about errors as small as 1E-6 that will be wrong on leap
second spear day. Having seconds of different lengths is a problem for this
class of people, and will be a problem whether or not there's a leap second
step.

NTP was developed after leap seconds started, it is true. But it took
20-odd years after it was developed for people to start smearing leap
seconds. The prime mover for leap seconds was never computer time, which in
1970 sucked by today's standards: to be within minutes of the "correct"
time was good enough so nuanced differences in what was "correct" were
never given much of a though (UTC, UT1, UT2, TAI, meh, the delta between
these is 1000x smaller than what my system time can track, so who cares).
It was all about navigation and making sure that there was uniformity.

Warner

Cheers,
>
> Kevin
>
>
> 
> From: LEAPSECS  on behalf of Martin
> Burnicki 
> Sent: Monday, February 4, 2019 10:48 AM
> To: leapsecs@leapsecond.com
> Subject: Re: [LEAPSECS] is leap smear legal in Germany?
>
> EXTERNAL EMAIL: please report suspicious content to the ITS Help Desk.
>
>
> Steve,
>
> Steve Allen wrote:
> > The story about the German time broadcasts of DCF77 is in Bulletin
> > Horaire.
> [...]
> > But now I am trolling and asking:
> > Given that rubber seconds are illegal in Germany, is it legal to
> > use Google/Amazon NTP servers that provide smeared leap seconds?
>
> Thanks for the historic facts on DCF77, that's very interesting.
>
> I don't know if it's legal or not, but I know some of our customers here
> in Germany have explicitly configured their Meinberg LANTIME NTP servers
> to do leap second smearing.
>
> It's not because they like smearing seconds so much, it's just because
> it's a reliable way to avoid problems caused by OS kernels which simply
> step the system time back to insert a leap second.
>
> 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
> ___
> 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] Running on TAI

[Warner Losh]

On Fri, Jan 18, 2019 at 1:35 AM Martin Burnicki 
wrote:

> Steve Allen wrote:
> > On Thu 2019-01-17T18:12:25+0100 Martin Burnicki hath writ:
> >> Hm, maybe that was originally the case. I wonder whether the folks who
> >> wrote the text just had UTC in mind when they "invented" time_t.
> >
> > The best insight into the POSIX committee was posted on LEAPSECS in
> > 2003
> > https://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html
>
> Very interesting. Thanks for the pointer!
>

I've had people report similar discussions or histories related from the
committee in real life as well..  :(


> > Not clear in that posting was that Arthur David Olson's timezone code
> > for Unix systems already contained the code written by Bradley White
> > which allows time_t to count every second in the radio broadcast time
> > scale and handle leap seconds.  POSIX committee members knew that and
> > decided to disregard it with words that actually prevented system
> > designers from adopting a more correct scheme.
> >
> >> So IMO this clearly says that time_t has to be interpreted depending on
> >> the context, and must not necessarily hold exclusively UTC numbers of
> >> second.
> >
> > The tricky part comes when software on one system exchanges values of
> > time_t with another system that believes time_t has a different value.
>
> Yes, but that's basically what I said: It depends on the context (or
> maybe a different word would be more appropriate than "context"), but
> not on the data type.
>
> It's even the same if you look at different struct timespecs taken on
> the same system, but with different clock IDs. From the data type alone
> you don't know how to interpret this correctly.
>

And that's ultimately my point as well. time_t is defined, by POSIX, only
for certain clocks. All other clocks are aggressively undefined by the
standard. You can't take the time_t's from a timespec returned from any
clock other than CLOCK_REALTIME and be assured of getting meaningful
results for a call to localtime() or gmtime(), for example.
clock_gettime(CLOCK_UPTIME), for example, returns time in an epoch that's
not really knowable (elapsed time since the system booted) without other
dynamic pieces of data.

Hence my comments that time_t is very narrowly standardized, though people
often use it for other things. It's important to constrain arguments about
what POSIX does and does not provide to what is standardized. The whole
leap second fiasco in POSIX revolves around how stupidly it is defined in
the standard (where stupidly here means making the actual time standard
impossible to implement, but also a nasty moral judgement on my part about
how the supposedly "good enough" definition has failed the test of time).


> >> I think a good solution would be to have a structure that contains a
> >> time_t value plus at least one flag that indicates the leap second
> >> status, or a field with TAI index. It would be even better to have such
> >> additional information available with struct timespec, so an application
> >> can tell if the time stamp is inside a leap second, or not.
> >
> > I think that the entire infrastructure should recognize the notion of
> > needing two kinds of time:  precision seconds and civil days.  That is
> > what the astronomy community had understood and promoted since before
> > 1950.
>
> I fully agree. From what I've read there are some programming
> environments (Java, Python, ...) that provide individual workarounds for
> the limitations of the OS, but I think you run into trouble again if you
> have to exchange timestamped data between applications that have been
> developed using different build environments.
>

Unfortunately, I think that's a rat-hole that's as big or bigger than the
timezone rathole. Data containing times in the past generally isn't in a
uniform timescale used today, so the older you get, the more complicated
things become. And each discipline has differing notions of time.
Astronomers have one, but that differs by observatory if you get old enough
(mostly the same, but all relative to some local time). People have others.
Lots of others. Many notions of local time existed, most loosely based on
the sun, but not exactly Solar Time for all users (eg Big Ben set the time
for the area around it, and other clocks in London were set to Big Ben's
chimes and others to chimes of other clocks set to Big Ben's clocks, so
that you had only a loose notion of a translation to a universal time from
times in historical records). Some stuff would be easy to do, but it grows
quickly as different notions of time would have to be added to accommodate
more users of time throughout history.


> > That is the hard part.  It is the part that technical folks punted on
> > doing during the 1960s because it would have required explaining the
> > need for two kinds of time to bureaucrats and legislators and waiting
> > for them to change laws and regulations.  Instead they chose to act
> > quickly 

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[Warner Losh]

On Tue, Jan 15, 2019 at 10:09 PM Gary E. Miller  wrote:

> Yo Warner!
>
> On Tue, 15 Jan 2019 17:45:32 -0700
> Warner Losh  wrote:
>
> > > > Except that's not a leap second. struct tm doesn't do leap seconds
> > > > really. It kinda sorta does, but it kinda sorts doesn't.
> > >
> > > Well, it does in a modern Linux kernel.  Otherwise NTPD would fail
> > > on the leap second, and that only happens every year so.  :-)
> > >
> >
> > You are wrong. The kernel doesn't use struct tm.
>
> I never said the kernel uses struct tm.  I said you can query the kernel
> for
> the time in a struct tm.
>

What system call is that? A quick grep didn't turn anything up for me. All
the calls I'm aware of are library calls that get the system time and then
break it up.


> > The kernel does this
> > by ticking either in TAI or by incrementing a TAI offset. ntpd uses a
> > different interface that exposes these things to it so it can
> > broadcast the leap second indicators correctly.
>
> Yup.
>
> > > > First, when you convert back and forth to time_t, you lose leap
> > > > second information. It's impossible to convert back and forth
> > > > from at least the UTC time zone. There's some 'right' time zones,
> > > > but they aren't strictly speaking POSIX compliant because it uses
> > > > the wrong math. Non-conforming, but damned useful and not wrong.
> > >
> > > Which is why you can't use time_t in UTC,  but time_t in TAI
> > > can work, as well as struct tm, usually.  Lot's of latent bugs...
> > >
> >
> > No. time_t is not TAI or GPS. It is UTC. Adjusted UTC.
>
> No, time_t is just a way to count seconds.  See man difftime() for a
> use of time_t that is unrelated to any particular epoch.
>

This is the biggest mistake people make with POSIX time_t. It's not just a
way to count seconds. It is the funky seconds since 1970 thing. By
definition.

difftime takes two time_t's and returns a double that's the difference
between them. This is only a time_t when time_t is defined to be a double
(which is allowed, but apart from IBM, nobody has done that), otherwise it
is not. Typically, time_t is some int type, so difftime isn't a good
example here. Also, the open group standard is silent about what it's
supposed to do across a leap second, but since it operates on time_t, it's
unclear if a time_t of 1230767 and 1230768002 should be 3 or 4 since
those two times straddle 2009 December 31, 23h 59m 60s. I've seen spirited
debate on both sides of that issue.

> It is the
> > number of SI seconds since 1970, minus all the positive leap seconds,
> > plus all the negative ones.
>
> Ciration please?  I already cited the Linux doc that says otherwise.
>

The Linux doc does not define the standard. The POSIX doc does (from the
Open Group 2017 edition):

3.150 Epoch

The time zero hours, zero minutes, zero seconds, on January 1, 1970
Coordinated Universal Time (UTC).
4.16 Seconds Since the Epoch

A value that approximates the number of seconds that have elapsed since the
Epoch. A Coordinated Universal Time name (specified in terms of seconds
(tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the
year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a
time represented as seconds since the Epoch, according to the expression
below.

If the year is <1970 or the value is negative, the relationship is
undefined. If the year is >=1970 and the value is non-negative, the value
is related to a Coordinated Universal Time name according to the C-language
expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all
integer types:

tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

which is equivalent to what I said based on how leap seconds work.

I've done a lot with POSIX time_t and what is and isn't stated in the
standard.  Linux may implement something that's not strictly POSIX
compliant, but the root of the problem with time_t is POSIX defines it very
particularly and when people deviate from the standard, or make their own
up when the standard is silent, they do so is somewhat divergent ways
(which is part of the problem as well as leap seconds not being defined in
time_t as there's no way to represent them uniquely in a time_t, despite
them existing in the non-uniform radix UTC notation).



> > > If you squint at it, GPS time (gps weeks, time of week) is just
> > > another notation very similar to time.  And we know that works.
> > >
> >
> > GPS time has no leap seconds. It's a monotonic count since 1980.
>
> Correct.
>
> > > Since future leap seconds ar

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[Warner Losh]

On Tue, Jan 15, 2019 at 1:50 PM Gary E. Miller  wrote:

> Yo Warner!
>
> On Tue, 15 Jan 2019 12:43:46 -0700
> Warner Losh  wrote:
>
> > Except that's not a leap second. struct tm doesn't do leap seconds
> > really. It kinda sorta does, but it kinda sorts doesn't.
>
> Well, it does in a modern Linux kernel.  Otherwise NTPD would fail
> on the leap second, and that only happens every year so.  :-)
>

You are wrong. The kernel doesn't use struct tm. The kernel does this by
ticking either in TAI or by incrementing a TAI offset. ntpd uses a
different interface that exposes these things to it so it can broadcast the
leap second indicators correctly.


> > First, when you convert back and forth to time_t, you lose leap second
> > information. It's impossible to convert back and forth from at least
> > the UTC time zone. There's some 'right' time zones, but they aren't
> > strictly speaking POSIX compliant because it uses the wrong math.
> > Non-conforming, but damned useful and not wrong.
>
> Which is why you can't use time_t in UTC,  but time_t in TAI
> can work, as well as struct tm, usually.  Lot's of latent bugs...
>

No. time_t is not TAI or GPS. It is UTC. Adjusted UTC. It is the number of
SI seconds since 1970, minus all the positive leap seconds, plus all the
negative ones.

Now, you can use that type bogusly to hold any count from any epoch with
any rules you like, but such use is not POSIX conforming. Many people abuse
time_t to store TAI, it's true, but that's not its definition, and you'll
wind up confusing things because of the 40 second offset between the two.


> If you squint at it, GPS time (gps weeks, time of week) is just another
> notation very similar to time.  And we know that works.
>

GPS time has no leap seconds. It's a monotonic count since 1980.


> > Second, many of the tm_ fields can create a time that's N 's
> > in the future by adding N to that structure and converting. So tm_sec
> > == 60 could be a leap second, or it could be the second after tm_sec
> > == 59.
>
> Since future leap seconds are unknown, and unknowable, there is no
> possible valid way to do this on the time scale of years.
>

Correct. This is the fundamental flaw of UTC.


> > > But gpsd and ntpd try real hard to be correct.  Sadly, with leap
> > > smear, there is no consensus on what is 'correct'.
> > >
> >
> > Both leap seconds and leap second smear must die. Others have
> > different opinions, some strongly held. Not all the contradictory
> > opinions are necessarily wrong.
>
> Good luck with that.
>

Yea. Having done timing systems for a decade now a decade ago, I always
felt that was the best solution. The BIH guys broke time by trying to fix
it. :(

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

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[Warner Losh]

On Tue, Jan 15, 2019 at 12:41 PM Rob Seaman  wrote:

> Isn't this covered (for instance) in section 20.3.3.5.2.4(b) of
> IS-GPS-200J (https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf)? The
> various libraries and operating systems listed deal with none of the
> reference time scales (GPS, UTC, or TAI, for that matter) completely and
> correctly.
>
> This suggests strongly that those models of time are fatally flawed and
should be revisited.

> There's no obvious connection here with astronomical use cases. We rely on
> our reference clocks' vendor to have implemented IS-GPS-200J and relevant
> standards correctly. These devices operate off single board linux cards,
> but I presume they wrote the critical code themselves to handle leap
> seconds, but also other precision timekeeping issues not entertained by
> POSIX and other mass market software. Our clocks handle time scales other
> than UTC, but since our customer (NASA PDCO) specifies UTC, that's what we
> deliver.
>
Spinning rocks are hard, eh? the non-uniform nature of UTC is a big reason
it's hard to implement correctly in software (especially when there's code
size or speed constraints). It's impossible to implement without tables
that must constantly be updated. While this is natural and acceptable in
many environments, it presents operational difficulties for others. The ITU
standard that tries to keep the spinning rock and atomic time in sync is
flawed in that it doesn't adequately accommodate all situations. POSIX has
similar sorts of flaws, but the details differ.

> The bread-and-butter leap second discussions on this list seem irrelevant
> to simply meeting an engineering requirement to adhere to whatever
> standard. If POSIX, python, excel, whatever don't provide canned tools to
> convert seamlessly between GPS and UTC, or to handle format conversions
> from week:ms to sexagesimal, such tools must be implemented outside those
> languages/libraries. There are a vast number of other science-related data
> engineering details that POSIX (for example) also does not implement.
>
Yes. Despite the efforts of the POSIX committee to make it easy to
implement time, those efforts have resulted in a fatally flawed standard
that leads to the "1 second errors are fine, don't bother me" attitude that
pervades many adjacent APIs to the POSIX APIs. It was the number one
frustration that I had when I had to deal with vendors that didn't get the
leap seconds pedantically correct and didn't give a @!##@ that they didn't
because there was no financial penalty for not doing so. It was maddening.

Warner


> Rob Seaman, Lunar and Planetary Laboratory
>
> --
> On 1/15/19 11:50 AM, Tom Van Baak wrote:
>
> Jim -- I'm replying via the LEAPSECS list because we love leap second 
> questions here.
>
> List -- Jim is a long-time member of time-nuts, works at JPL, and does 
> wonderful stuff.
>
> From Jim Lux:
>
> I'm working with a variety of things which work in UTC or GPS
> week/millisecond, so we're doing a lot of conversion back and forth.
> (the spacecraft puts out time in week:millisecond, all the ground
> systems processing is in UTC)
>
> The question comes up when converting back and forth, and whether
> various libraries handle leap seconds correctly.
> For now, I can use a hack of not computing back to 6 Jan 1980, but use
> an epoch like 15 Dec 2018 (week 2031: 518,400.000 seconds) and hope
> there's no leap second in the offing.
>
> Yes, that's one way. But that doesn't sound safe or correct to me.
>
>
> For instance, in Python, if I do a datetime(2016,12,31,0,0,0) +
> timedelta(hours=30) does it come out as 1/1/2017 6:00:00 or 5:59:59  (it
> comes out 0600)
>
> Similarly, does Excel's time formatting allow for some minutes having an
> extra second, or does it just assume all minutes are 60 seconds.
>
> Nope. All minutes have 60 seconds in Excel. And in Windows. And in 
> Unix/POSIX. Really any computer system that uses a fixed "epoch" and a 
> ticking "counter" is ruined by leap seconds. The systems differ in their 
> epoch's, they all differ in their counters, they can all be set to UTC, 
> except they all fail when there's a positive or negative leap second.
>
>
> I'll probably test it for the cases I'm interested in (Ruby, Python,
> Excel, Matlab, Octave), but if someone else has already done it, then
> I've got something to cross check against.
>
> This is a good question for LEAPSECS. I suspect those packages are well-known 
> here.
>
>
> (python does NOT know about leap seconds)
>
> import datetime
>
> d = datetime.datetime(2016,12,31)
>
> dt = datetime.timedelta(hours=30)
>
> d
> Out[4]: datetime.datetime(2016, 12, 31, 0, 0)
>
> dt
> Out[5]: datetime.timedelta(1, 21600)
>
> d+dt
> Out[6]: datetime.datetime(2017, 1, 1, 6, 0)
>
> Right, this is typical for almost any software developed anywhere. Leap 
> seconds are such a weird exception, almost no commercial software, web 
> frontend or backend, or mobile phones, or mobile apps deal with them 
> 

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[Warner Losh]

On Tue, Jan 15, 2019 at 11:58 AM Gary E. Miller  wrote:

> Yo Tom!
>
> On Tue, 15 Jan 2019 10:50:10 -0800
> "Tom Van Baak"  wrote:
>
> > Nope. All minutes have 60 seconds in Excel. And in Windows. And in
> > Unix/POSIX.
>
> Not quite.  Check out "man gmtime" for one way that POSIX represents time.
>

Yes and no. time_t doesn't have leap seconds. At all. Ever. So from that
perspective, POSIX can't do leap seconds. time_t is so engrained in the
other interfaces of POSIX, they can't have leap seconds either.


> Specifically:
>
>struct tm {
> [...]
>int tm_sec;/* Seconds (0-60) */
>
> gmtime() is perfectly capable of reporting 61 seconds in a minute.
>
> Failure to account for this causes mnay problems.
>
> What it does not do well is accounting for leap seconds that are in
> the past or future.
>

Except that's not a leap second. struct tm doesn't do leap seconds really.
It kinda sorta does, but it kinda sorts doesn't.

First, when you convert back and forth to time_t, you lose leap second
information. It's impossible to convert back and forth from at least the
UTC time zone. There's some 'right' time zones, but they aren't strictly
speaking POSIX compliant because it uses the wrong math. Non-conforming,
but damned useful and not wrong.

Second, many of the tm_ fields can create a time that's N 's in the
future by adding N to that structure and converting. So tm_sec == 60 could
be a leap second, or it could be the second after tm_sec == 59.


> > Right, this is typical for almost any software developed anywhere.
> > Leap seconds are such a weird exception, almost no commercial
> > software, web frontend or backend, or mobile phones, or mobile apps
> > deal with them correctly.
>
> But gpsd and ntpd try real hard to be correct.  Sadly, with leap smear,
> there is no consensus on what is 'correct'.
>

Both leap seconds and leap second smear must die. Others have different
opinions, some strongly held. Not all the contradictory opinions are
necessarily wrong.

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

Re: [LEAPSECS] the inception of leap seconds

[Warner Losh]

On Wed, Aug 15, 2018 at 5:49 AM, Zefram  wrote:

> Another thing missing from the analogy is the distinction
> between arithmetical and observational calendars, which is very relevant,
> UTC being observational and the Julian calendar (the announcement's
> comparand) being arithmetical.


I wish we'd accepted a larger DUT1 variance to allow for a regular schedule
of leap seconds, even if the function changes on the scale of decades. That
would allow one to enshrine into code when the goofy things happen, making
them regular and transforming UTC into an arithmetic calendar, or at least
one that's mostly arithmetic :)

Eg, would we really be worse off if we'd said 'there will be a leap second
every 18 months starting Jan 1 1972? We're 46 years past the start, and
we'd have had 30 leap seconds with that rule, instead of the 27 leap
seconds that have been published. Sure, it's off a little, but on the
average, it's no worse than the amount we get off using the Gregorian
calendar... And this hypothetical assumes that this is how it would have
been from the start of UTC, so it would have been baked into things like
telescopes from the start...

Of course, Tom showed years ago having a different base frequency than
9,192,631,770Hz would have fit the wobble of the earth better, but that was
settled in the late 50s / early 60s so we'd have to go farther back in time
to 'fix' that. IIRC, 9,192,631,850 would have matched the millisecond per
day we're typically slow a lot better and we've had only had the need for 3
or 4 leap seconds...

We're stuck with what we have, though, and a GPS system that reads exactly
0 E/W some 100m from the actual Airy Meridian the tourists (including
recently me) pay to stand on. And yes, I know that abnormality is unrelated
to leap seconds, but it's fun to point out all the "wobbles" when you look
closely at these things...

Warner
___
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

[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

[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

[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] Fwd: IERS Message No. 354: Recent changes to the IERS 14 C04 series / Bulletin B

[Warner Losh]

In short, they used some bad values without realizing it, then followed a
process that was flawed that amplified the bad values. Someone noticed the
small, but accumulating error and they've updated their process and re-run
the numbers.

Did I miss something?

Warner

On Tue, May 8, 2018 at 8:28 AM, Michael.Deckers via LEAPSECS <
leapsecs@leapsecond.com> wrote:

>
>
> On 2018-05-07 12:41, Rob Seaman wrote:
>
>>
>> Anybody have more details about this? How it happened or what it might
>> mean for practical timekeeping?
>>
>> Rob
>>
>> --
>>
>>
>>
>>  Forwarded Message 
>> Subject:IERS Message No. 354: Recent changes to the IERS 14 C04
>> series / Bulletin B
>> Date:   Mon, 7 May 2018 10:57:14 +0200 (CEST)
>> From:   central_bur...@iers.org
>> To: messa...@iers.org
>>
>>
>>
>> 
>> IERS Message No. 354May 07, 2018
>> 
>>
>>
>> Recent changes to the IERS 14 C04 series / Bulletin B
>>
>>
>> Dear IERS users,
>>
>>  From its production in February 2017, 14 C04 nutation was only based
>> upon the IVS combined solution according to a recommendation issued by
>> representatives of IVS and IERS. But, on March 3, 2018 it turned out
>> that IVS combined solution had not been updated since January 13, when
>> Bulletin B was made. So, celestial pole offsets (CPO) were set to zero
>> after this date.
>>
>> In order to fix this problem, on March 3 we run again the C04
>> combination by taking all VLBI solutions, of which the last UT1/CPO
>> determination went back to February 12. So we had to update the C04
>> series from January 13. With this new solution, the pole coordinates and
>> UT1-UTC were slightly changed.
>>
>> There was a also a serious flaw in UT1 values till January 2018, where
>> UT1 intensive values are no more accounted after we wrongly follow an
>> advise of an IVS/IERS representative. Because of the error
>> interpolation, UT1 solution was seriously downgraded between IVS dates.
>> Whereas the precision of UT1 intensive is about 30 micros (against 10
>> micros for R1/R4 UT1), the error introduced by interpolation between two
>> IVS dates is probably much larger. We came to this conclusion, after
>> Frank Reinquin (CNES) put forward an anomalous increase of SLR LAGEOS
>> 1/2 orbital residuals using the 14 C04. Then we discovered that these
>> anomalies were precisely located at the dates where UT1 intensive had
>> been ignored, and replaced by a pure interpolated values between
>> neighbouring R1/R4 sessions.
>>
>> According to the decision of the IERS Directing Board of April 8, 2018
>> the 14 C04 solution for UT1 was modified on April 16, 2018 by including
>> the contribution of UT1 intensive back to 1996. The old version, updated
>> until 2018/04/16 was put in the directory
>> ftp://hpiers.obspm.fr/iers/eop/eopc04/eopc04.2017/.
>>
>
>
> I am just guessing what is meant. Here is my tentative
> de-Frenchification:
>
> [From its production in|Since] February 2017, [|the] 14 C04
> nutation
> [|data for the deviation of the observed celestial
> intermediate pole CIP
> from the pole of the 2006 nutation series] was [only based
> upon|derived
> only from] the IVS combined solution [|for the CIP,]
> [according to|following]
> a recommendation issued by representatives of IVS and IERS.
>
> [But,|Also,] on March 3, 2018 when Bulletin B [|for 2018
> February] was made
> it [turned out|was discovered] that [|the] IVS combined
> solution had not
> been [updated since|kept up to date after] January 13. So,
> celestial pole
> offsets (CPO) were [set to|determined to be] zero after this
> date [|2018-02-13].
> In order to fix this problem, on March 3 we [run|ran] again
> the C04
> combination by taking all VLBI solutions, of which the last
> UT1/CPO
> determination went back to February 12. So we had to update
> the C04
> series from January 13 [|onwards]. With this new solution, the
> pole
> coordinates and UT1-UTC were slightly changed.
>
> There [was a also|also has occurred] a serious flaw in UT1
> values
> [till|before] January 2018, where UT1 [intensive values|values
> derived
> from intensive VLBS observations] [are no more accounted|were
> no longer
> taken into account] after we wrongly follow[|ed] an
> [advise|advice]
> of an IVS/IERS representative. Because of [the error|this
> erroneous]
> interpolation, [|the] UT1 solution was seriously
> [downgraded|degraded in]
> between IVS dates.
>
> Whereas the [precision|uncertainty] of UT1 [intensive|data
> taken from
> intensive VLBR observations] is about 30 micros[|econsds]
> 

Re: [LEAPSECS] Implementation for |UTC-UT1| > 1 s

[Warner Losh]

On Tue, Mar 20, 2018 at 1:59 PM, GERRY ASHTON <ashto...@comcast.net> wrote:

>
> > On March 20, 2018 at 3:07 PM Warner Losh <i...@bsdimp.com> wrote:
> >
> >
> > On Tue, Mar 20, 2018 at 7:59 AM, GERRY ASHTON <ashto...@comcast.net>
> wrote:
> >
> > > Perhaps this is too obvious to mention, but if there is a desire to
> allow
> > > |UTC-UT1| somewhat greater than 1 s, but much less than 1 minute, in
> order
> > > to schedule leap seconds further in advance, it will still be
> necessary to
> > > limit each correction to 1 s. This is because a vast number of
> standards do
> > > not allow the number of the second to reach 61.
> > >
> >
> > I don't see how that follows. The number of seconds in a minute is an
> > orthogonal problem ti DUT1, unless you are proposing multiple leap
> seconds
> > at once...
> >
> > Warner
> > ___
> > LEAPSECS mailing list
> > LEAPSECS@leapsecond.com
> > https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
> Exactly. It would break lots of stuff if, for example, two leap seconds
> were inserted at the end of December 2022. If there was a desire to predict
> leap seconds a full year in advance, and as of mid-December 2021, it
> appeared there would be a DUT of 1.9 s in December 2022, it would be
> necessary to schedule one leap second at the end of December 2022, and
> another at the end of June 2023.


Nobody, but nobody, is suggesting that there be multiple leap seconds at
once (well, apart from the horrible leap hour idea that should be totally
dead). Having multiple leap seconds at random totally defeats the purpose
of allowing DUT1 > 1. It's to allow longer-term scheduling, not to save
them up and do them all at once (again, the silly leap hour notion should
just be ignored as a fig leaf short-hand for 'never do leap seconds again').

The notion of having a larger DUT1 would still have single leap seconds,
but since the evolution of UT1 is effectively a random walk around a long
term average, it would let you schedule 1 leap second every 18 months for
the next decade and know that you aren't walking off entirely, but that you
might have times where the peak error is > 1s (maybe even > 2s, but
certainly < 1minute). We have extremely good confidence that if we did 7
leap seconds between now and 2028, DUT1 then definitely be  < 10s, almost
certainly be < 5s, quite likely be less than 2s and has a good chance of
being < 1s. All 10-year look-back periods fall into these ranges, at least
since 1972, if my quick eye-balling of the data is right.

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

Re: [LEAPSECS] Implementation for |UTC-UT1| > 1 s

[Warner Losh]

On Tue, Mar 20, 2018 at 7:59 AM, GERRY ASHTON  wrote:

> Perhaps this is too obvious to mention, but if there is a desire to allow
> |UTC-UT1| somewhat greater than 1 s, but much less than 1 minute, in order
> to schedule leap seconds further in advance, it will still be necessary to
> limit each correction to 1 s. This is because a vast number of standards do
> not allow the number of the second to reach 61.
>

I don't see how that follows. The number of seconds in a minute is an
orthogonal problem ti DUT1, unless you are proposing multiple leap seconds
at once...

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

Re: [LEAPSECS] UT1 via NTP

[Warner Losh]

On Mon, Mar 19, 2018 at 2:02 PM, Gary E. Miller  wrote:

> Yo Hal!
>
> On Mon, 19 Mar 2018 12:41:46 -0700
> Hal Murray  wrote:
>
> > Perhaps we should setup a simple UDP server that responds with the
> > UT1-UTC offset.  The idea is that you can get a good UTC via GPS or
> > good local NTP servers.
>
> How about the client just downloads the daily UT1 to UTC correction
> data, then adjusts UTC(GPS)?
>
> http://maia.usno.navy.mil/ser7/ser7.dat
>
> Here is a sample of this week's report:
>
>   IERS Rapid Service
>   MJD  xerror yerror   UT1-UTC   error
>"  "   "  "ss
>18  3  9  58186 0.00803 .9 0.36036 .9  0.157823 0.11
>18  3 10  58187 0.00857 .9 0.36159 .9  0.157100 0.06
>18  3 11  58188 0.00974 .9 0.36269 .9  0.156399 0.04
>18  3 12  58189 0.01137 .9 0.36401 .9  0.155694 0.03
>18  3 13  58190 0.01283 .9 0.36560 .9  0.154949 0.65
>18  3 14  58191 0.01385 .9 0.36737 .9  0.154118 0.65
>18  3 15  58192 0.01450 .9 0.36927 .9  0.153196 0.55
>
> Looks to me about a kinda sort maybe 1 micro second per day shift.
>

Should be closer to 1ms/day. And it is: the above is 4.6ms in 6 days or
770us/day.

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

Re: [LEAPSECS] D.H. Sadler in 1954

[Warner Losh]

On Sun, Mar 18, 2018 at 11:12 PM, John Sauter <
john_sau...@systemeyescomputerstore.com> wrote:

> On Sat, 2018-03-17 at 22:52 +, Michael.Deckers via LEAPSECS wrote:
>
> > So, the likely future is that the limit on |UT1 - UTC| will be
> > dropped,
> > leap seconds will no longer be applied, and UTC will become a
> > fixed
> > translate of TAI (so that dissemination of TAI - UTC becomes
> > unnecessary).
>
> I think you are reading too much into the recommendation.  There is no
> mention made of letting UT1 - UTC become unbounded, but only to
> "consider the present limitation on the maximum magnitude of UT1 - UTC"
> and to "improve further the accuracy of the prediction of UT1 - UTC".
>
> Allowing UT1 - UTC to increase from plus or minus 0.9 seconds to plus
> or minus 1.9 seconds would require changes in the protocols used to
> disseminate UT1 - UTC, but it is definitely possible.  Improving the
> accuracy of the prediction of UT1 - UTC is a good idea but may not be
> possible, since predicting the rotation of the Earth is like predicting
> the weather.
>
> In my opinion, the intended future is that the frequency of Bulletin C
> is decreased from twice a year to once a year, or once every two years.
>

As a developer of disconnected systems, I'd love it if they adopted this
change. There's nothing magic about 1s and it was selected for a number of
pragmatic reasons that no longer exist. While there may be a few other
newer reasons to keep it, having good UT1 - UTC mitigates most of them.
Having a loser tolerance means we could do things like having a leap second
every 18 months for the next decade which would help disconnected and
non-updated systems cope better. One of the biggest problems with
implementations getting UTC is that it's an irregular system based on
arcane observations rather than something more predictable like leap
years.  A known rule with a > 6month horizon would help compliance
significantly.

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

Re: [LEAPSECS] [Non-DoD Source] D.H. Sadler in 1954

[Warner Losh]

On Fri, Mar 16, 2018 at 10:16 AM, Matsakis, Demetrios N CIV NAVOBSY, N3TS <
demetrios.matsa...@navy.mil> wrote:

> I was surprised to find phrases in the Lick web pages:  "CCIR ignored the
> advice that astronomers " and "squelched astronomers who insisted that leap
> seconds would cause trouble".
>
> I realize their author is not the only person with a strong emotional
> bias, but even so I question the tone of these web pages because they are
> inconsistent with the following:
>
> 1. There was a progression in thought as technology advanced and atomic
> clocks proved their reliability.
>
> 2. It should be obvious that ephemeris time would need a flywheel system
> to get practical time to the users, and GMT could be part of that.  Today
> individual labs realize UTC(k) for the same reason - to flywheel before the
> monthly computations of UTC are published.  WWVB, GPS, and your local cell
> towers are all part of the system as well.  (Even so, I think everyone
> today agrees that Ephemeris time was a mistake.)
>
> 3.  According to references in Nelson et al’s Metrologia article, which
> was peer-reviewed, it looks to me like the switch to UTC was by universal
> agreement among the institutions.  The IAU, URSI, CIPM(=CGPM), and CCIR(=
> ITU) all agreed to the current system in the late 60's, and I would guess
> that the timing of their resolutions probably depended more on the
> (generally) 3-year spacing of their general assemblies than anything else.
> Note that many of those groups had overlapping membership.  It would
> however be unusual if all individual members of these bodies ever agreed to
> any resolution, even if passed "by consensus".
>

The adaptation of UTC was by consensus. The leap second stuff was a rush
job in 1971 with the first leap second on Jan 1, 1972. I think that rush
job is what the Lick pages refer to.

For more trivia, the dynamic  Gernot Winkler of the USNO was both a
> practical clock man and astronomer.  He was not the only one, and he was a
> very active member of the IAU who chaired commissions, served on working
> groups, etc.  He told me personally that he and Essen independently came up
> with the idea of leap seconds.   He also said a big reason was to win the
> support of the mariners, who in the pre-GNSS days actually did celestial
> navigation and who in the pre-internet days could not easily get access to
> tables that incorporated the difference between UT1 and UTC.
>

UT1 - UTC was known to .1s based on WWV and other broadcasts. At the time,
the < 1s error was so that you limited your error in navigation to
something acceptable. Though one also had LORAN-C (which had it's own
time-scale based on UTC w/o leapseconds to compute the TOCs, but whose
operational bases had atomic clocks set to UTC).

Warner


> To: Leap Second Discussion List
> Subject: [Non-DoD Source] [LEAPSECS] D.H. Sadler in 1954
>
> In 1954 D.H. Sadler produced a monograph on the changes in time
> that had been resolved at the 1952 IAU General Assembly.
> His writeup is clearer than almost anything else for the next 60 years.
> It was published in Occasional Notices of the RAS, and it has been hard
> to find until now.
> https://www.ucolick.org/~sla/leapsecs/twokindsoftime.html
> This is one of the series of documents produced starting in 1948 and
> proceeding through the next 20 years where astronomers explained that
> two kinds of time would be needed to satisfy all applications.
>
> --
> 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 mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap second roundup 2017

[Warner Losh]

On Mon, Oct 23, 2017 at 3:42 PM, Brooks Harris <bro...@edlmax.com> wrote:

> On 2017-10-23 02:07 PM, Warner Losh wrote:
>


> Never has been really, but it was the objective for centuries. Local time
> is obviously a gross approximation, but a very useful one. Before atomic
> time, navigation time (the almanacs) and "civil time" were largely one and
> the same. Leap Seconds decoupled them.
>

Before the 1950's we had no clue the two could be different. The almanacs
were based on how well chronometers could be made, which was on the order
of one second per day or month (especially for mobile clocks). Prior to the
broadcasts of time, you had to base all navigation on local actual solar
time, calibrated to the prime meridian based on celestial observations as
best you can... Leap seconds recognized the reality that the small
variances in earth's rotation add up.

> UT1 isn't a timescale in the strictest sense. TAI and UTC are the same
> timescale, but with different second labeling. Apart from small differences
> in realtime realization, they are always lock step.  UT1 is an artificial
> construct of averaging local time as well, with the seasonal variations
> subtracted out.
>
> As per Richard Langley's note, "UT1 gives us the true orientation of the
> Earth in space as measured (now) directly by space geodetic systems.
>

Yea, I was getting UT1 and UT2 confused.


>
> We have the "smeared timescales" (Google, AWS, Bloomberg, etc). Each
>> generally varies the frequency in the 12 or 24 hours surrounding the Leap
>> Second to "hide" it from the receiving systems. This eliminates the Leap
>> Second from view, reestablishing the Gregorian calendar, and downstream
>> systems and applications behave more reliably. However, these "smears" do
>> not match each other so tractability amongst them and to UTC is
>> compromised, and the frequency shifts are more extreme than might be
>> necessary.
>>
>
> The existence and proliferation of the smears suggest, I would say, that
> leap seconds are not a good fit to a large segment of time users and
> suggests that leap seconds are a poor way to maintain synchronization.
>
> I agree. Leap Seconds have to go, and the 1/86400th of a day of the
> Gregorian calendar must be restored. This is the only feasible way for
> computer systems, applications, and traditional timekeeping systems to
> operate. However, the UTC standard with Leap Seconds cannot be
> significantly changed, as per above. So, I suggest, use DUT1 to define an
> accurate interoperable timescale that is traceable to UTC and better
> reflects the underlying phenomenon..
>
> Use of DUT1 could improve this situation. DUT1 values are announced by
>> IERS, become effective on a specific date, and typically span several weeks
>> or months periods. If the DUT1 values were used to specify a (very slight)
>> frequency shift of the dissemination clock during those intervals the
>> resulting time-points would essentially "slowly smear away" the Leap Second
>> during the entire period between announced Leap Seconds.
>>
>
> DUT1 varies a lot from day to day. It rarely spans even days when you look
> at it at enough resolution. It changes by hundreds of microseconds a day
> typically. The 100ms version that used to be included in terrestrial
> broadcasts
>
> Still is, I'm pretty sure.
>
> may have these properties, but that's a crude approximation.
>
> Ah, no, I don't think that's right, as per Richard's comment above. Look
> carefully at Bulletin D and IERS Conventions. DUT1 stays within 1/10th
> second of UTC. Its not a crude approximation.
>

DUT1 is defined to be UT1 - UTC so I don't see how you can say this.  The
Bulletin D announcements are that the announced value is rounded to the
nearest 1/10th of a second. That's an extremely crude approximation of the
value, and effectively replaces the 1s leap steps with a .1s jump when this
value changes. See column 'UT1 - UTC' in Bulletin B which varies by about
100us a day, with a mean error of about 17us. Computers really need a an
error closer to 1us to have a stable steering loop if you want to have
dissemination of something that closely approximates UT1 without steps, but
17us is likely sufficient.

> Current proposals seek to eliminate the Leap Second, decoupling
>> timekeeping from solar time, or defer the Leap Second, increasing its
>> inaccuracy. Rather than reducing the accuracies, this DUT1 driven timescale
>> idea instead *increases* the accuracies by using higher resolution than one
>> second, essentially "mini-leaps" by frequency shift. My
>> back-of-the-envelope calculations suggest the precision with respect to UTC
>> would be

Re: [LEAPSECS] leap second roundup 2017

[Warner Losh]

On Mon, Oct 23, 2017 at 11:37 AM, Brooks Harris  wrote:

> On 2017-10-23 09:58 AM, Rob Seaman wrote:
>
>> Multiple timescales exist now for multiple purposes. Multiple timescales
>> will exist under all scenarios. Debasing Universal Time is not a
>> solution to any "real world" problem. If you want a new timescale,
>> define a NEW timescale.
>>
>> Indeed.
>

We don't need a new timescale. We have plenty. UTC has always been the best
one to have. It's usefulness isn't because astronomers think it's great (it
is inaccurate, after all, as a Universal Time in the astronomical sense,
but it is useful enough to astronomers as an approximation that certain
optimizations can be made were it not quite so accurate).

To me, the frustrating thing about the discussion at ITU and elsewhere is
> the apparent outright refusal to consider a "second timescale". It is
> considered and then dismissed out of hand in:
>
> Document 7A/39-E
> United States of America
> DRAFT NEW REPORT ITU-R TF.[UTC]
> The International Time Scale, Coordinated Universal Time (UTC)
> https://www.itu.int/md/meetingdoc.asp?lang=en=R15-
> WP7A-C=United%20States%20of%20America
>
> In the last paragraph before the Conclusion they say
>
> "... Another alternative proposed to ensure backward compatibility with
> the current UTC time-scale is to use another international coordinated
> continuous time-scale on an equal basis. This was suggested as a suitable
> method to provide a choice of time scales that could be applied for a
> particular system. The implementation of such an option has not been
> determined as either possible or practical, and the possibility of
> confusing two international standard time scales makes such a solution
> unlikely."
>

I think that is actually quite wise. What time is it really? would replace
the "did we get the leapsecond" when different systems try to exchange data.


> The irreconcilable difficulty arises from UTC being a modification of the
> Gregorian calendar algorithm. The world (mostly) uses Gregorian, but then
> along comes this unpredictable and irregular Leap Second to upset the apple
> cart. No clever algorithm can fit that 86401th second label (23:59:60) back
> into the Gregorian 86400-second-day. The Leap Second must go, and so it
> does, either by ignoring it or smearing it, thereby creating many
> incompatible and inaccurate timescales in the real world.
>

Gregorian, strictly speaking, doesn't have leap seconds. It's just a new
numbering of days to keep the year alignment in sync. It cares not how the
days are divided.


> There are two underlying physical phenomenon; time by atomic science, and
> time by astronomical observation. The counting mechanisms between the two
> are incommensurate because humans (and astronomers) expect the time-of-day
> to indicate the position of the Sun in the sky.  This is not just a matter
> technical considerations but a matter of *principle*.
>

True. Does time measure elapsed time, or the angle of the spinning rock. I
posit that the latter is not interesting so long as the former gives an
answer that's close enough (eg within an hour). Even with leap seconds, we
are only forestalling the time when we must add them so frequently that we
cannot keep up.


> Earlier in the same document they say:
>
> ".. Maintaining a conceptual relation with the Earth’s Rotation Angle
> (represented as UT1) does not appear to be a necessity for the sake of
> civil time."
>
> Isn't that a *value judgement*? It seems its this sort of value judgment
> that upsets many who feel that solar time is important. At the Science of
> Time symposium and elsewhere we've heard many impassioned presentations
> about how important solar time is to humans; practically, culturally, and
> religiously.
>

I happen to think 'uniformity of timescale' is more important than
synchronization to a wobbly rock. But they are right: It doesn't matter
what time the clocks say it is, so long as everybody's clock matches. We
already accept a variance from the local solar time for time zones, and
things like DST suggest that we as a civil society have a tolerance of an
hour or two between observed local time and clock on the wall time. In this
sense, civil time doesn't need to be tied, exactly to the second, to what
the earth is doing. Society will function correctly if the location of the
arbitrary synchronization to a time drifts east a little bit. We'll be good
for thousands of years by that standard. It may be desirable for other
reasons, but it isn't required for a civil time.


> Civilians *want* time to reflect astronomical time in a Gregorian YMDhms
> form. UTC with Leap Seconds has served that purpose admirably for decades,
> tying the worlds timekeeping systems together, albeit imperfectly.  The one
> second accuracy compromise of UTC has long since been accepted as a
> practical matter, and the system has been in effect since 1972. Proposals
> to change it meet with impassioned resistance 

Re: [LEAPSECS] leap second roundup 2017

[Warner Losh]

On Mon, Oct 23, 2017 at 9:00 AM, Poul-Henning Kamp 
wrote:

> 
>
> > By that logic one should avoid intervals spanning the end of February
> > because of leap days, and avoid any periods in the spring or fall (in
> > either hemisphere) that might span local DST transitions, [...]
>
> That is balderdash, and you know it:
>
> We know exactly when leap-days happen, and UTC doesn't have DST.
>

And the rules for leap days are fixed. They don't ever vary like leap
seconds do (since they are inserted observationally rather than
mathematically). Since the rules for leap days are fixed, you can write a
mathematical expression to implement them. And that expression is
relatively simple. And it can be testably verified via testing software.
You can't do that with leap seconds. While the rule for when they might
happen is fixed (though there's some disagreement among sources in end of
month vs primary / secondary times), the timing of them is unknown until 6
months prior. So because of that, nobody tests them: You can't tell me
today that a computer will, with absolute certainty, tick through a leap
second that might or might not happen on Dec 31, 2018. It's physically
impossible because literally nobody knows today that there will be one (or
not) with any certainty. you can't test that before you ship your embedded
system. On the other hand, you do know that Mar 1 follows Feb 28th that
year, but follows Feb 29th in 2020. You can test that before you ship a
system.

Sure, there are methods to distribute the leap seconds. They mostly kinda
sorta work. It's the "mostly" part that I base my statements with the
phrase 'with certainty' on. We're 5 decades on from the implementation of
leap seconds in 1972 and yet they still remain "mostly kinda sorta" working
when you consider all use cases. History has shown this, and likely will
continue to show it. I suspect the only way to get reliable leap seconds is
to say 'For the next decade, we'll do one every 18 months and publish in 5
years what we'll do the following decade' to keep the long-term drift fine,
but at the expense of DUT1 possibly having larger than 1s divergence.
Absent these changes, it will remain flakey and we'll continue to have a
proliferation of 'leap smear' schemes to paper over the leap second at the
expense of frequency stability (since most applications don't care for even
moderate frequency errors).

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

Re: [LEAPSECS] leap second roundup 2017

[Warner Losh]

On Mon, Oct 23, 2017 at 7:28 AM, John Sauter <
john_sau...@systemeyescomputerstore.com> wrote:

> On Sun, 2017-10-22 at 23:46 -0600, Warner Losh wrote:
> >
> >
> > On Sun, Oct 22, 2017 at 11:02 PM, John Sauter <John_Sauter@systemeyes
> > computerstore.com> wrote:
> > > On Sun, 2017-10-22 at 17:53 -0700, Steve Allen wrote:
> > > >
> > > > The BIPM has contributed
> > > > CGPM draft Resolution "On the definition of Time-Scales"
> > > > For two years various meetings have indicated that a document
> > > like
> > > > this was under construction, so this is probably that result.
> > > >
> > > > A draft of the document seems to be at
> > > > http://www.iaufs.org/CCTF%20Recommendation-DRAFT.pdf
> > > > It largely seems to be a formal way for the CGPM to update the
> > > > definition of TAI and UTC to match what the IAU did over a decade
> > > > ago.
> > > > Unsurprisingly it makes no mention of the connection between the
> > > > calendar day and UT1.
> > >
> > > The next-to-last bullet point under "clarifies that" states that
> > > "UTC
> > > is also a means of dissemination of the standard of frequency;
> > > however
> > > this function is limited to intervals that do not contain leap
> > > seconds;".  Why the concern about leap seconds?  As long as you
> > > know
> > > the name of each second, why should it matter that there is a leap
> > > second in the interval?
> >
> > Because one cannot reliably know that. And by reliably, I mean
> > everybody knows, all the software knows, all the software agrees,
> > even among diverse groups whose primary purpose may not be time
> > keeping and may have sloppy habits about leap seconds (eg, the real
> > world).
> >
> > One can know it, sure, but one cannot count on every single other
> > person who touches the data knowing it with certainty. So it's just
> > best to avoid data that spans a leap second.
> >
>
> By that logic, one should avoid any interval that includes June 30 or
> December 31, since such an interval might include a leap second.


Yes. That's the problem with leap seconds.

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

Re: [LEAPSECS] leap second roundup 2017

[Warner Losh]

On Sun, Oct 22, 2017 at 11:02 PM, John Sauter <
john_sau...@systemeyescomputerstore.com> wrote:

> On Sun, 2017-10-22 at 17:53 -0700, Steve Allen wrote:
> >
> > The BIPM has contributed
> > CGPM draft Resolution "On the definition of Time-Scales"
> > For two years various meetings have indicated that a document like
> > this was under construction, so this is probably that result.
> >
> > A draft of the document seems to be at
> > http://www.iaufs.org/CCTF%20Recommendation-DRAFT.pdf
> > It largely seems to be a formal way for the CGPM to update the
> > definition of TAI and UTC to match what the IAU did over a decade
> > ago.
> > Unsurprisingly it makes no mention of the connection between the
> > calendar day and UT1.
>
> The next-to-last bullet point under "clarifies that" states that "UTC
> is also a means of dissemination of the standard of frequency; however
> this function is limited to intervals that do not contain leap
> seconds;".  Why the concern about leap seconds?  As long as you know
> the name of each second, why should it matter that there is a leap
> second in the interval?
>

Because one cannot reliably know that. And by reliably, I mean everybody
knows, all the software knows, all the software agrees, even among diverse
groups whose primary purpose may not be time keeping and may have sloppy
habits about leap seconds (eg, the real world).

One can know it, sure, but one cannot count on every single other person
who touches the data knowing it with certainty. So it's just best to avoid
data that spans a leap second.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Fri, Feb 3, 2017 at 4:30 PM, Brooks Harris  wrote:
> If its after the Leap Second then your method doesn't work directly; you'd
> need to figure it out and make an internal adjustment to the TAI-UTC value a
> second *before* its supplied to you, right? See what I mean?

That would be a problem, yes. However, how do you know it is a leap
second w/o TAI-UTC changing? You'll need that metadata from elsewhere.
To do the leap second correctly, though, you'd need some warning
before the leap second  that it will, in fact, be a leap second.

I'd love to know which spec actually states the offset changes where
you say, since it would resolve the ambiguity. Absent a spec, the
closest thing is decades of Bulletin C.

However, I owe Zefram an apology for being overly grumpy. I thought he
was being deliberately obtuse. In reality, his question TAI-UTC at
23:59:59 proved the undoing of what I was advocating. I'm sorry I
snapped at him. It was uncalled for.

The math works perfectly if you use 60 seconds for the length of the
minute before the leap second (the second he had in mind), and 61
after. Not very satisfying, and a hole I had missed. Thinking through
what that's the case was helpful. It makes some sense that this would
be the case since the leap second isn't part of UTC until it is
inserted. Instead of modify the method to cope, I concluded something
else. It shows the real crux of my misunderstanding of the nature
TAI-UTC.

The problem is a confusion between an interval in UTC time, and a
difference between two time scales when one of the time scales is
using a second label not in the other. A interval in UTC time is well
defined and unambiguous. Applying my method to that problem works
flawlessly (w/o the suggested 60s kludge above) for computation of
intervals within UTC time. Since it works there, one would think it
would be a good fit for TAI-UTC since that looks like an interval.

However, that's not what TAI-UTC actually is. It isn't an interval,
despite being subtraction of two times. They are exactly the same
time, so the interval between them is always 0. TAI-UTC is actually an
offset between two sets of second labels. One can do that math two
ways to get the offset: my way and the conventional way. After reading
the standard, which is silent on the issue, neither is inherently
right or wrong. It's unspecified in TF.460. However, decades of common
usage (Bulletin C) strongly suggests the more conventional way is
what's more accepted. Since there's weirdness in what I was
advocating, and since it flies in the face of tradition, I'll concede
the point.

Sorry for the noise.

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

Re: [LEAPSECS] Negative TAI-UTC

[Warner Losh]

On Tue, Feb 7, 2017 at 12:03 PM, Zefram  wrote:
> Clive D.W. Feather wrote:
>>probability is that TAI-UTC will ever be negative? Should data structures
>>be designed to handle this case or not bother?
>
> Data structures should certainly allow for the possibility, but in
> space-constrained cases can be optimised based on the understanding that
> it's relatively unlikely.  If a fixed-size field is being designed,
> then the range of TAI-UTC values that it can accommodate can be made
> asymmetric, favouring positive values.  An 8-bit field might reasonably be
> made to use excess-32 encoding, encompassing values [-32, 223], giving it
> a good chance of covering the next century's evolution of Earth rotation.
> (8 bits is minimal for that design objective; I'd press for more bits
> if possible.)  A variable-length encoding can in principle cover all
> possible values, but could still benefit by making the representations
> of negative numbers longer than the representations of positive numbers.

So long as after the number is decoded, it's decoded into an signed
number. This is a clever way to get a fuller range of likely leaps
without precluding rare, but possible events.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Mon, Feb 6, 2017 at 10:58 AM, Zefram <zef...@fysh.org> wrote:
> Warner Losh wrote:
>>Saying that the two numbers are the same is improper. Or rather, it
>>depends on which time scale you are looking at them in if they are
>>improper.
>
> The numbers are not on any time scale.  The numbers are derived from
> the time values, but are a different thing.

They are second labels which have different rules for TAI and UTC.

>>However, if you look at the two times in UTC land and compute a delta
>>in UTA land, then you find the interval between N:23:59:60 and
>>N+1:00:00:00 you wind up with 1 second. That leads to the conclusion
>>that the difference starts at the beginning of the leap second.
>
> It does not lead to that conclusion in the general case.  (It does for
> the specific case of TAI-UTC changing from 0 s to 1 s.)  This is one of
> the options for handling TAI-UTC that I examined a few messages ago,
> and it leads to the conclusion that if TAI-UTC is initially positive
> then it increases some seconds *before* the leap second.

Actually it doesn't. I couldn't follow the logic on that argument at
all, so I didn't reply. At worst if you misapplied my method, you'd
get an off by one error.

> I'd examined it
> because it appeared to me that, by consistently using the irregular radix
> for subtraction, it was applying the principle that you were claiming to
> apply, though it leads to a different conclusion from the one you reached.
> (You responded that this was not your system.)

Yea, I've read through your message a couple of times and still don't
understand how you got to where you did.

> I'd still like to see from you a worked example of TAI-UTC for a time a
> few seconds before a positive leap second, where TAI has already ticked
> over into the following day, to compare against an equivalent example
> for a time inside the same positive leap second.  You've done a worked
> example inside a leap second, but not one in the preceding seconds.
> I want to see how you get a different result for 00:00:35-23:59:59 from
> that which you get for 00:00:36-23:59:60.

Sure. I still owe you that, and plan on giving you that. I'm a bit
crunched for time today since I've been working to get a release done
by noon today for the past week (for a problem that exploded into my
lap just after this thread started).

>>can't normalize N:23:59:60 to N+1:00:00:00 because in UTC they are two
>>different second labels.
>
> They certainly are different second labels, and in UTC they even
> label different seconds.  That's not in dispute.  I did not normalise
> one of them to the other.  The equivalence between them is only that
> certain relevant functions of UTC time labels, specifically MJD and its
> equivalents, yield the same value for both of these.  It is via those
> functions that TAI-UTC is tacitly defined.

When you convert to MJD, it appears you are assuming each day has
86400 seconds, which is why two seconds map to the same value.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Mon, Feb 6, 2017 at 6:39 AM, Zefram <zef...@fysh.org> wrote:
> Warner Losh wrote:
>>So either there's some weird math that lets one subtract two numbers
>>that are different and get 0 as the answer, or the delta has to change
>>at the start.
>
> To the extent that they're different, the things being subtracted are
> not numbers.  The expression "TAI - UTC" is shorthand for something more
> complicated than a numeric subtraction, which will nevertheless produce
> a numeric result.  The linear reduction of a timestamp that Clive and
> I have separately described is sufficiently numerical to admit of a
> straightforward subtraction, and the linear reductions of N:23:59:60 and
> (N+1):00:00:00 are duly the same.

Saying that the two numbers are the same is improper. Or rather, it
depends on which time scale you are looking at them in if they are
improper. In UTC they are clearly not the same, but different second
labels. UTC can express this non-sameness. TAI can't do that, so you
have to reduce the improper time to a proper one before you can
compare them. There's two ways to look at it: convert them both to TAI
or convert them both to UTC.

So, if you look at the two times in TAI land, you have to do that
folding of seconds that's implicit in the linearization formula. If
you do that folding of seconds, then the 60 in the irregular radix
takes care of the difference in the first second since you've folded
its value to the value of the first second of the next day. That means
you have to say the difference starts after the leap second.

However, if you look at the two times in UTC land and compute a delta
in UTA land, then you find the interval between N:23:59:60 and
N+1:00:00:00 you wind up with 1 second. That leads to the conclusion
that the difference starts at the beginning of the leap second.

The whole discussion about when the difference starts can be boiled
down to that. What's the proper way to look at it? Depends on how you
do the math to do the conversion to when you use the new offset.

> An analogy: suppose we do a bit of arithmetic in hexadecimal.  We can
> all agree that 0x5a0 - 0x5a0 = 0x0.  Suppose that while keeping the
> hexadecimal radix we additionally use the digit "g", with value sixteen.
> Now we find that 0x5a0 - 0x59g = 0x0.  The difference is zero, yet the
> numbers appear different.  What's going on?  Well, the numbers per se
> are the same: 0x5a0 = 0x59g is a single numerical value.  The things
> that are different are the digit sequences "5a0" and "59g", which under
> the convention being used here are two different ways of expressing that
> single number.  The digit sequences are not themselves numbers.

I think now you're getting confused about irregular radix. If we were
to do that with hex, the number 0x59g would be a non-normalized number
that normalizes to 5a0 because hexadecimal is a regular radix. You
can't normalize N:23:59:60 to N+1:00:00:00 because in UTC they are two
different second labels.

Put another way: it's indisputable that if I have one event at
N:23:59:60.1 and a second event at N+1:00:00:00.6, they happened 1.5s
apart.

Also, I'll note that bulletin C says from 0h, which is a time
expressed to only one significant digit. They chose to not use the
unambiguous 00:00:00 opting for the less precise 0h. If you make the
second folding argument via time linearization, you map both the leap
second and the first second of the next day to the same value. Which
one of those is 0h?

I think the final answer is: It's ambiguous and I was wrong to insist
that there's one true way to recon it.

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

Re: [LEAPSECS] Negative TAI-UTC

[Warner Losh]

On Sat, Feb 4, 2017 at 11:12 AM, Brooks Harris <bro...@edlmax.com> wrote:
> On 2017-02-04 12:24 PM, Warner Losh wrote:
>>
>> On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather <cl...@davros.org>
>> wrote:
>>>
>>> Looking only into the future, not historical data, what do people think
>>> the
>>> probability is that TAI-UTC will ever be negative? Should data structures
>>> be designed to handle this case or not bother?
>>
>> Doubtful, but not impossible.
>>
>> LoD would have to increase significantly for that to happen. The
>> current LoD delta is about 1ms. This looks to vary between -500us to
>> 2ms on IERS' web page (http://hpiers.obspm.fr/eop-pc/index.php).  It
>> also looks like the short term forecast is to return towards 0 in the
>> next 150 days or so. Looking at even longer term data from
>> http://www.usno.navy.mil/USNO/earth-orientation/eo-products/long-term
>> we see huge error bars for LoD just a few hundred years ago and a big
>> drop in deltaT from 1850-1900. So the data we have suggests that it is
>> unlikely, but not outside the realm of possibility.
>>
>> It's quite likely that the first negative leap second would have a
>> much higher bug rate than the current positive leap code which has at
>> least been tested several times and is known to still have issues.
>
> Yes, a negative Leap Second seems especially dangerous to me. How many
> devices and applications have been exhaustively tested for that condition?
> I'd think the IERS should be especially nervous about issuing a negative
> Leap Second. The smears would have to go the other way too.

That's my prediction too. I know that at least some of the code I was
involved with has experienced a negative leap second since we had to
show the contracting office that we could handle a negative leap
second end to end by running our gear in a GPS simulator that lied to
the GPS receiver and told it there was a negative leap second coming.
But I do recall fixing a bunch of bugs to make this possible (by
simulating the GPS putative output and driving the rest of the
software from that). More bugs than I had to fix for positive leap
second testing before 2006...

> What if the negative Leap Second possibility was eliminated from the
> specification so only positive Leap Seconds were allowed? If the DUT1-to-UTC
> <.9s were relaxed, how far from DUT1 might it go? Would it matter, how much,
> and to whom?
>
> That would have a rather significant impact on simplification of
> implementations, eliminating one whole set of cases and test conditions,
> wouldn't it? That could lead to more reliable and uniform behavior, couldn't
> it?

I'd say there'd be some objections from people that need UTC to be
within the arbitrary second of DUT1 since their applications assumed
this to be the case and cannot be adjusted somehow. When I started on
this list, I'd say the list is small, but unknown. After years of
doing this, we know there's some telescopes that cost big bucks to
make, but have proprietary software that assumes UTC == UT1 for
initial coarse aiming and the errors in aiming get too large if that
number grows north of a second. There's also talk of sky facing
applications for near earth objects that need this too, but they also
need the IERS rapid forecast group to give them numbers to within a
millisecond. Plus there's an unknown amount of software that checks to
make sure it is < 0.9s (or maybe 1.0s) or that's in old-school FORTRAN
fixed column format that can't overflow. Plus we don't know how large
a negative offset would be, which would make a lot of people nervous.

If we're looking to relax the magnitude of DUT1, perhaps it would also
be time to make the adjustment algorithmically rather than
observationally? That is, lay out a schedule for N years that's
regular as clock work and adjusted on the 'back end' every few years
if the earth is turning significantly faster or slower than the
prediction... However, I'm not so sure that even this small step is
possible.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Sat, Feb 4, 2017 at 10:32 AM, Steve Summit  wrote:
> Warner wrote:
>> I think this is the crux of my problem with Tom's answer to my first
>> leap second question. We have two times, that are obviously different
>> that when subtracted produce 0 as the answer. x-y = 0 should only be
>> true when x and y are the same. But we get that answer when they are
>> different.
>
> So what about x = 100 degrees Celsius, y = 212 degrees Fahrenheit?
> Two obviously different numbers.  What should the difference be?

That's a bad analogy, because there's a 1:1, onto mapping between the
two. There's also a unit shift involved. And no "leap degrees." And
also, it turns out, universal agreement as to what the right answer
is.

A better analogy would be between Julian and Gregorian calendars. Does
the offset for those increase on Feb 29, 2100 (Gregorian) or on March
1, 2100 (Gregorian)? I suspect we'd have a similar debate about that.

> This is a suggestion, not a proof.  The analogy between
> Celsius-versus-Fahrenheit and TAI-versus-UTC is not at all
> perfect.  And we're dancing around between proofs from first
> principles, versus demonstrations based on what makes the math
> easier.  But I'm afraid the "the numbers are different, so the
> difference can't be zero" argument is not as compelling as you'd
> like.

I guess we're at logger heads then. Any "proof" that involves a lossy
mapping is suspect, imho.

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

Re: [LEAPSECS] Negative TAI-UTC

[Warner Losh]

On Sat, Feb 4, 2017 at 10:24 AM, Warner Losh <i...@bsdimp.com> wrote:
> On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather <cl...@davros.org> wrote:
>> Looking only into the future, not historical data, what do people think the
>> probability is that TAI-UTC will ever be negative? Should data structures
>> be designed to handle this case or not bother?
>
> Doubtful, but not impossible.
>
> LoD would have to increase significantly for that to happen. The

Bah, of course I mean decrease.

> current LoD delta is about 1ms. This looks to vary between -500us to
> 2ms on IERS' web page (http://hpiers.obspm.fr/eop-pc/index.php).  It
> also looks like the short term forecast is to return towards 0 in the
> next 150 days or so. Looking at even longer term data from
> http://www.usno.navy.mil/USNO/earth-orientation/eo-products/long-term
> we see huge error bars for LoD just a few hundred years ago and a big
> drop in deltaT from 1850-1900. So the data we have suggests that it is
> unlikely, but not outside the realm of possibility.
>
> It's quite likely that the first negative leap second would have a
> much higher bug rate than the current positive leap code which has at
> least been tested several times and is known to still have issues.

I should have added a "Yes, make all the things signed." I'd go so far
as to say make them 32-bits, but even 16 bits would be enough for
thousands of years into the future. It would cover thousands of years
into the past even at the most extreme points of the error bars.

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

Re: [LEAPSECS] Negative TAI-UTC

[Warner Losh]

On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather  wrote:
> Looking only into the future, not historical data, what do people think the
> probability is that TAI-UTC will ever be negative? Should data structures
> be designed to handle this case or not bother?

Doubtful, but not impossible.

LoD would have to increase significantly for that to happen. The
current LoD delta is about 1ms. This looks to vary between -500us to
2ms on IERS' web page (http://hpiers.obspm.fr/eop-pc/index.php).  It
also looks like the short term forecast is to return towards 0 in the
next 150 days or so. Looking at even longer term data from
http://www.usno.navy.mil/USNO/earth-orientation/eo-products/long-term
we see huge error bars for LoD just a few hundred years ago and a big
drop in deltaT from 1850-1900. So the data we have suggests that it is
unlikely, but not outside the realm of possibility.

It's quite likely that the first negative leap second would have a
much higher bug rate than the current positive leap code which has at
least been tested several times and is known to still have issues.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Sat, Feb 4, 2017 at 8:37 AM, Clive D.W. Feather  wrote:
> Now define the "linearization" of a broken-down time as:
>
> L = D*86400 + H*3600 + M*60 + S
>
> In TAI, L is the number of seconds since 00:00:00 on the epoch date.
>
> In UTC L is *NOT* the number of seconds since anything useful, but is rather
> just a number that turns out to be useful. With an epoch date of 1970-01-01,
> L gives you the Posix time_t value, but that is not relevant here. It *is*
> important to note that the calculation of L in UTC is lossy in two different
> ways:
> * at a positive leap second, the same L value represents two different times;
> * at a negative leap seconds, some L values don't represent any possible
>   time.
> As we will see, this lossiness turns out not to matter.

That's where you lose me. I believe that it actually does matter since
you encode the extra offset for the leap second into the
linearization, you've hidden the delta such that you have to define
the offset as changing after the leap second for it to work out. I
contend that since the mapping / linearization isn't 1:1 onto, the
proof is not valid. I think this is the crux of my problem with Tom's
answer to my first leap second question. We have two times, that are
obviously different that when subtracted produce 0 as the answer. x-y
= 0 should only be true when x and y are the same. But we get that
answer when they are different. I believe this is can only happen with
a partial ordering. Since UTC is not a partial ordering of the
seconds, I'm not sure that I buy this argument as definitive.

I'll concede this is a convenient computationally.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Wed, Feb 1, 2017 at 11:14 PM, Warner Losh <i...@bsdimp.com> wrote:
> On Wed, Feb 1, 2017 at 10:37 PM, Zefram <zef...@fysh.org> wrote:
>> Warner Losh wrote:
>>>If you are going to willfully misunderstand, then I'm done being patient.
>>
>> I am not willfully misunderstanding.  I have tried to understand
>> what you're doing, and I've been unable to find a system that works
>> consistently, uses the labelling of leap seconds on which we are agreed,
>> and yields TAI-UTC changing at the start of a positive leap second.
>> Please enlighten me.  If you were to supply the couple of worked examples
>> that I have suggested, I believe that would shed much light on your
>> system.
>
> I've already done exactly that. I'll see if I have time tomorrow to
> write it up again using TeX or something that's easier to format and
> explain with than ASCII text. Based on Tom's description of my method,
> I think he may misunderstand it too. It's as consistent as the
> calendar system we have today.

I'm doing a longer write up, but work got crazy...

But consider TAI and UTC when they were equal, for the sake of
argument. I know they never were, but if we look at what the first one
would look like:

TAI  UTC delta
23:59:58 23:59:580
23:59:59 23:59:590
00:00:00 23:59:601
(since how can it be 0 if they are different?)
00:00:01 00:00:001

So either there's some weird math that lets one subtract two numbers
that are different and get 0 as the answer, or the delta has to change
at the start.

It's understanding what the weird math is that I'm having trouble with
for people that say it is after the leap second that the delta
changes.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Wed, Feb 1, 2017 at 10:37 PM, Zefram <zef...@fysh.org> wrote:
> Warner Losh wrote:
>>If you are going to willfully misunderstand, then I'm done being patient.
>
> I am not willfully misunderstanding.  I have tried to understand
> what you're doing, and I've been unable to find a system that works
> consistently, uses the labelling of leap seconds on which we are agreed,
> and yields TAI-UTC changing at the start of a positive leap second.
> Please enlighten me.  If you were to supply the couple of worked examples
> that I have suggested, I believe that would shed much light on your
> system.

I've already done exactly that. I'll see if I have time tomorrow to
write it up again using TeX or something that's easier to format and
explain with than ASCII text. Based on Tom's description of my method,
I think he may misunderstand it too. It's as consistent as the
calendar system we have today.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Wed, Feb 1, 2017 at 8:12 AM, Steve Summit  wrote:
> Part of the problem, as Zefram has pointed out, is that when we
> attempt to compute 00:00:36 minus anything, we're subtracting a
> relative time from an absolute TAI time, which gives us another
> absolute TAI time, *not* a UTC time.  So the method is already
> suspect.

I strongly disagree with this assertion. We're subtracting the time,
and converting bases from the regular radix of TAI to the irregular
radix of UTC at the same time.

In other words, the conversion process isn't just subtracting two
times in a vacuum, as I've explained already. My method is
self-consistent and produces the correct answers. It maps the TAI
sequence of second labels to the UTC sequence of second labels. It
doesn't just produce another absolute TAI time. Since Zefram's whole
complaint is based on that misunderstanding, I can offer no further
critique.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Wed, Feb 1, 2017 at 1:50 AM, Zefram <zef...@fysh.org> wrote:
> Warner Losh wrote:
>>I'd suggest that you re-read what I wrote, because these two
>>paragraphs do not represent that at all.
>
> It certainly involves a different result from what you stated, but as
> I said, your result doesn't seem to follow from the principle that
> you stated.  Rereading, my view of your statements hasn't changed.
> Of course it's conceivable that I didn't grasp your intent, in which
> case I still don't.
>
> You never explicitly performed the computation for an example such as my
> case of 2016-12-31T23:59:59.0 UTC, 2017-01-01T00:00:35.0 TAI.  Perhaps you
> could clarify your intent by walking through the computation of TAI-UTC
> for that instant, contrasting it with the equivalent computation for
> 2016-12-31T23:59:60.0 UTC, 2017-01-01T00:00:36.0 TAI.  Or, if you prefer,
> walk through the computations of the UTC values from the TAI and TAI-UTC
> values for those instants.
>
>>For a negative leapsecond, it's clear that the offset changes at the
>>end of :58 second. Briefly, you are adding two to get the next second
>>instead of the customary one.
>
> "Adding two to get the next second" implies the use of the regular
> 60-second radix.  That's not compatible with your system of `borrowing'
> in the irregular radix.
>
>>My irregular-radix system?
>
> The aspect of this that I'm attributing to you is the use of the irregular
> radix for the arithmetic around the TAI-UTC difference.

If you are going to willfully misunderstand, then I'm done being patient.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Tue, Jan 31, 2017 at 11:02 PM, Zefram <zef...@fysh.org> wrote:
> Warner Losh wrote:
>>Only for time_t computations.
>
> The POSIX expression for time_t, if taken entirely literally, does the
> same thing.  But that's not the only use of a scalar behaving in this way.
>
>>  "reducing to a scalar value" unfortunately doesn't map
>>1-1 onto UTC.
>
> Right.  The scalar form does not adequately represent UTC.  Fully
> representing a UTC time requires at minimum two parts: an integer
> identifying the day and a continuous value identifying the time of day.
> All uses of expressions that treat UTC as a scalar, such as "TAI - UTC"
> and "UT1 - UTC", need to be interpreted carefully, with the understanding
> that contextual information is required to perform a complete conversion.
>
>> TF.460 says nothing about this.
>
> Indeed.  It makes some mention of TAI-UTC, but is not explicit about
> the details of what that means.  It does say that it's always integral,
> but doesn't say when it changes.  That is an unfortunate omission.
>
> It is the common practice, in IERS documents and elsewhere, not a formal
> standard, that establishes this usage.  One is also guided towards
> this by its mathematical coherence, which of course is why it became
> common practice.  Your way, doing the arithmetic in the irregular radix
> implied by the sequence of UTC time labels, leads to more discontinuities.

If it isn't in the standards documents, it's informal usage. While
useful in conversation, it can (and often does) lack the rigors
necessary to unambiguously implement the standard.

> Let's consider (again) the 2016-12-31 leap.  One second after the end of
> the leap second we have (uncontroversially) UTC = 2017-01-01T00:00:01.0,
> TAI = 2017-01-01T00:00:38.0, TAI-UTC = 37 s.  In the middle of the leap
> second, 1.5 s earlier, we have UTC = 2016-12-31T23:59:60.5 and TAI
> = 2017-01-01T00:00:36.5.  For you to derive TAI-UTC = 37 s as you do
> essentially requires that we interpret that TAI label as if it were a UTC
> label and ask how many seconds there are between these two UTC labels.
> That's what using the irregular radix amounts to.  OK, that gets 37 s.
> Now let's go back another 1.5 s, to a point one second before the
> start of the leap second, and continue working that way.  We have UTC
> = 2016-12-31T23:59:59.0, TAI = 2017-01-01T00:00:35.0.  The difference
> between these two timestamps, taking account of the irregular radix,
> is *still* 37 s, made up of 2 s from 23:59:59.0 to 00:00:00.0 plus 35
> s from 00:00:00.0 to 00:00:35.0.
>
> So in your system the discontinuity in TAI-UTC is not, as you
> stated, at the beginning of the leap second.  Working backwards,
> we find that TAI-UTC actually changed at 2016-12-31T23:59:24.0 UTC,
> which is 2017-01-01T00:00:00.0 TAI.  At that instant we have (still
> using the irregular radix) a 37 s difference in the time labels.
> Half a second earlier we have UTC = 2016-12-31T23:59:23.5 and
> TAI = 2016-12-31T23:59:59.5, with an uncontroversial difference
> of 36 s.  Essentially, your system perceives UTC as a continuous
> scalar, and perceives a discontinuity in *TAI*, where it jumps
> from 2016-12-31T23:59:59.9 to 2017-01-01T00:00:00.0.  TAI omits
> a second's worth of time labels supplied by the irregular radix,
> 2016-12-31T23:59:60.0 to 2016-12-31T23:59:60.9.

I'd suggest that you re-read what I wrote, because these two
paragraphs do not represent that at all.

> A negative leap is worse, because TAI takes on labels that don't exist
> in the irregular radix.  How do you account for that?  If we permit
> the out-of-radix :59, with its apparent numerical value, then we find
> that the notional TAI scalar repeats a second's worth of values, with
> out-of-radix notation being used to distinguish the two instances of
> those scalar values.  Any computation that produces this TAI scalar in
> its pure form cannot be used to unambiguously decode a TAI time.

For a negative leapsecond, it's clear that the offset changes at the
end of :58 second. Briefly, you are adding two to get the next second
instead of the customary one. In that case, it's clear that one comes
from the normal increment and the other one comes from decrementing
the TAI-UTC offset.

> Essentially, your irregular-radix system has the same problems for
> which you deride the regular-radix system.  The difference between the
> systems is in to which time scale they attribute the discontinuities
> that arise in TAI-UTC.  Performing the computations using the regular
> radix attributes them to UTC.  Using the irregular radix attributes the
> discontinuities quite unfairly to TAI.

My irregular-radix system? Nah, I can't take

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Tue, Jan 31, 2017 at 8:24 PM, Zefram <zef...@fysh.org> wrote:
> Warner Losh wrote:
>>changes at the start of the positive leap second, or at the start of
>>the first second after a negative label has been removed. Otherwise
>>the irregular radix math doesn't work out.
>
> The maths isn't done in the irregular radix.

What standard says that?

>  For the purposes of
> expressions such as "TAI - UTC" that require a UTC time to be reduced to
> a scalar value, that scalar is derived using the regular radix values.
> This means that, yes, 2016-12-31T23:59:60 and 2017-01-01T00:00:00 have the
> same scalar value.  The jump of TAI-UTC up by 1 s causes the repetition
> of the preceding 1 s worth of UTC scalar values.

Only for time_t computations. That's a very interesting conversation,
but that's a different conversation. TF.460 says nothing about this.
It only defines how seconds are labeled around a leap second. UTC has
a list of second labels. These second labels are an irregular radix,
and if you want to mechanically convert the TAI second labels to the
UTC second labels, you have to play that insane game, or a game that
maps onto it. "reducing to a scalar value" unfortunately doesn't map
1-1 onto UTC. Since it isn't 1-1, onto, it can't be standards
conforming which defines a 1-1 / onto mapping both ways between TAI
and UTC.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Tue, Jan 31, 2017 at 12:57 PM, Brooks Harris  wrote:
> On 2017-01-31 02:50 PM, GERRY ASHTON wrote:
>>>
>>> ...On January 31, 2017 at 7:08 PM Steve Allen  wrote in
>>> part:
>>> I prefer to think of a leap second as being truly intercalary.
>>> It is saying to atomic clock "It's not tomorrow yet, wait a second."
>>> It is between one calendar day of UTC and the next calendar day of UTC.
>>> It belongs to neither of them...
>>
>> UTC is civil time. Civil time is used to express deadlines. Most deadlines
>> fall at the end of a calendar day, so which day the 61st second falls in
>> will only affect a few time zones, but deadlines may fall on other hour
>> boundaries. So it is necessary to know which hour the 61st second belongs
>> to, and I believe it belongs to the hour that is about to end.
>
> I don't think anyone disagrees that the Leap Second is the last second of a
> day, "pushing" the midnight roll-over. That's clear from Rec 460. But when
> the TAI-UTC value increments is an important question.

It increments in such a way that the math for conversion works between
the two. That's the start of the leap second. One might informally say
that the increment is at the start of the day as a convenient
shorthand, but if that short hand results in wrong answers, that
shorthand is not what should be used to compute the answer.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Tue, Jan 31, 2017 at 12:50 PM, Brooks Harris <bro...@edlmax.com> wrote:
> On 2017-01-31 02:19 PM, Warner Losh wrote:
>>
>> On Tue, Jan 31, 2017 at 12:08 PM, Steve Allen <s...@ucolick.org> wrote:
>>>
>>> On Tue 2017-01-31T13:58:15 -0500, Brooks Harris hath writ:
>>>>
>>>> Ah, so who's right?
>>>
>>> I prefer to think of a leap second as being truly intercalary.
>>> It is saying to atomic clock "It's not tomorrow yet, wait a second."
>>> It is between one calendar day of UTC and the next calendar day of UTC.
>>> It belongs to neither of them.  The tag 2016-12-31T23:59:60 is merely
>>> a way of indicating which two days it is between.
>>> It is unfortunate that nobody thought this stuff through in 1969 when
>>> the decision was made to implement the leap second, and no matter how
>>> it is expressed, encoded, and calculated it will be a special case.
>>
>> Philosophically you may be right.
>
> It doesn't seem philosophical to me. Its obviously a special case, a special
> case of interoperablity decreed by the IERS.
>>
>>
>> Mathematically, however, I don't think that makes much sense. :60 is
>> an irregular radix. It's clearly added to the prior day, just like Feb
>> 29th is part of February.
>
> Yes.
>>
>> Also, doing the long-hand math on the
>> irregular radix, it also makes sense to have it be part of the prior
>> day
>
> It is, right? And that's what Rec 460 clearly says.
>>
>> and to increment the offset at the start of the leap second.
>
> Not necessarily.
>
> What part of Gregorian YMDhms or DST makes any "sense"? They are unavoidable
> conventions, wacky unavoidable conventions with mixed radix components and
> deceptive algorithmic rules. UTC with Leap Seconds alters those conventions
> slightly. Why would we expect it to "make sense"?

"Math is hard"?

When you view it through the lens of the irregular radix that UTC time
of day is, the math falls out naturally.  The points of irregularity
are the wacky stuff. Not what to do when you have one.

> I think Bulletin C says the TAI-UTC value increments at the start of the
> day:
>
> " UTC TIME STEP on the 1st of January 2017" and
> "from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s ".
>
> It doesn't say "the second before 2017 January 1".

Honestly, it isn't specific enough. It's specifying that on end of the
month a leap second is inserted. Anything beyond that is at best
informational since otherwise it would contradict TF.460. This is a
convenient shorthand, nothing more. In order for the math to work out,
the offset has to change at the start of the second.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Tue, Jan 31, 2017 at 12:41 PM, Brooks Harris <bro...@edlmax.com> wrote:
> On 2017-01-31 02:04 PM, Warner Losh wrote:
>>
>> On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <bro...@edlmax.com> wrote:
>>>
>>> On 2017-01-31 12:33 PM, Warner Losh wrote:
>>>>
>>>> On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit <scs...@eskimo.com> wrote:
>>>>>
>>>>> Tom Van Baak and Michael Decker wrote:
>>>>>>>>
>>>>>>>> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
>>>>>>>
>>>>>>> What kind of arithmetic is that?
>>>>>
>>>>> I think it ends up being roughly the same kind of arithmetic
>>>>> that tells you that the 60th day of the year is March 1.
>>>>> Or maybe February 29.
>>>>
>>>> Maybe he's referring to the fact that the offset is 37s, not 36s. The
>>>> offset changes AT THE START OF THE LEAP SECOND.
>>>
>>> OK, now here's something I've been worrying about for a long time.
>>> Everyone
>>> on LEAPSECS, and seemingly everywhere else in the literature, are *sure*
>>> they know exactly what UTC with Leap Seconds is. Yet the specifications
>>> are
>>> unclear, as we've been discussing.
>>>
>>> Here you are saying "The (TAI-UTC) offset changes AT THE START OF THE
>>> LEAP
>>> SECOND. " That is in direct conflict with my best understanding of it.
>>> I'd
>>> say "The (TAI-UTC) offset changes immediately AFTER the Leap Second, at
>>> the
>>> midnight roll-over to the first second of the next month." (See other
>>> email
>>> with my explanation and demonstration code).
>>
>> That code isn't doing what you think it is, at least imho. By knowing
>> it's a leap second and adding 1, you've just made a complicated
>> adjustment that would be unnecessary if the offset changes at the
>> start of the leap second. Effectively you've "corrected" knowing it's
>> a leap second by changing the answer by one. That's exactly the same
>> as saying the offset is one greater one second earlier and eliminating
>> the special case. In both cases, you have to know that the last minute
>> has 61 seconds.
>
> Yeah, but I think that's what the specification say.

All the specifications says is that positive leap seconds cause the
minute to have 61s.

>>>
>>> So, this is obviously a huge interoperablity issue. It has ramifications
>>> through many aspects of timekeeping manipulations.
>>
>> I don't think so. It's all about how you do the math and the final
>> answer.
>
> I think its about how you *receive* the information too, not just the YMDhms
> (UTC) result. What information is supplied by NTP or GPS? You've got to know
> exactly when to apply the Leap Second. In the case of a hypothetic Leap
> Second aware timestamp you need the metadata: TAI-UTC and one of
> IsLeapSecond or IsLeapSecondMinute (like a "61" flag) or IsLeapSecondDay.
> But the question is, on which timestamp does TAI-UTC increment?

It increments just prior to the positive leap second. It doesn't
matter how you get the information. That's when the offset needs to
change for the irregular radix math to work.

Or put less authoritatively: why would it matter how you get the
information? A second is either a leap second or it isn't, right? And
the property of a second that makes it a leap second in UTC is that's
when the offset changes against TAI.

We know that

UTC = TAI + UTC_OFFSET(TAI)

Since UTC is an irregular radix, the math is a little complicated, but
the only way for the above to work out is if UTC_OFFSET(TAI) changes
at the start of the leap second. So going from 36 to 37, the way you
get :60 is by subtracting 37 from TAI instead of 36.

>>
>> My interpretation leads to simpler math.
>
> Simpler math for what purpose? A bit simpler to calculate YMDhms (UTC)
> maybe, I'd have to work it through.

It's the only way to encode one number such that the irregular radix
math works out. And treating a positive leap second 'special' that
needs an extra decrement is isomorphic to changing the delta at the
start of the second.

> Of course you can treat it anyway you
> like internally as long as two applications wind up with *exactly* the same
> results. But they have to agree when TAI-UTC updates, at least as far as any
> interchange mechanism in concerned, right?

I think that the standard and standard math concepts of irregular
radix would dictate all that. How you encode your internal tables is
up to you, so long as they are isomorphic to what

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Tue, Jan 31, 2017 at 12:08 PM, Steve Allen  wrote:
> On Tue 2017-01-31T13:58:15 -0500, Brooks Harris hath writ:
>> Ah, so who's right?
>
> I prefer to think of a leap second as being truly intercalary.
> It is saying to atomic clock "It's not tomorrow yet, wait a second."
> It is between one calendar day of UTC and the next calendar day of UTC.
> It belongs to neither of them.  The tag 2016-12-31T23:59:60 is merely
> a way of indicating which two days it is between.
> It is unfortunate that nobody thought this stuff through in 1969 when
> the decision was made to implement the leap second, and no matter how
> it is expressed, encoded, and calculated it will be a special case.

Philosophically you may be right.

Mathematically, however, I don't think that makes much sense. :60 is
an irregular radix. It's clearly added to the prior day, just like Feb
29th is part of February. Also, doing the long-hand math on the
irregular radix, it also makes sense to have it be part of the prior
day and to increment the offset at the start of the leap second.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <bro...@edlmax.com> wrote:
> On 2017-01-31 12:33 PM, Warner Losh wrote:
>>
>> On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit <scs...@eskimo.com> wrote:
>>>
>>> Tom Van Baak and Michael Decker wrote:
>>>>>>
>>>>>> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
>>>>>
>>>>> What kind of arithmetic is that?
>>>
>>> I think it ends up being roughly the same kind of arithmetic
>>> that tells you that the 60th day of the year is March 1.
>>> Or maybe February 29.
>>
>> Maybe he's referring to the fact that the offset is 37s, not 36s. The
>> offset changes AT THE START OF THE LEAP SECOND.
>
> OK, now here's something I've been worrying about for a long time. Everyone
> on LEAPSECS, and seemingly everywhere else in the literature, are *sure*
> they know exactly what UTC with Leap Seconds is. Yet the specifications are
> unclear, as we've been discussing.
>
> Here you are saying "The (TAI-UTC) offset changes AT THE START OF THE LEAP
> SECOND. " That is in direct conflict with my best understanding of it. I'd
> say "The (TAI-UTC) offset changes immediately AFTER the Leap Second, at the
> midnight roll-over to the first second of the next month." (See other email
> with my explanation and demonstration code).

That code isn't doing what you think it is, at least imho. By knowing
it's a leap second and adding 1, you've just made a complicated
adjustment that would be unnecessary if the offset changes at the
start of the leap second. Effectively you've "corrected" knowing it's
a leap second by changing the answer by one. That's exactly the same
as saying the offset is one greater one second earlier and eliminating
the special case. In both cases, you have to know that the last minute
has 61 seconds.

> So, this is obviously a huge interoperablity issue. It has ramifications
> through many aspects of timekeeping manipulations.

I don't think so. It's all about how you do the math and the final
answer. My interpretation leads to simpler math.

> Ah, so who's right?

IMHO, if you do the math out long hand, you'll see I'm right. See
other mail where I walk through it (though perhaps in a difficult to
follow way due to the limits of email).

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak  wrote:
>>> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
>>What kind of arithmetic is that?
>
> Hi Michael,
>
> First, there's no problem with this, right?  (Thanks to Steve for catching 
> typo)
>
> 2017-01-01T00:00:35.5 TAI = 2016-12-31T23:59:59.5 UTC
> 2017-01-01T00:00:36.5 TAI = 2016-12-31T23:59:60.5 UTC
> 2017-01-01T00:00:37.5 TAI = 2017-01-01T00:00:00.5 UTC
>
> Now, we want to use "UTC = TAI + (UTC - TAI)" notation. So which is correct:
>
> 2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
> 2017-01-01T00:00:36.5 TAI - 36 s = 2016-12-31T23:59:60.5 UTC  ??
> 2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC
>
> or
>
> 2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
> 2017-01-01T00:00:36.5 TAI - 37 s = 2016-12-31T23:59:60.5 UTC  ??
> 2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC
>
> Neither one is particularly clear to me. Of course in real code it all works 
> because you special case the leap second label discontinuity and make it 
> work. In a sense you replace normal sexagesimal arithmetic with 59-gesimal or 
> 61-gesimal arithmetic for that one minute. But, yeah, I can see that it 
> complicates prose and equations regarding UTC-TAI offsets.

I think it has to be the second one because when you work through the
math, it works out.

The math simply doesn't work out for the former. 36-36 is 0, which you
have to somehow know means 60. That's nuts, imho. However, 36-37 is
-1. When you have an underflow, you have to borrow from the previous
minute. That minute has 61 seconds, which when added to -1 gives 60,
which is the correct answer.

Otherwise you are in special case hell where you know there's a leap
second so you add one more, which is solved nicely by just bumping the
offset at the start of the leap second.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Mon, Jan 30, 2017 at 6:06 AM, Tony Finch  wrote:
> Michael.Deckers. via LEAPSECS  wrote:
>>
>>My point was that Arias' labeling makes it clear that the
>>latest discontinuity in TAI - UTC occurred when TAI assumed
>>the value 2017-01-01 + 36 s. The ITU labeling (nor any
>>other specification in ITU-T TF.460-6) does not imply the precise
>>instant of the discontinuity, nor does IERS Bulletin C52.
>
> It's tricky. Bulletin C is pretty clear about when it thinks TAI-UTC
> changes:
>
>   from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC   : UTC-TAI = - 36s
>   from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s
>
> However, since there isn't any TAI time with a :60 seconds label, it
> doesn't make much sense to have a defined delta for the last UTC second
> of 2016.

I disagree with this. It makes perfect sense to have a defined delta
for the last UTC second of 2016. And it is 37s because the delta
changes at the start of the positive leap second, or at the start of
the first second after a negative label has been removed. Otherwise
the irregular radix math doesn't work out. It is the change in both
cases that accomplish the leap second. The delta is always defined,
and the points that the delta change lets you know how many seconds
were in that final minute.

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

Re: [LEAPSECS] alternative to smearing

[Warner Losh]

On Thu, Jan 12, 2017 at 9:12 AM, Clive D.W. Feather  wrote:
> Preben Nrager said:
>> If you don't care about Christ, and the church, I can understand why you
>> treat all timescales alike. But if you really care about the fundamental
>> timescale of science and society, then I don't see how you can ignore the
>> time of the incarnation.
>
> If you really want the fundamental timescale of society, then your zero
> point should be the date of the first creation of the world by his Supreme
> Noodliness the FSM.

While calendar discussions are interesting, and sometimes relevant to
leap seconds, I'm pretty sure that we've left the main area of this
list: the complete and total elimination of leap seconds in our
lifetime, or universal implementation of them in the face of many
difficulties that aren't obvious from first principles. :)

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

Re: [LEAPSECS] next leap second

[Warner Losh]

On Wed, Jan 11, 2017 at 3:28 PM, Zefram  wrote:
> It would be nice to have more sophisticated projections from IERS more
> than a year ahead.  It would particularly help in evaluating the proposals
> that have been made involving scheduling leap seconds further ahead.

Especially if they had error bars that reflect the current confidence
levels, perhaps tested on historic data.

It would be really useful for IERS to say UT1-TAI = 75s +/- 20s at
AD2100 at 1000s at AD3000 (or whatever the numbers are). I realize
there's two sources of error here: crazy variations in the future
evolution of the earth's rotation as well as legitimate interpretation
differences of historical data. However, we know with a high level of
certainty that in AD3000 the difference isn't going to be 100s, nor
will it be 10,000s, and certainly not 100,000s. There's a range of
predictions, as numerous papers posted here have shown, and it may be
useful to have data on that.

But even short range predictions of the next decade or two would be
useful... If nothing else, it would help us test the state of the art
in prediction.

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

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

Keep in mind that leap seconds have a short shelf life. Over the next
1000 years, it's projected TAI - UT will grow to about an hour
(2500-4500 if I'm reading
https://www.ucolick.org/~sla/leapsecs/deltat.html right). In two
thousand it will be about 4 hours due to quadratic acceleration.
That's ~10k seconds in 1k years, or about one per month. The current
UTC spec will run out of steam long before then, as it defines only 4
times to insert leap seconds (well, 4 preferred times, any month can
be victim). Needing 12 per year means we're driving at about 1s/month
which means that keeping DUT1 to < 0.9 will be a challenge due to
seasonal variation and such. The Nyquist limit suggests that we'll run
out of steam when we hit one every 6 months, which would be about
~1200 years from now (give or take a few hundred, there's a lot of
uncertainty in the long term rate). Some new means of synchronization
must be found, the only real question is when. Well before that date,
letters from BIPM/IERS will cease to cut it (I'm in the camp that says
we're already past that date: no reliable[*] means to get leap seconds
exists today from authoritative sources).

Warner

[*] By this I mean some non-forgeable, authoritatively signed by
BIPM/IERS table of leap seconds, automatically updated and an
official, guaranteed service of the agency.

On Fri, Jan 6, 2017 at 12:29 PM, GERRY ASHTON  wrote:
> The Gregorian calendar and UTC with leap seconds are in harmony; the 
> customary change-of-day time with the Gregorian calendar is midnight, and the 
> methods used to establish midnight throughout most of the time the Gregorian 
> calendar has been in use did not approach accuracy of tens of seconds. It is 
> TAI or other 86,000-SI-seconds-per-day time scales that will not be in 
> harmony with the Gregorian calendar in hundreds or thousands of years when 
> the difference between mean solar time and 86,000-SI-seconds-per-day time 
> scales becomes appreciable ("appreciable" literally being a religious issue).
>
>> On January 6, 2017 at 5:50 PM Brooks Harris  wrote:
>>
>>
>> On 2017-01-05 09:33 PM, Steve Summit wrote:
>> > Brooks Harris wrote:
>> >> It seems to me infeasible to alter the basic behavior of time_t
>> >> because it effects every aspect of the operating system,
>> > Absolutely.  Posix time_t is untouchable, and here to stay.
>> >
>> >> POSIX time and 86400-second-day systems (including Windows time) will
>> >> never exactly  match UTC at the Leap Second and we'll have to live
>> >> with that partial inaccuracy for a long time.
>> > Right.  (But I don't know if people will find the inevitable
>> > discrepancies between time_t and "Time2" acceptable.)
>> That's been at the heart of the "eliminate Leap Seconds debate", right?
>> Two camps, basically. But given both UTC with Leap Seconds and Gregorian
>> as inevitable conventional circumstances its no longer a question of
>> acceptable or not. It is what it is, so lets agree how best to support
>> the two with the least inaccuracy, least complexity, and least
>> disruption to existing systems. It can't be perfect; the two just do
>> not, and will not, match. There's not enough holes in Gregarian to
>> accommodate the Leap Second pegs.
>>
>> >
>> >> But a second, parallel, time system (call it POSIX Time2) could
>> >> implement a fixed-epoch timer (call it time2_t) and a
>> >> Leap-Second-accurate API that would yield YMDhms representation
>> >> including 23:59:60, call them, for examples, gmtime2() and mktime2().
>> > That's essentially what clock_gettime(CLOCK_UTC) gets you.
>> > A struct timespec fetched with clock_gettime(CLOCK_UTC) is your
>> > "POSIX Time2".  I have implemented gmtime_ts_r() and mktime_ts()
>> > which operate on struct timespec, and do the right thing with :60.
>> Ah good.
>>
>> What source are you using for the Leap Seconds? Tz Database?
>>
>> >
>> >> With that, those applications that needed it could use the POSIX Time2
>> >> API, and everybody else would be none the wiser. It would also define
>> >> the mapping between legacy POSIX and the UTC-accurate POSIX Time2.
>> > That's exactly my intent, and I have it all working on my test
>> > system today.  Just one or two more bugfixes and I should be
>> > ready to post it!  (I've been saying for the past several months.)
>> Its a harder problem than it appears, as those of us who've got our
>> fingers dirty with the implementation details can attest. Going at it
>> directly in the OS takes guts :-)
>> >
>> >> Eventually, maybe the file system timestamps could be augmented with
>> >> flags to mark Leap Second instances and local time parameters.
>> > I'm not ready to think about the filesystem yet (beyond thinking
>> > that leapsecond-aware filesystem timestamps don't seem nearly as
>> > important).
>> I think the challenge inevitably arrives at the file system(s), so a
>> comprehensive plan should anticipate how that could eventually be
>> accomplished. This is 

Re: [LEAPSECS] alternative to smearing

[Warner Losh]

On Thu, Jan 5, 2017 at 4:26 AM, Hal Murray  wrote:
>
> [do something N years in the future]
>> Except that's not how things are programmed. Programming it that way would
>> be very inefficient in a part of the kernel that has to be ultra-efficient.
>> Since you don't know how many seconds it will from now, you can't schedule a
>> timeout. The current setup of UTC doesn't let me know how many seconds it
>> will be in the future. People can talk about it, but computers don't always
>> store things that way. ...
>
> Are there any performance critical chunks of code that want to wait until N
> years from now?  I doubt it.

With due respect, that's a crappy attitude to getting something right.
You want to have one interface that always works that's easy to use
and schedule with. If you don't have that, then your software is more
likely to break. IMHO, that's yet another example of the "it's only a
second" attitude that keeps us from having nice things like a working
UTC implementation on Unix.

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

Re: [LEAPSECS] alternative to smearing

[Warner Losh]

On Thu, Jan 5, 2017 at 3:42 AM, Hal Murray  wrote:
>
>> 1) The leap day in February can be handled by any isolated or autonomous
>> clock or timekeeping system. A leap second can only be handled with periodic
>> direct or indirect communication with IERS, or manual intervention with the
>> likes of keyboard input or toggle switches. For secure or embedded systems
>> this is a huge issue.
>
> If a system is isolated, does it matter if its clock knows about leap seconds?
>
> I could imagine that "isolated" meant nothing goes in for security reasons, 
> but then time doesn't go in either.  So maybe you allow GPS to go in the back 
> door, but that has leap info.

While still operational, LORAN-C timing stations were all isolated
systems. They needed to know the leap second data for a variety of
reasons. One of those reasons was that we had to be able to replace
the GPS receiver module at any time. It was replaced with a 'cold
spare' from the shelf, which might not have the most up-to-date leap
information on it. It was not possible to rotate all the spares in and
out every 6 months to get the new data for a variety of reasons I need
not go into here. These GPS receivers needed about 12.5 minutes to get
the proper UTC offset since cold ones had no valid almanac, and we
weren't allowed to have it get it from the network (not even one of
the 3 other redundant systems on said network that could have the
right data). This meshed poorly with a requirement that the GPS
receiver must report UTC time within 1 minute of the power being
applied to it, as you might imagine...

GPS also doesn't provide leap second tables. Just current and maybe
future offsets. It's often enough, but not universally enough.

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

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit <scs...@eskimo.com> wrote:
> Warner Losh wrote:
>> On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit <scs...@eskimo.com> wrote:
>> > 2. Have xtime keep TAI.  This has the advantage that it's not at
>> >all wrong or kludgey to represent TAI as a simple count of
>> >seconds since the epoch, which of course xtime already is.
>>
>> The problem here, not listed, is with external stuff. When I touch
>> a file, the time needs to be stored in UTC time so TAI needs to be
>> converted to UTC
>
> Sure.  But it's a given that if we keep TAI internally, we have
> a way to easily convert it to UTC any time anybody asks for it.
> So we do the same conversion any time we need an updated
> timestamp for a file.  In general, every updated file timestamp
> comes from the equivalent of clock_gettime(CLOCK_UTC) /
> getimeofday() / time().

That just requires one number: the current offset.

>> and back again when dealing with files on disk.
>
> Not sure what you mean there.

Internally, the kernel is keeping time in TAI. So when the time is
updated in the inode, you have to do a TAI to UTC conversion.

>> It then becomes an interesting question: do you have to back convert
>> form UTC to TAI when doing a stat on a file in this scheme?
>
> No, not at all.  The timestamp in the inode on disk was stored in
> UTC, as it always has been.

Right, and is the time_t in the st_atime, st_mtime and st_ctime fields
reported as UTC or TAI? If TAI, you need a table and an agreed
convention for dates prior to 1972.

But keeping the kernel time in TAI and reporting it in UTC still
doesn't solve the userland side of things because time goes backwards
across the leap second... If everything were in TAI and it was just a
conversion, then some math with time breaks.

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

Re: [LEAPSECS] alternative to smearing

[Warner Losh]

On Wed, Jan 4, 2017 at 9:36 PM, Steve Summit <scs...@eskimo.com> wrote:
> Warner Losh wrote:
>> Steve Summit <scs...@eskimo.com> wrote:
>> > The requirement for tables (and, correspondingly, the
>> > "impossibility" of dealing with future UTC dates more than a few
>> > months out) depends on what you're trying to do...
>> > In particular, if right now it's 2017-01-05T01:56:13, I can
>> > obviously compute that (say) exactly three years from now is
>> > 2020-01-05T01:56:13, and I can even set a computer alarm to
>> > go off then, even if neither I nor the (suitably programmed)
>> > OS kernel that's tracking the alarm know in advance how many
>> > leap seconds there might end up being between now and then.
>>
>> Except that's not how things are programmed... People can talk
>> about it, but computers don't always store things that way. The
>> non-uniform radix presents problems. Trying to play semantic games
>> like this doesn't change that. There's problem, and trying to
>> equivocate away by saying "well, if you just did it right it would be
>> OK" isn't a helpful position. Requiring every computer to do
>> complicated things so that a leap second can work once in a blue moon
>> isn't a good engineering tradeoff.
>
> Indeed.  Did you see the message a few hours ago where I
> mentioned the "New Jersey approach" (aka "Worse is better")?
>
> But my point, my quibble with tvb's list, was that he said that
> some things were impossible or require leap second tables, when
> in fact they're merely difficult (to the point, depending on your
> engineering tradeoffs, of being a bad idea) or sometimes require
> leap second tables.
>
> I don't think that saying something is impossible, when it's
> merely difficult, is helpful either.

Saying something is impossible is just a short hand for "impossible to
implement efficiently" which is a decidedly helpful thing to say.
Forcing a design that can't be fast will inevitably result in a
competing design that is fast winning out, even in the face of
correctness. time_t is one such example: It made it easy to do local
time and literally impossible to do UTC.

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

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit  wrote:
> 2. Have xtime keep TAI.  This has the advantage that it's not at
>all wrong or kludgey to represent TAI as a simple count of
>seconds since the epoch, which of course xtime already is.
>The objection, as mentioned here pretty regularly, is that if
>you want to be able to set the clock from UTC, and deliver
>UTC, you always need to know TAI-UTC, so if you don't have it
>(if you're not on the net, or if you don't faithfully receive
>it early enough during boot) you're sunk.  But I'm now
>thinking that the work involved in assuming TAI-UTC=0 in that
>case (and remembering that we can't, for example, return
>success if someone asks for clock_gettime(CLOCK_TAI), and
>remembering to fiddle things if we learn TAI-UTC later) may
>end up being less than the work involved in #1.

The problem here, not listed, is with external stuff. When I touch a
file, the time needs to be stored in UTC time so TAI needs to be
converted to UTC and back again when dealing with files on disk. NFS
needs to report the right time, etc. Times will be off, and there will
be a lot of opportunities for bugs in the conversion. Some filesystems
have this as an explicit requirement, while others have it implicit.
While this would solve the ticking through a leap second problem,
there's a host of other issues hiding behind the scenes.

It then becomes an interesting question: do you have to back convert
form UTC to TAI when doing a stat on a file in this scheme? If so,
then the kernel needs to have a complete and accurate table of leap
seconds to do that conversion back and forth. Where does this come
from? How do you keep it up to date? Is there a locking protocol for
this?

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

Re: [LEAPSECS] alternative to smearing

[Warner Losh]

> The requirement for tables (and, correspondingly, the
> "impossibility" of dealing with future UTC dates more than a few
> months out) depends on what you're trying to do.  You can *talk*
> about the dates, and you can do interval arithmetic with a
> precision of days, hours, or minutes, perfectly well.  The only
> thing you need those leap second tables for, I think, is
> performing interval arithmetic with a precision of seconds.

Right, which is a common operation, even with dates in the future in the kernel.

> In particular, if right now it's 2017-01-05T01:56:13, I can
> obviously compute that (say) exactly three years from now is
> 2020-01-05T01:56:13, and I can even set a computer alarm to
> go off then, even if neither I nor the (suitably programmed)
> OS kernel that's tracking the alarm know in advance how many
> leap seconds there might end up being between now and then.

Except that's not how things are programmed. Programming it that way
would be very inefficient in a part of the kernel that has to be
ultra-efficient. Since you don't know how many seconds it will from
now, you can't schedule a timeout. The current setup of UTC doesn't
let me know how many seconds it will be in the future. People can talk
about it, but computers don't always store things that way. The
non-uniform radix presents problems. Trying to play semantic games
like this doesn't change that. There's problem, and trying to
equivocate away by saying "well, if you just did it right it would be
OK" isn't a helpful position. Requiring every computer to do
complicated things so that a leap second can work once in a blue moon
isn't a good engineering tradeoff. Ignoring the people that have
actually implemented things when they tell you that it's a bad design
isn't going to help make the design better..

Warner

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

Re: [LEAPSECS] Leap seconds ain't broken

[Warner Losh]

On Tue, Jan 3, 2017 at 6:35 AM, Rob Seaman  wrote:
> And Steve is discussing a specific legacy telescope.

That rather sums up the situation today with software. We have a
specific legacy standard called POSIX that's causing all kinds of
issues that pop up when you least expect it (taking out DNS server,
that's impressive), but there's no heir apparent to the standard, and
no history of willingness to change the standard to allow it to
properly model the current reality. Sure, it's just this bizarre
interface that we have to cope with, and it should just work by
default. But it doesn't. And that's before we get to the unspecified
behavior in the SQL standard or any of a large number of other
standards and APIs both great and small that punt on the issue
entirely. So instead of having this one telescope in the corner that's
old and ironically has issues with leap seconds with the rest of the
fleet working great and having high confidence the fleet will work
great, the situation with software is rather different. Here the bits
of software that work right on purpose are rather the rare exception
than the rule. The rest of the 'fleet' of software applications may or
may not handle the leap second correctly, which may in turn cause
problems great or small (or no problems at all). The issue here is
that it's hard do audit to know that it all works, hard to detect
issues before the failure and extensive testing of every single bit of
code across the leap second is prohibitively expensive.

So even before we get to "should work" or "should model reality" we
are confronted with a situation where we know that they don't, have
lots of examples of issues around them and such a general fear of leap
seconds causing something to go wonky we paper over it by introducing
a frequency error and hoping for the best since it breaks the fewest
number of things, at least as studied at Google and other places. Such
a permanent and ongoing impedance mismatch can not end in a happy
place.

So Rob and I can argue about what should happen, but I do know what
does happen and will continue to happen unless something radical
changes.

> There are subtleties to timekeeping. Removing leap seconds wouldn’t remove 
> the subtleties, rather it would promote them to significantly more 
> importance, perhaps “breaking” even more software and systems.

I suspect strongly, based on two decades of fixing bugs large and
small with leap seconds, that vastly more software will behave
correctly than badly by simply removing them. Time will no longer go
backwards, have a large step, or other weirdness that systems with
leap seconds and faulty software experience today. Given the rise of
smeared leap seconds to paper over it, I think that lots of people
have come to this same conclusion (mostly for reasons that have been
discussed at length).

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

Re: [LEAPSECS] Leap seconds still broken

[Warner Losh]

On Tue, Jan 3, 2017 at 4:35 AM, Tony Finch  wrote:
> Come on, some of the rest of you must have seen some failure reports,
> beyond just having to reboot your telescopes :-)

On a purely schadenfreude note: I find it extremely ironic that there
are any telescopes that have issues with a leap second since they are
the primary beneficiary of this peculiar dance we do upon occasion.

Warner

P.S. Sorry about the content free post. To make up for that, here's
redhat's rather long and extensive list of known issues with different
redhat versions. https://access.redhat.com/articles/15145
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds still broken

[Warner Losh]

On Sun, Jan 1, 2017 at 3:05 PM, Tony Finch  wrote:
> Ask Bjørn Hansen  wrote:
>>
>> Meanwhile over in reality even the software that’s supposed to keep track
>> of time basically still fails on leap seconds.
>
> More examples of failure, where 2 of the 4 setups got it wrong -
> http://www.spinellis.gr/blog/20170101/

Looks like I need to go look into why the FreeBSD kernel code to see
why it failed this time. I wonder who broke it this time. I've fixed
it a couple of times already in the past.

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

Re: [LEAPSECS] 2016 is not tied for second longest year ever

[Warner Losh]

On Sat, Dec 31, 2016 at 1:12 AM, Clive D.W. Feather <cl...@davros.org> wrote:
> Warner Losh said:
>> I'd think that 1712 in Sweeden was the longest year with 31708800 SI
>> seconds (give or take a few hundred milliseconds, my data-sniffing fu
>> isn't up the challenge of digging through the historical data to find
>> out how many). That was a double-leap-year.
>
> What about 708 AUC, with 15 months and 445 days? Surely that completely
> trumps 1712?

1712 for Sweden we know for sure. 708 AUC / 46BC we know less well.
There's several commentaries on the web for this that lay out the
conflicting evidence for the number of days (422, 444 or 445), so it's
hard to declare that the winner if we don't know what the actual total
is :)

http://www.tyndalehouse.com/Egypt/ptolemies/chron/roman/046bc.htm

There's also other year reckonings for other cultures that produce
very long results depending on what you tag as "a year"

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

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Sat, Dec 31, 2016 at 9:31 AM, Steve Summit  wrote:
> I'd like to say I'm not going to worry about that sort of case
> too much -- clearly, we can't implement proper leap second
> handling if we can't trust our time services to report them
> properly! -- but based on what I'm seeing on the ntp servers I'm
> sampling today, I may have been a bit too optimistic in that
> stance. :-\

Based on my actual experience debugging problems in production systems
around leap seconds, you can't trust the putative leap second
information too little. ntpd lies sometimes. GPS receivers have
firmware bugs that give the wrong results near leap seconds sometimes.
etc. To be robust, your system must cope with the lies and
prevarications as best it can. Leap seconds are the least thought
about aspect of most systems, so most people just get them wrong
through neglect, incompetence and sometimes spite. Any system that
hopes to survive in the current and foreseeable information
environment must be paranoid, ideally getting information from
multiple sources and cross checking it as best it can to try to
correct for human error (in both directions) as best it can.

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

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Sat, Dec 31, 2016 at 1:13 AM, Zefram <zef...@fysh.org> wrote:
> Warner Losh wrote:
>>Other systems don't have this quite yet, but I'd love to see it more
>>widely implemented. Is there a spec for this yet,
>
> https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html

Cool, but last updated 1998...

>>To do this, one would need to tell the kernel that a new leap second
>>is introduced. That's not too bad, but you'd also need to then run
>>through all the timers in the system to adjust the time that the UTC
>>timer was going to fire to be a new time
>
> You're prejudging the implementation too much.  The kernel does need
> to know about each leap second by the time it happens, but it does not
> need to convert timer expirations between TAI and UTC immediately when
> the timer is set.  Nor does avoiding this imply performing conversion in
> the hot path on timeout.  It suffices that timer settings get converted
> to the operational time scale *sometime* between when they are set and
> when they expire.  If a timer is set to expire a year hence, it would
> not be difficult to postpone the conversion until a few minutes before
> it expires, by which time one can expect to be able to perform the
> conversion correctly.

True. I'd assumed that the kernel has one callout wheel, that wheel is
in a uniform time scale, and that any conversion would need to be done
at insertion time. The issue with your suggested approach is how do
you know when to convert? Do you have a second callout wheel for
things '> minutes' in the future that gets scanned periodically for
adjustments? How does that complicate the locking and/or code paths
for timer cancellation, etc. Too much time being paranoid about making
change to that code in one specific system I guess.

>>But I'm curious how you'd represent a leap second in this scheme?
>
> CLOCK_UTC is defined to use 1e9 <= tv_nsec < 2e9 in struct timespec,
> by implication with tv_sec the same as it is for the preceding second.

Kinky. Won't work with timegm(), et al, since they don't time a
timespec to do their thing. But it certainly suggests some kind of
extensions that might be worth looking into. That suffers from the
conversion problem and the raw-math detection issue still, but it
isn't completely horrible. Is there ongoing work in this area? I
suspect that there'd be about a dozen APIs that might need to grow
awareness of timespecs.

>>  It's especially troublesome if the kernel decides that there
>>really isn't going to be a leap second at midnight for some reason
>
> That would require a decision on what it means to have set a timer for
> a time that doesn't actually exist.  It's not difficult to implement
> any of the reasonable options.

Yes. Generally, the sleep APIs are that you'll sleep for at least that
amount of time. For the timeout api, the absolute time could be fudged
a bit. Thought you'd have an information sharing problem between
userland and the kernel if you wanted a timeout in UTC time
potentially (how do you know that kernel / userland agree on the
future evolution of UTC).

>>It might be easiest if there's a flag on the UTC timeouts
>>that could be adjusted across such events
>
> Handily, clock_nanosleep() already has a flags parameter that could be
> used for that purpose.

Yea, I was thinking an internal to the kernel's timeout
implementation. If the kernel knows about UTC, then it can do the
conversions, and also trigger on changes to its knowledge of UTC,
which presumably happen infrequently enough to allow the work done in
that case to be somewhat expensive and intrusive to the operation of
the system for the duration of time it takes to do the work.

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

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Fri, Dec 30, 2016 at 10:11 PM, Rob Seaman <sea...@lpl.arizona.edu> wrote:
> On Dec 29, 2016, at 1:35 PM, Warner Losh wrote:
>
> A lot of code could have been changed while the ITU fiddled, e.g., Mac OS X
> was launched in 2001.
>
>
> Could have, but didn’t...
>
> Of course, MacOS is largely based on legacy code...
>
>
> Sixteen years ago, MacOS was a completely different operating system than on
> this MBP.
>
> The issue is what happens over the next fifteen years.
>
>
> That's not even remotely true. The GUI is completely different, but the core
> of the OS hasn't been rewritten in the past 15 years.
>
>
> Let’s back that up. During the  period, approximately 15 years long, that a
> small faction sought to have the ITU redefine UTC, Mac OS X has lived its
> entire lifecycle. Sixteen years ago, Mac OS 9 was a completely different
> beast. For that matter, iOS and Android are both less than a decade old.

You really don't know how much code is reused. Mac OS X has code
that's at least 40 years old in it. It is the fusion of Mach VM and on
a BSD kernel, both projects date back to the 70's. It uses the BSD
libc, as does Android (which is basically Linux kernel plus a BSD
userland plus cool stuff from google for Java and the like). All these
code bases are at least 30 years old. They aren't, as you say,
completely different. In fact, they likely contain some of the same
ancient code in them. Nothing is ever re-written from scratch. Even
Linux, whose kernel was written from scratch, imports tons of code
whose histories pre-date linux (gcc, X11, etc). iOS is MacOS rebranded
and ported to ARM. None of these have been written from scratch in the
last decade. Even the venerable IANA timezone database and code is
pushing 30 years at this point.

> In the coming decade, one is confident that lots of other software will be
> written and rewritten. It will be better software if it acknowledges factual
> reality as its underpinning.

And POSIX time_t can't represent leap seconds any more today than it
could in 30 years ago. Until this fundamental issue is resolved, no
forward progress is possible.

The "factual reality" is a construct of man. UTC is arbitrary in its
limits of 0.9s. There's nothing magical about 0.9s except that it
limited the errors from celestial navigation to a tolerable amount in
the days before GPS. Sure, mean solar time is not synchronized with
atomic time. That's reality. But what we adopt for civil time need not
be mean solar time. That's an invention of man as well. It's
tradition, sure, I'll grant that, but it isn't a fundamental constant
of the universe. Go only as far as Mars and everything changes...

> The argument appears to be that POSIX is such crap that we have to degrade
> other technologies. This may be aligned with the zeitgeist of 2016, yet
> remains oddly unpersuasive.
>
> It's only unpersuasive because you don't understand how long old code sticks
> around.
>
>
> Steve Allen and some others here from the astronomy community may be amused
> to have such a statement directed to a long time member of astronomy's IRAF
> group.
>
> POSIX dates to 1988, about the time I joined the IRAF group, though I had
> coded in IRAF starting around 1984. IRAF is layered on a virtual OS / kernel
> architecture and is coded in a highly portable C-like preprocessor language.
> The verbatim source runs (or ran) on various flavors of Unix, on VMS, on
> Data General’s OS. The code base is roughly of the scale of Linux.
>
> As IRAF’s Y2K tsar I understand how old code can be updated to support a new
> timekeeping API.
>
> Astronomy’s FITS image / table data format also predates POSIX, by an
> additional five years or so (late 1970s). This is a quirky international
> standard with a rather arcane process for changing the standard. Steve and I
> and likely others here are members of various FITS committees that navigate
> proposed changes. A checksum proposal was adopted into the standard this
> year that I introduced in 1994. The FITS world coordinate paper on time that
> Steve coauthored took a lightning fast decade or so.
>
> Over the next decades we likely all believe that time and timekeeping will
> become more important, not less. As such, software and systems and standards
> relating to time will benefit from attacking the issues head on. At the very
> least preserve the current UTC standard for backwards compatibility while
> having some committee of the ITU or BIPM design (or attempt) a better
> mousetrap.

Carefully written code can cope. However, the standard APIs don't
allow people to cope. You have to talk the standard APIs if you want
your code to be portable. The standard APIs don't have a way to
express the leap second unambiguously. That's the fundamental problem.
And the prevai

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Fri, Dec 30, 2016 at 9:52 PM, Steve Summit <scs...@eskimo.com> wrote:
> Warner Losh wrote:
>> On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray <hmur...@megapathdsl.net> wrote:
>> >> One could imagine having a more complicated structure that could cope with
>> >> the inherent ambiguity in future times. I can't say "schedule an event
>> >> exactly 1 year from now" for example without it. I need additional 
>> >> metadata
>> >> around to know if I want it to happen at the same time of day on the same
>> >> date or if I want it to happen after than many seconds have elapsed.
>> >
>> > Could that be solved with 2 functions in the API, one for N seconds from 
>> > now,
>> > and a second for at some future date/time specified in Y/M/D/H/M/S format
>> > rather than something like a time_t?
>>
>> Only partially (meaning only assuming every day has exactly 86400
>> seconds). These operations are possible today, since the former is +=
>> and the latter is timegm(), sorta, but neither groks leap seconds.
>
> I think we can do better than that, even today.  If you want
> to do something in N seconds, schedule a conventional alarm.
> (And, yes, using today's code, you'll always get N seconds that
> ignore leap seconds.)
>
> But if you want to do something at a particular future time,
> and you don't care (or can't predict) exactly how long from now
> that'll be, you can do that today, too, with clock_nanosleep and
> the TIMER_ABSTIME flag.
>
> In principle, it's straightforward to define meaningful behavior
> for both relative and absolute timers which run on Posix, TAI,
> or true-UTC timescales -- that is, with clockid tags of
> CLOCK_REALTIME, CLOCK_TAI, or CLOCK_UTC.  Implementation of some
> of the combinations is likely to be difficult, but hopefully not
> impossible.  (CLOCK_TAI is already in the newest Linux kernels,
> but I'm not sure how well it works; CLOCK_UTC is, shall we say,
> emerging.)

Other systems don't have this quite yet, but I'd love to see it more
widely implemented. Is there a spec for this yet, or is it just
whatever code is noodling around in Linux?

> One key point is that while scheduling a future event to occur
> at an absolute time does indeed necessarily require naming that
> time, this does not -- repeat not! -- become impossible just
> because we can't know how many leap seconds might occur between
> now and then.  If the true-UTC representation is properly
> designed (that is, if it is *not* realized as, say, a monotonic,
> leapsecond-observing count of seconds since the epoch), you
> can construct a future true-UTC timestamp, using a new mktime
> variant, just as easily and accurately as you can construct a
> future time_t value.  (In other words, we should not have to
> assume 86400-second days to do these things.)

To do this, one would need to tell the kernel that a new leap second
is introduced. That's not too bad, but you'd also need to then run
through all the timers in the system to adjust the time that the UTC
timer was going to fire to be a new time (by removing and inserting it
into the right list). While there are a number of different clocks
that can be reported, timeouts are still in the absolute ticking
monotonic thing. Doing a time conversion on every timeout is likely to
be too expensive since they get called a lot and tend to be the
critical path.

But I'm curious how you'd represent a leap second in this scheme? I'd
like to schedule a timeout in the UTC time during the leap second
(because it's the next second, or in 5 minutes or whatever, not
because there's something special about it, but because there
shouldn't be something special about it). How is that encoded into
time_t? Its easy to encode in TAI time, but not so easy to encode in
UTC time. It's especially troublesome if the kernel decides that there
really isn't going to be a leap second at midnight for some reason
(like a bad ntp server leaked the wrong data which was later
corrected). It might be easiest if there's a flag on the UTC timeouts
that could be adjusted across such events... Not ideal, but not
horrible.

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

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Fri, Dec 30, 2016 at 6:47 PM, Steve Allen <s...@ucolick.org> wrote:
> On Fri 2016-12-30T17:59:14 -0700, Warner Losh hath writ:
>> if you were to transition to a TAI world, then you'd not be able to
>> implement the latter for a TAI time of the UTC time at some
>> Y/M/D/H/M/S past the end of the next six month boundary, since it is
>> impossible to have that knowledge.
>
> This is a well-known problem in the arena of calendaring applications
> when an event is to be attended by parties in many timezones.  The
> calendaring applications must be able to recognize that the timezone
> rules for one or more of those attending can change (sometimes with
> much less notice than the 6 months for leap seconds) between the
> scheduling and the event.  This requires that the event be stored with
> a home time zone (in addition to the time in that zone) in which its
> time is fixed, and that everyone else can be alerted if the local
> authorities announce that home time zone or their own time zone is
> being changed.

Yes. Just so. Keeping all that book is a lot harder than the current
APIs, and many of the kernel interfaces just want a time_t + fraction
to do the scheduling with, leading to an impedance mismatch that's a
friction point where many bugs usually crop up. It's made a bit harder
also by the fact that the current tz code doesn't, by default, stat to
see if the zone data has changed on every time conversion call... It's
even worse here, though, because you do need to convert times between
the different CLOCK_* timescales, and it's hard to know if the
conversion is still valid when you use the converted value. It's
always a race, though thankfully a very slow one... And in the kernel,
there's often an optimized data structure that holds the current
timeouts sorted in order of when the timeouts expire in the kernel's
timescale...

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

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray  wrote:
>
>> One could imagine having a more complicated structure that could cope with
>> the inherent ambiguity in future times. I can't say "schedule an event
>> exactly 1 year from now" for example without it. I need additional metadata
>> around to know if I want it to happen at the same time of day on the same
>> date or if I want it to happen after than many seconds have elapsed. You
>> can't convert a putative UTC time to TAI time until you are within 6 months
>> of that time (the current announcement schedule) because if you try to
>> compute that time too far in the future, it will change. ...
>
> Could that be solved with 2 functions in the API, one for N seconds from now,
> and a second for at some future date/time specified in Y/M/D/H/M/S format
> rather than something like a time_t?

Only partially (meaning only assuming every day has exactly 86400
seconds). These operations are possible today, since the former is +=
and the latter is timegm(), sorta, but neither groks leap seconds. And
if you were to transition to a TAI world, then you'd not be able to
implement the latter for a TAI time of the UTC time at some
Y/M/D/H/M/S past the end of the next six month boundary, since it is
impossible to have that knowledge.  The former, btw, is also done with
timegm, since you can pass it an unnormalized Y/M/D/H/M.S and it will
do the math for you. Except it doesn't deal with leap seconds, since
time_t doesn't. There's too many ways to express these different
items, and different programers make different choices, some less well
suited to a 'tell the right lies' APIs approach than others. Some
programmers rely heavily on timegm and friends, while others try to
roll their own, with varying degrees of competence. Having the rolling
the own bit outside of the library calls is what makes papering over
more difficult.

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

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Fri, Dec 30, 2016 at 7:28 AM, Steffen Nurpmeso  wrote:
> Never having done kernel programming, this doesn't sound logical
> to me.  You have a clock source and a conversion algorithm.  That
> runs every time, maybe even millions time a second?  Maybe kernels
> exist which don't do any work unless there is real work to be
> done, due to I/O or application requests etc., then synchronizing
> on soft startup only, a.k.a. less often.

Kernels don't work that way at all.

> It appears to me that it would be a single additional subtraction
> to get to UTC, would that time signal be tracked as TAI.

At any given instant, you might know how many seconds UTC and TAI
differ by. That's the easy part. However, you might not always know
that, and for any second that's more than 6 months in the future, it's
impossible to know how to convert.

>  |One could imagine having a more complicated structure that could cope
>  |with the inherent ambiguity in future times. I can't say "schedule an
>
> So there is no ambiguity for CLOCK_TAI.

There is ambiguity in CLOCK_TAI because all sources of time are UTC.

> The ambiguity for UTC is to adjust time for our home planet, or
> what remains of it now that we listen to some middle-age eight
> cylindre blues that is to say -- e.g., ~58 percent loss of species
> in a fourtyfive years study from i think WWF it was?
> Yes, yes, i know about that great future with those Big Macs that
> have grown in the genetical laboratories etc., and the cloned-back-
> to-life green plants everywhere (take for example that fantastic
> invention of the "CityTree", how fine that is).
> Until then i realize -- i very _much_ realize when i look out of
> my window, to say the truth -- that the sun and the light and
> warmth it brings is a very crucial aspect of not only my
> subconsciousness, and i now start looking forward impressable to
> the leap second that is to occur to bring us in sync again.  Yes.

I doubt very much you can tell an error of DUT1 being even as small as 60s.

>  |event exactly 1 year from now" for example without it. I need
>  |additional metadata around to know if I want it to happen at the same
>  |time of day on the same date or if I want it to happen after than many
>  |seconds have elapsed. You can't convert a putative UTC time to TAI
>  |time until you are within 6 months of that time (the current
>  ...
>
> Yeah, sorry, but that is what it is.  Those financial warriors
> need it for timestamps, with subsecond precision.

"It is what it is" means that it's basically an intractable problem.

>  |As an aside, UTC could be made more predictable if a schedule was
>  |announced like we do leap days. We can be off by several days because
>  ...
>
> But what is the application you need this for?
> You want to know future dates with subsecond precision --
> Armageddon won't happen, thanks to Bruce Willis -- but never cared
> for correct date handling of the past.  No one ever did.
> One day you will turn around and find nothing but scorched earth
> behind your back.

Designing an API that can't handle all reasonable uses of time means
you are setting yourself up for failure. This is another manifestation
of the "it's only a second so why bother" attitude that will continue
to mire us in the unsatisfying situation we're in now. Trying to give
me a straw-man argument about what use is it means that you're saying
we can't solve this problem or that I'm crazy for trying. Yet it's one
of the very real issues that one confronts when trying to deal with
actually solving the problem. It's the primary cause of my pessimism.

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

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Thu, Dec 29, 2016 at 9:42 PM, Rob Seaman <sea...@lpl.arizona.edu> wrote:
> On Dec 29, 2016, at 1:35 PM, Warner Losh <i...@bsdimp.com> wrote:
>
>>> A lot of code could have been changed while the ITU fiddled, e.g., Mac OS X
>>> was launched in 2001.
>>
>> Could have, but didn’t...
>>
>> Of course, MacOS is largely based on legacy code...
>
> Sixteen years ago, MacOS was a completely different operating system than on 
> this MBP.
>
> The issue is what happens over the next fifteen years.

That's not even remotely true. The GUI is completely different, but
the core of the OS hasn't been rewritten in the past 15 years.

> The argument appears to be that POSIX is such crap that we have to degrade 
> other technologies. This may be aligned with the zeitgeist of 2016, yet 
> remains oddly unpersuasive.

It's only unpersuasive because you don't understand how long old code
sticks around.

>>>> UTC may well be superior to POSIX's notion, but that’s entirely besides 
>>>> the point.
>>>
>>> It is the only point.
>>
>> It all depends on the metrics you use to judge it by Is time of day more 
>> important or interval time more important.
>
> Reject the premise. Time of day is mean solar time. Interval time is atomic 
> time.

Right, you just use different metrics than I. Our understanding and
notion of time has evolved, and continues to evolve.

> Both exist in the physical universe we inhabit. Systems should be engineered 
> to handle both. Leap seconds are a means to an end, and UTC remains a 
> reasonable compromise, but by all means seek another compromise.

Yes. There are ways to improve UTC such that it can actually be more
reliably implemented in software by making its irregularities more
predictable.

>> You've obviously never dealt with pervasive standards in coding that date 
>> back to the 70's that are nearly impossible to change. Doing that by fiat 
>> isn't going to work.
>
> Or one could point out that time of day has been mean solar time since the 
> big bang (well, since the first roughly spherical protoplanet formed a solid 
> crust). That’s an awfully big windmill at which to tilt.
>
>
>>> Or simply adopt GPS or TAI
>>
>> Won't work. Been proposed and rejected many times.
>
> I did mention:
>
>>> Commercial devices already exist…that implement high precision GPS and TAI.
>
> The ones we have run Linux. (Discussions of whether Linux is POSIX are 
> redirected to /dev/null.)
>
> POSIX wants to pretend that time of day is interval time. If so, just don’t 
> call it “Universal Time”.

You did mention them. I'll note that while one can run with TAI or GPS
time, and one has been able to do that for at least 20 years that I'm
aware of, it doesn't solve the problem. If it was that easy, we'd be
doing it already.

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

Re: [LEAPSECS] POSIX? (was Time math libraries, UTC to TAI)

[Warner Losh]

On Thu, Dec 29, 2016 at 4:29 AM, Rob Seaman  wrote:
> Warner is staging a spirited defense of POSIX. Such a stalwart champion
> deserves a more worthy cause.
>
> POSIX time_t says they don't exist. Therefore, they don't exist.
>
>
> POSIX, meet physics.

There's nothing that says that DUT1 < 0.9 is sacrosanct. It isn't
physics, it's about convention. But we've had this argument many
times.

> There's millions of lines of code written to POSIX with the mistaken
> assumption that they are implementing time correctly. Changing it all, or
> even a large part of it, is unlikely to happen.
>
>
> A lot of code could have been changed while the ITU fiddled, e.g., Mac OS X
> was launched in 2001.

Could have, but didn't. In the interim no contender for best ever time
library that solves the leap second problem emerged and was accepted.

Of course, MacOS is largely based on legacy code, so in its core
libraries little code was added around time. But that's a quibble
about the example.

> UTC may well be superior to POSIX's notion, but that’s entirely besides the
> point.
>
>
> It is the only point.

It all depends on the metrics you use to judge it by Is time of
day more important or interval time more important.

> While it might result in a better world if POSIX were able to change, it
> isn’t.
>
>
> Placing POSIX in the same “too stupid to fail” basket as the U.S. Electoral
> College seems a weak strategy.
>
> The marketplace has effectively voted with its feet, and change would be too
> expensive.
>
>
> But change is what is proposed. That being the case, the simplest change
> would be to define a new timescale. Call it “GNU” for "GNU is Not UTC”. Add
> one statement to the POSIX standard:
>
> “After  all references to UTC in the POSIX documents, or to
> timekeeping generally, will be taken to refer to the GNU time scale, defined
> by .”

You've obviously never dealt with pervasive standards in coding that
date back to the 70's that are nearly impossible to change. Doing that
by fiat isn't going to work.

> Or simply adopt GPS or TAI, which already have the precise behavior desired.
> Commercial devices already exist (and are already widely deployed) that
> implement high precision GPS and TAI.

Won't work. Been proposed and rejected many times.

The basic problem is that things don't work by default. They can't
work by default with the current standards, as defined by existing
practice. POSIX dropped the ball here in some ways (though to be fair,
they were codifying existing practice that dated back to the mid
1970's in UNIX: prior to that epochs changed every couple of years).

If there was an easy solution, it would have emerged by now. Trouble
is that the details are quite difficult to get right even if you get
the standards issues out of the way. And it's for a problem that
people sneer at (only a second, why do I care), so there's little
support for spending boatloads of money to fix it. The problem is that
you never know if the following code has a leap second issue or not.
Let's suppose for a minute we redefined time_t to be TAI. Let's
further suppose that we can perfectly transmit knowledge about leap
seconds to every machine on the planet that's doing time
synchronization well enough to care. Let's also suppose the numerous
other technical issues are sorted out. How do you know if the
following code has issues with leap seconds or not:

time_t foo;
foo = get_some_time();
foo += 60;
do_something_at(foo);

Does this code say "do something in 60 seconds" so it will slip 1
second within the minute over a leap second. Or does it say "Do
something one minute hence at the same offset within the minute?" For
the casual observer, those two statements are the same. but to the
computer, they are different. And it isn't something that's easily
adaptable to easy detection by the compiler because it's how boatloads
of code is currently written. Many of the y2k bugs were caught because
the patterns there are easier to automatically scan for. Yet this
example illustrates that it can be hard to divine intent.

One could imagine having a more complicated structure that could cope
with the inherent ambiguity in future times. I can't say "schedule an
event exactly 1 year from now" for example without it. I need
additional metadata around to know if I want it to happen at the same
time of day on the same date or if I want it to happen after than many
seconds have elapsed. You can't convert a putative UTC time to TAI
time until you are within 6 months of that time (the current
announcement schedule) because if you try to compute that time too far
in the future, it will change. Absent metadata, you'll have the wrong
time. It also means that any interval you compute about a future set
of times can change after you've computed it in the light of new data.
It's this aspect of the problem that leads me to say it's unsolvable:
future UTC is inherently ambiguous because it is tied to a rotating
earth 

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Thu, Dec 29, 2016 at 12:28 AM, Steve Summit  wrote:
> If we try to handle them better, two conclusions seem inescapable:
>
> 1. Posix-compatible time_t values will need to be smeared,
>spreading the leap second out more gradually, to eliminate
>sudden, unseemly jumps.
>
> 2. There needs to be a well-defined way to deliver true,
>non-smeared, leapsecond-aware UTC time to code that needs it.
>
> Putting these together, I conclude that any smearing for #1 needs
> to be done in the OS kernel, just before delivering leapsecond-
> unaware Posix-compatible time_t values.  Doing the smearing anywhere
> upstream (as, for example, Google is doing it) precludes #2.
>
> As a proof of concept, I'm working on a set of Linux kernel mods
> to do both #1 and #2.  I had hoped to have them ready for
> interested people to experiment with this Saturday, but
> unfortunately I'm not going to make it.

How do we know when to do #1 and when to do #2? Especially in light of
the uses of #1 that do extra things to get to knowledge of truth? I
think you'd get most cases if you used adj_timex to report the speared
error, since I know of at least some code that recovers UTC from
time_t get time calls this way.

Also, how do you make this work 'by default' without making every
single programmer that uses these APIs know all the leap second rules?

How do you deal with acquiring knowledge of leap seconds after you've
given out 'old' timestamps that might be affected by them? This is
best described as how well you recover from the leapsecond file being
corrupted and replaced, though there's many other scenarios here.

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

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Wed, Dec 28, 2016 at 2:21 PM, Brooks Harris <bro...@edlmax.com> wrote:
> On 2016-12-28 02:29 PM, Warner Losh wrote:
>>
>> On Wed, Dec 28, 2016 at 10:33 AM, Brooks Harris <bro...@edlmax.com> wrote:
>>>
>>> The YMDhms count progression across the first Leap Second
>>> (1972-06-30T23:59:60 (UTC)) as yielded by POSIX gmtime() is expected to
>>> be
>>
>> Or rather "something like the following," because POSIX doesn't say
>> what happens during the leap second. Some systems replay the 799
>> second rather than the 800 second to avoid starting the day twice...
>> This is also allowed by POSIX because every last thing dealing with
>> the leap second is implementation defined because it is outside the
>> scope of the standard. FreeBSD does 799 twice for example. There's
>> other systems that 'freeze' time during the leap second, only
>> incrementing it by a tiny fraction for each gettimeofday call.
>
> Hi Warner,
>
> My understanding, also from David Wells: "Unlike the POSIX conventions , the
> NTP clock is frozen and does not advanced during the leap second, so there
> is no need to set it back one second at the end of the leap second. "

Except that it does advance... It plays the second twice, once with
the pending leap set, and once with it cleared I though. At least for
the time exchanges that happen during the leap second. I have a fuzzy
memory of this changing at some point (from freeze to double tick
disambiguated by a bit), but have no primary source for this.

> This seems consistent my understanding of the specs, that POSIX would
> "reset" and NTP would freeze. But POSIX is intentionally vague on its
> definition of "the epoch" to allow some fudge factor for older systems to be
> conformant and somewhat unclear how Leap Seconds are handled.

POSIX is silent on leap seconds. Any leap second behavior is outside
the scope of the standard because POSIX time_t doesn't have leap
seconds at all. Any behavior at all is possible during the leap second
since leap seconds cannot exist in POSIX. That's my main beef with the
standard: It works well for local time at the expense of being able to
do something sensible (or a range of sensible behavior) with leap
seconds (both ticking through them and representing them.

It's my memory of kern_ntptime.c that early versions froze the system
time during the leap second, while later ones double ticked. I recall
reading something on Dave Mills' ntp web site years ago to this
effect, but a quick google search is not fruitful at the moment.

> Indeed some implementations have made different choices, which is exactly
> the sort of mismatched behavior we'd all like to find a way to overcome,
> right?

There's two problems: one is that time_t is defined in such a way as
to preclude sensible things with a leap second. Two is that
implementations differ on what the sensible thing to do is because
they must break some symmetry to fix the problem: is time monotonic or
can you double tick special seconds? Is frequency stable or can you
randomly fudge it (either hugely by stopping time, or tinily with a
long-term offset)? Much each second must have a uniform label? Without
a sensible standard, with defined semantics, progress is impossible
because you must break some fundamental aspect of the passage of time.
Leap seconds break time by making it a non-uniform radix in a fussy
and technical way that's poorly communicated to the world. Since the
standard assumes a uniform radix, the impedance mismatch cannot but
cause problems. Couple that with the "It's just a second, so who
cares" attitude that's prevalent, and I despair at a solution coming.

In other words, I'm of the opinion that defining what the right thing
to do while the ship is sinking isn't really useful if the underlying
model assumes ships can't sink.

>>>   time_t  gmtime()UTC
>>> 78796799 = 1972-06-30 23:59:59 = 1972-06-30T23:59:59 (UTC)
>>> 78796800 = 1972-07-01 00:00:00 = 1972-06-30T23:59:60 (UTC) << Leap Second
>>> 78796800 = 1972-07-01 00:00:00 = 1972-07-01T00:00:00 (UTC) << time_t
>>> reset
>>> 78796801 = 1972-07-01 00:00:01 = 1972-07-01T00:00:01 (UTC)
>>>
>>> time_t must be reset after the Leap Second to maintain the alignment of
>>> the
>>> POSIX and UTC YMDhms representations. In effect the time_t origin has
>>> become
>>> coincident with "1972-01-01 00:00:00 UTC plus one Leap Second", or
>>> "1972-01-01 00:00:01 UTC". As David Mills says "... In effect, a new
>>> timescale is reestablished after each new leap second."
>>
>> Yes, you must repeat time_t values to be posixly correct. Many
>> extensions 

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Wed, Dec 28, 2016 at 12:59 PM, Steve Summit <scs...@eskimo.com> wrote:
> Warner Losh wrote:
>> ...There's other systems that 'freeze' time during the leap second,
>> only incrementing it by a tiny fraction for each gettimeofday call.
>
> Do you know which systems those are?  I haven't found any of them.
> I know Dave Mills talks about them.  I've heard that Linux implemented
> that scheme once, but later removed it.

Some versions of Linux. Some versions of Ultrix / OSF on Alpha did
similar. There are several NTP hardware servers that did likewise
internally. I also think OS/MP on Solbourne computers did this, but
can't easily check anymore. OS/MP was based on SunOS 4.x, and I think
it inherited it from there. I haven't checked lately to know who may
still be doing it. There are some systems that really want to have
consistent, monotonically increasing time no matter what, and will
accept time being wrong in rare cares to achieve that.

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

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Wed, Dec 28, 2016 at 10:33 AM, Brooks Harris  wrote:
> The YMDhms count progression across the first Leap Second
> (1972-06-30T23:59:60 (UTC)) as yielded by POSIX gmtime() is expected to be

Or rather "something like the following," because POSIX doesn't say
what happens during the leap second. Some systems replay the 799
second rather than the 800 second to avoid starting the day twice...
This is also allowed by POSIX because every last thing dealing with
the leap second is implementation defined because it is outside the
scope of the standard. FreeBSD does 799 twice for example. There's
other systems that 'freeze' time during the leap second, only
incrementing it by a tiny fraction for each gettimeofday call.

>  time_t  gmtime()UTC
> 78796799 = 1972-06-30 23:59:59 = 1972-06-30T23:59:59 (UTC)
> 78796800 = 1972-07-01 00:00:00 = 1972-06-30T23:59:60 (UTC) << Leap Second
> 78796800 = 1972-07-01 00:00:00 = 1972-07-01T00:00:00 (UTC) << time_t reset
> 78796801 = 1972-07-01 00:00:01 = 1972-07-01T00:00:01 (UTC)
>
> time_t must be reset after the Leap Second to maintain the alignment of the
> POSIX and UTC YMDhms representations. In effect the time_t origin has become
> coincident with "1972-01-01 00:00:00 UTC plus one Leap Second", or
> "1972-01-01 00:00:01 UTC". As David Mills says "... In effect, a new
> timescale is reestablished after each new leap second."

Yes, you must repeat time_t values to be posixly correct. Many
extensions to POSIX have been proposed and implemented (and some are
quite good) that effectively say time_t ticks in TAI time and to get
UTC the host must translate with varying degrees of papering over the
old APIs. But Dave Mills is right: if you are trying to count seconds,
your counts are necessarily discontinuous at a leap second in an
implementation defined way.

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