Re: [LEAPSECS] Alanna Mitchell in NYT

[Joseph Gwinn]

On Mon, 14 Nov 2022 20:26:07 +, Poul-Henning Kamp wrote:
> 
> Joseph Gwinn writes:
> 
>>> I believe I recently saw PHK ruminating that forward compatibility in
>>> computing is at least as important as backward compatibility because
>>> the next 30 years of software need to know where they are going.
> 
> The other side of my argument is that more software will be created
> in the next 30 years than were created in the previous 30 years,
> so if you want to optimize for more code being correct, you need
> to concentrate on getting it right for the future, not for the past.

And the likelihood is that software written (at great expense) to 
prepare for what will be in 30 years from now will be a dead loss, 
outmaneuvered by technological and scientific progress.

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

Re: [LEAPSECS] Alanna Mitchell in NYT

[Joseph Gwinn]

On Mon, 14 Nov 2022 11:48:12 -0800, Steve Allen wrote:
> On Mon 2022-11-14T18:27:25+ Poul-Henning Kamp hath writ:
>> And with a 2035 deadline we might just get to see if our implementations
>> of negative leap-seconds work before it is too late.
>> 
>> Yes, it should have happened 20 years ago.
> 
> I believe I recently saw PHK ruminating that forward compatibility in
> computing is at least as important as backward compatibility because
> the next 30 years of software need to know where they are going.
> The NYT article ends with Arias ruminating about how someday
> there will have to be a leap minute or leap hour.
> To have systems which will handle that eventuality we need to be
> openly considering the goals and implementation for that already.

The problem is as always that we cannot know the future, and so we 
will always guess wrong.

That which is predicted never happens and that which happens is never 
predicted.

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

Re: [LEAPSECS] article for Metrologia

[Joseph Gwinn]

On Sun, 30 Oct 2022 07:08:25 +, Poul-Henning Kamp wrote:
> 
> Warner Losh writes:
> 
>> 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.
> 
> I would say it is even worse:
> 
> POSIX was simply an administrative exercise to rapidly rubber-stamp
> the AT manuals to define a common baseline "before UNIX fragmented".
> 
> The "technical review" of POSIX amounted to "The seven dwarfs" comparing
> it to their own manuals, to ensure that their "me-too" UNIX could be made
> compliant with minimal effort.
> 
> Even if it had been a very convincing proposal, any change as
> fundamental as time_t, be it leap-seconds or 64 bits, would have
> been instantly shot down, entirely on the grounds that "The seven
> dwarfs" didn't have the in-house UNIX-skill to implement the change.

Not exactly.  I laid the history out in the "[time-nuts] Leap seconds 
and POSIX" thread circa 2009, which I won't recite here - see for 
instance 
.

The other ting to keep in mind is the immense existing codebase of 
unix kernels et al, not to mention application code depending on 
those kernels.

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

Re: [LEAPSECS] article for Metrologia

[Joseph Gwinn]

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.

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
>  |>|
>  |>|
>  |>
>  |> 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 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.
> 
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> ___
> 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

[Joseph Gwinn]

On Thu, 12 Nov 2020 23:45:52 +, 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 ?

Twenty years ago, I tested a very large radar for the general effect 
of a leap second by arbitrarily causing the local clock by one 
second, in both directions.  Radar software gyrated and settled down 
on the inserted leap second, and really gyrated on a deleted second.  
But nothing failed.

This tests mostly the radar tracking software, and not leap second 
handling per se.  The radar passed - the momentary gyration was not a 
problem in practice.

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

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

[Joseph Gwinn]

John,

I've read your paper "Avoid Using POSIX time_t for Telling Time" 
(2016-12-08), and have some general comments:

1.  Despite the resemblance to UTC, POSIX time is by intent *not* UTC, 
so all the observations that actual days can differ from 86,400 seconds 
and so on are correct, but beside the point - there are no leap seconds 
in POSIX Time.  The reason is that POSIX Time must work in isolated 
systems, ones having no access to leap second data.  This issue comes 
up from time to time, and there are a number of archived email fights 
on the subject, laying out the whole issue.  POSIX Time is its own 
timescale, the details of which flow from the objectives and 
requirements of POSIX operating systems.  While the POSIX Time Epoch is 
defined in terms of UTC (originally GMT), the progression rule is an 
approximation of atomic time - it just marches along, counting out 
seconds without reference to astronomy.

2.  The new and modern timescale that most resembles POSIX Time is 
TAI.  TAI was traditionally a paper clock, but the rise of IEEE 1588 
Precision Time Protocol (PTP) has caused TAI to be implemented in 
practical time generation and distribution systems.  Specifically, one 
can now buy GPS receivers that can be configured to publish GPS System 
Time, UTC, and now TAI.  This makes it simple and direct to use TAI 
where one would have used UTC.  Keeping in step with civil time is then 
performed only at interfaces where UTC or local civil time is required, 
the core of the system (with millions of lines of code) being 
blissfully unaware of leap seconds.

3.  Over my career building large radar systems, the typical setup is 
that the radar runs on GPS System Time distributed as if it were UTC.  
This is achieved by setting the GPS receiver to emit GPS System Time, 
and letting NTP think that this is UTC.  Actually, NTP botches leap 
seconds - a negative leap would cause the last second to be re-run, and 
a positive leap causes a time wobble.  The radar software does notice 
these deviations from uniformity.  The bump that a leap second would 
cause is intolerable in most such systems, so leap seconds are banned 
from the core.  The displays and interfaces to external systems do any 
necessary conversion to and from UTC or local civil time.

4.  FYI, typical radar software internally uses an integer count of 
clock ticks since their Epoch, which varies.  The use of integer counts 
allows mathematically exact time arithmetic to be done efficiently.  In 
these systems, time is a form of data, and not the clock on the wall.  
Think tracking of things flying by.  One system from decades ago 
counted milliseconds "since Christ died" (well, the start of the 
Gregorian Calendar) in a 48-bit integer.  More recent systems count 
nanoseconds in a 64-bit integer.  Monotonic Time in POSIX is modeled on 
these timescales.

Joe


On Tue, 13 Dec 2016 10:50:53 -0500, John Sauter wrote:
> Eric,
> 
> I attach a set of time manipulation subroutines I have been working on.
>  You can extract the sources from the PDF file using okular.
> 
> These subroutines manipulate time expressed as UTC coded in a tm
> structure.  They extract the current time and allow addition and
> subtraction of years, months, days, hours, minutes and seconds.  They
> also handle local time and deal properly with leap seconds.  Details
> are in the PDF file.
> 
> I am planning to update the software to include the latest research on
> historical values of Delta T, but this version will work until I can
> get to that.  I would appreciate any feedback you might have.
> 
> Since these subroutines handle leap seconds while expressing time using
> UTC, you can use UTC rather than TAI as your time scale.
> 
> You said you are capturing meta-data about the devices from which you
> capture time.  I feel that this is absolutely required, and I
> congratulate you for doing this.
> John Sauter (john_sau...@systemeyescomputerstore.com)
> -- 
> PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E
> ___
> 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] A standard for leap second smearing

[Joseph Gwinn]

On Tue, 27 Sep 2016 23:45:18 +0100, Stephen Colebourne wrote:
> Leap second smearing is a way of taking UTC (with leap seconds) and
> mapping it to a view of time that always has 86400 subdivisions per
> day.
> 
> Tony Finch summarized five known approaches, which are all linear:
> 
> Amazon-12h +12h
> Bloomberg -0   +2ks
> Google-10h +10h
> QTnet -"about 2 hours" +0
> UTC-SLS   -1ks +0
> 
> The goal of this thread is to see if consensus could be found for one
> approach of smearing.
> 
> The decisions would appear to be:
> 
> 1) Linear or Other?
> All current known smears are linear. Google previously had a different
> approach, but changed to linear. Are there any major arguments against
> linear? It would seem to be easier to specify and code that way.
> 
> 2) When to smear?
> Some smear up to midnight, some smear after midnight, some smear both
> sides. What are the arguments for/against each?
> 
> 3) Speed of smearing?
> The existing approaches have two broad groups - fast (under an hour -
> Bloomberg/UTC-SLS) and slow (20 hours or more - Google/Amazon) with
> QTnet an outlier towards the fast end. What are the arguments
> for/against fast/slow? Would there be a case for two agreed standards,
> one fast and one slow?
> 
> 4) Anything else?

In my experience, large systems that really care to avoid leap-second 
disruptions lock NTP to GPS System Time (not UTC) from the GPS 
receiver, and handle the leap-second offset in application code at the 
human interfaces and computer interfaces to external systems that 
understand only UTC.  

What's coming, due to IEEE 1588 PTP is that GPS receivers now have the 
ability to publish TAI (over the screaming objections of BIPM) as well, 
so many newer systems will lock NTP to TAI.

In both cases, there is usually a parallel all-hardware path that 
distributes nanosecond-accurate time from the GPS receiver to all 
time-critical hardware.

There is also usually another parallel all-hardware path distributing 
microsecond-accurate time.  This path was traditionally implemented 
using IRIG-B AM over coax, but now IEEE 1588 PTP is trying to take that 
niche over, but this will require increased maturity.

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

Re: [LEAPSECS] Look before you don't leap

[Joseph Gwinn]

On Tue, 19 May 2015 22:02:18 -0700, Rob Seaman wrote:
 On May 19, 2015, at 1:39 PM, Joseph M Gwinn gw...@raytheon.com wrote:
 
 In short, POSIX systems have to be able to work in a cave, with no 
 access to the sky or knowledge of astronomy.
 
 If the cave has access to NTP it has access to the IERS.

Not necessarily.  One can have only local clocks, and need only 
synchronization within the cave.

 
 And astronomy happens underground as well:
 
   http://www.atlasobscura.com/places/sudbury-neutrino-observatory

We don't have large enough caves.  Wasn't that FTL neutrino debacle due 
to a bad connector in the time distribution path from GPS upstairs to 
the neutrino detectors downstairs?


 Astronomers and others rely on both solar and atomic timescales.  
 Both need transport infrastructure to the most remote locations on 
 Earth (and under it and in orbit).

True but not relevant to the intent of the POSIX Timescale.

 
 On the other hand, the one thing we can be sure about POSIX is that 
 it will ultimately have a finite lifespan.  But a day on Earth (and 
 on Mars and Pluto) will always be a synodic (mean solar) day, 
 whatever decision is made at WRC-15.

Nothing lives forever, not even the Earth, so what's the point?

As for the format of time_t, it is an integer of unspecified size.  
Most current systems use 32 bit integers, and this will roll over in 
2038 (if signed).  This was well understood back when POSIX had its 
last revision, where the omission of a size was intentional.  

The rationale is that by the time we get to 2038, all platforms will 
have changed time_t to a 64-bit integer, deferring the problem for tens 
of billions of years, by which time POSIX will be in museums, laughed 
at by bored children.  That is, if children still exist.

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

Re: [LEAPSECS] W1K GPS rollover for some time servers (PTP motivation)

[Joseph Gwinn]

On Tue, 5 May 2015 22:54:03 -0700, Steve Allen wrote:
 Like the TymServe 2100 units there will probably be other systems that
 fail because of a lack of leap seconds.  That means that 45 years ago
 the CCIR put us all into a Catch-22 situation, and the ITU-R inherits
 the undesired responsibility of doing or not doing something about it.
 
 On Tue 2015-05-05T21:37:48 -0600, Warner Losh hath writ:
 Engineering is the choice of which consequences you want to have.
 
 It should be an informed choice, and an individual choice, and a
 choice.  What gets broadcast in the radio time signals is none of
 those, and that is presumably a major motivation for the adoption of
 IEEE 1588 (PTP).  IEEE 1588 gives those system managers a way to
 choose to disregard certain international standards in favor of a
 system with guaranteed robust behavior.  Such use of PTP is evident in
 older documents and recent press releases by the financial markets
 which basically read We know our systems will be robust but we're not
 sure about yours, so we're changing the trading hours on June 30.

The original impetus behind IEEE 1588 PTP was the US Navy.  

A big reason to desire something like 1588 was to eliminate most of the 
various time distribution systems on Navy ships, such as IRIG, 
combining everything into ethernet.  There is a lot of money in this - 
cable plants are expensive, bulky, and heavy, and each independent 
distribution system requires lots of engineering labor to implement and 
interface.

But I will agree that forcing propagation of TAI as a practical (versus 
paper) clock is one good side effect, but that isn't sufficient reason 
for the Navy to have spent all that money.

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

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

[Joseph Gwinn]

On Thu, 12 Mar 2015 18:50:56 -0700, Tom Van Baak wrote:

 I didn't think that NTP or POSIX or PTP is what we'd call a timescale. 

As discussed in other responses, a timescale requires only three 
things, a definition of zero time (or a specified time), a definition 
of the second (or some other time duration unit), and a progression 
rule.  That's it.

By this definition, all three (NTP, POSIX, PTP) define private 
timescales for their own internal use, and translate to and from 
external timescales as needed.


 NTP is a UTC synchronization algorithm. 

NTP is a synchronization algorithm for sure, but NTP is not limited to 
UTC, even though the RFCs speak of UTC.  Lots of people use NTP to 
distribute GPS System Time, and I bet that there are people now using 
NTP to distribute TAI.


 UT0 is a measurement. UT1 is a timescale. TAI is a timescale. UTC is a 
timescale. 

UT0 *is* a timescale, one that is tied to a specific astronomical 
observatory.  Multiple UT0 timescales are combined to yield UT1, and 
UTC is derived from UT1.

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

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

[Joseph Gwinn]

On Sun, 08 Mar 2015 12:24:42 -0400, Brooks Harris wrote:
 
 On 2015-03-07 06:50 PM, Joseph Gwinn wrote:
 On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote:
 In the discussions I've been involved with many people argued
 strenuously we don't care about the past, only accurate date-time
 going forward!. The reason I'm choosing to ignore the subject of
 accurate date-times before 1972 is not that its not important, but
 probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS
 - its just too expansive a topic to tackle in some commonly accepted
 way. For date-time before 1972 you've got to switch to some other
 timescale depending on the purpose at hand.
 I figured it out the difference between GMD and UTC for POSIX.  There
 was an 81 microsecond error,  At the time, most UNIX boxes kept time to
 the nearest second, synchronized to a hairy wrist.  There were advanced
 systems that could do milliseconds, and in the 1980s a few that had
 microsecond resolution, but we chained them to GPS via NTP, so the
 error was multiple milliseconds, depending on everything.
 Hi Joe,
 
 I see the difficulties with UTC implementations and the questions at 
 ITU-R stemming from the historical and legacy misalignment of the 
 timekeeping mechanisms of the c language and POSIX and the UTC 
 specifications. Perhaps that's obvious. I'm not criticizing anybody 
 anywhere for this, its just the way its come about.
 
 I think the only way the industry can eventually converge on reliable 
 civil time representation is to refine the underlying time 
 mechanisms in POSIX in some manner that allows a migration to a more 
 comprehensive UTC implementation. I think if a new new POSIX time 
 specification were to take shape it would add an option to the the 
 conversation at ITU-R - instead of simply to kill Leap Seconds or 
 not they'd also have a viable migration path to comprehensive UTC 
 timekeeping implementation to consider.
 
 We understand the folks at POSIX have grappled with this topic in the 
 past and run into all sorts of difficulty. Given the current state of 
 affairs, do you think there's any way IEEE and POSIX could reengage 
 this topic?

The biggest problem was that the time folk couldn't stop arguing, and 
come to a solution that met all of POSIX's technical requirements.  Nor 
should the arguments be held in the POSIX committee, most of which were 
totally unable to follow the arguments.  The committee finally threw 
the time folk out into the snow and settled for minimal changes.  I did 
get the statement that each day has exactly 86,400 seconds written into 
the standard, and that although it resembled UTC is was not in fact 
UTC, to cut off the common misinterpretation that POSIX time was UTC.  
I published the email threads some time ago.  Anyway, if the time folk 
could come to agreement and present one proposal, there is a chance.

Also listed in the email threads were the requirements, and one of the 
requirements is that POSIX time had to work in a reasonable way even in 
totally isolated systems, which have no way to know about leap seconds.

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

Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

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

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


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

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

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

Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote:
 Joseph Gwinn wrote:
 On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
 Hi folks,
 
 I've been asked off list to make the slides of my presentation at
 FOSDEM 2015 in Brussels available and post the download link on this
 list.
 
 So here it is:
 
 
https://fosdem.org/2015/schedule/event/technical_aspects_of_leap_second_propagation_and_evaluation/
 
 See the Attachment link.
 
 Very interesting; thanks for posting this.
 
 I have a few questions and comments:
 
 1.  Slide titled Known Bugs (2): Has support for negative leap
 seconds been restored in NTP v4?  It wasn't clear.
 
 I have to admit that I wrote this before 4.2.8 had been released. 
 Support for negative leap second has been in older NTP versions, but 
 had been removed in 4.2.6.
 
 Now in 4.2.8 the leap second code has been reworked and cleaned up, 
 and a very quick look at the source code seems to indicate that this 
 might work again. At least there's code which passes the announcement 
 flag to the kernel, if kernel support is enabled.
 
 I think I'll give it a try soon. I'd expect that a negative leap 
 second might work if an appropriate announcement is received from a 
 refclock or upstream NTP server, but it will be interesting to find 
 out if this works with a NIST-style leap second file where the TAI 
 offset decreases at a given date.

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

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

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


 Second, we often have the GPS (or PTP 1588)
 receiver to emit GPS System Time, but never share this with downstream
 servers, who are configured for UTC (but strangely the leap seconds
 never come).  The difference between UTC and GPS System Time is handled
 in applications code.  The reason for this approach is so that the bulk
 of the system is free from step discontinuities, and only the
 interfaces need deal with UTC.
 
 I agree, but as I've tried to point out above I think a better 
 project design would have been to use TAI instead of GPS time. PTP 
 works natively with TAI, and you can easily convert between he two 
 scales.
 
 Of course it's easy to convert GPS to TAI, and vice versa, but you 
 have to take care that more types of conversions are required and 
 implemented correctly.

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

 
 Thanks for your feedback!

Quite welcome.

Joe Gwinn


 Martin
 -- 
 Martin Burnicki
 
 MEINBERG Funkuhren GmbH  Co. KG
 Email: martin.burni...@meinberg.de
 Phone: +49 (0)5281 9309-14
 Fax: +49 (0)5281 9309-30
 
 Lange Wand 9, 31812 Bad Pyrmont, Germany
 Amtsgericht Hannover 17HRA 100322
 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
 Andre Hartmann, Heiko Gerstung
 Web: http://www.meinberg.de
 ___
 LEAPSECS mailing list
 LEAPSECS@leapsecond.com
 https://pairlist6.pair.net/mailman/listinfo/leapsecs
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

Harlan,

On Sun, 01 Mar 2015 20:35:20 +, Harlan Stenn wrote:
 Joseph Gwinn writes:
 On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
 Hi folks,
 
 I've been asked off list to make the slides of my presentation at 
 FOSDEM 2015 in Brussels available and post the download link on this 
 list.
 
 So here it is:
 
 
https://fosdem.org/2015/schedule/event/technical_aspects_of_leap_second_propagation_and_evaluation/
 
 See the Attachment link.
 
 Very interesting; thanks for posting this.
 
 I have a few questions and comments:
 
 1.  Slide titled Known Bugs (2): Has support for negative leap 
 seconds been restored in NTP v4?  It wasn't clear.
 
 Not yet.  It's a tradeoff.
 
 We've never needed to delete a leapsecond and depending on who you ask
 it will probably never happen.

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


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

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

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

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

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

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

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

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

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

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

Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

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

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

Thanks,

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

Re: [LEAPSECS] My FOSDEM slides

[Joseph Gwinn]

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

Very interesting; thanks for posting this.

I have a few questions and comments:

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

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

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

Re: [LEAPSECS] earth speeding up

[Joseph Gwinn]

On Tue, 15 Apr 2014 06:31:21 -0700, Tom Van Baak wrote:
 I know it's a risk making trend lines, but those of us who work with 
 clocks, oscillators and frequency standards find it irresistible to 
 peek ahead sometimes and guess what's coming. This applies to my 
 favorite clock, the earth.
 
 See attached inverse length of day plots (that is, frequency error 
 rather than excess LOD, or period error). This started with Stable32 
 (the standard tool we all use for time  frequency metrology) but I 
 reformatted them with Excel to make them clearer.
 
 This plot is for 1 July 1972 to the present. Those of you who follow 
 DUT1 like the stock market recognize the characteristic periodicity, 
 bumps, and trends. Note especially the stable period starting 1999, 
 with many days of the year longer than 86400 seconds, and 
 consequently no leap second for 7 years (roughly MJD 51000 to 54000).
 
 Any betting person would say the plot shows an upward trend over the 
 past 40 years. A simple linear fit suggests the earth will be back to 
 an honest 86400 second day within a few years, around MJD ~59000 
 (year ~2020).
 
 The URL for the plot is:
 http://leapsecond.com/pages/lod/earth-lod-10.gif
 
 See also the zoomed version, where the predicted zero-crossing is clearer:
 http://leapsecond.com/pages/lod/earth-lod-11.gif
 
 The raw DUT1 and LOD data comes from IERS. It's a work in progress; 
 other plots are under http://leapsecond.com/pages/lod/ as I pursue 
 this.
 
 I realize this is just for fun, and the serious geology, astronomy, 
 and climate professionals on the list will raise valid concerns. But 
 there's no doubt that since the 1970's the earth is generally 
 speeding back up. If this trend continues, within a decade, we will 
 have another long stretch of no leap seconds and this time it will be 
 followed by our first negative leap second.

This first negative leap second may end civilization - essentially no 
leap-second handling code is really ready for a step backwards.  Yes, I 
know the standard says it can go both ways.  But who reads such boring 
documents anyway?

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Joseph Gwinn]

On Sat, 18 Jan 2014 19:51:33 -0700, Warner Losh wrote:
 
 On Jan 18, 2014, at 5:21 PM, Steffen (Daode) Nurpmeso wrote:
 
  Those applications which do care about leap seconds can determine
  how to handle them in whatever way those applications feel is
  best.
 
 The problem is that all applications should care about leap seconds. 
 It is a part of the time standard (UTC) that is papered over in POSIX 
 time_t. This is a false partitioning, and what causes the probelms.

There are applications where the timescale cannot have any step 
discontinuities.  Like airplane and missile guidance.

 
 I think today this would require including a leap second table
 yourself.  I do know for sure that my gettimeofday() returns
 a seconds-since-the-epoch that includes leap seconds, so, without
 Olson right/, i'm afraid the timestamps are wrong.
 
 This turns out to be difficult to arrange if you have to know time 
 early in your startup sequence. GPS receivers can give it to you, 
 unless they are a 'cold spare' that have been turned off for more 
 than 6 months, then you have a time jump if there's been a leap 
 second in the interim (because cached values become wrong)...  Or you 
 have a delay until the number is known after the almanac is 
 downloaded. It is this problem that's lead me and others to suggest a 
 longer time horizon for leap seconds to ensure that the use cases are 
 more easily handled.
 
 Of course, the 6 month window does make it impossible to compute a 
 time_t for a known interval into the future that's longer than 6 
 months away...

And there is always the problem that one really really hopes that the 
guidance still works after an unpredicted leap.

So, one creates a TAI-like timescale.  This also simplifies the 
software, as only a few human-facing applications need to care about 
leap seconds, and if these few applications stumble, it's only an 
annoyance.

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Common Calendar Time (CCT) -Brooks Harris

[Joseph Gwinn]

On Sat, 18 Jan 2014 23:10:41 -0800, Brooks Harris wrote:
 On 2014-01-18 09:39 AM, Zefram wrote:
 Joseph Gwinn wrote:
 No.  If your poke around into how time is used, you will discover that
 what is stored is the count of seconds since the Epoch.  Broken-down
 time is used only when there is a human to be humored.

 Sure, scalar time_t values are used underneath, and I didn't say
 otherwise.  That's what time_t is for.  The kernel even increments the
 time_t clock, most of the time, as if it's a linear count of seconds,
 which is how it behaves on the small scale outside the immediate
 vicinity of leap seconds.  But a kernel that knows about leap seconds
 then introduces a discontinuity in the scalar value, somewhere near each
 leap, to maintain the scalar-UTC relationship.

 Yes, two related issues -
 
 1) There's no specification how the kernel should behave.
 2) The POSIX API has its shortcomings, as you note, and these are 
 tangled with the kernel's behavior.

It's true that POSIX governs APIs (application-program interfaces), and 
does not govern kernel implementation details.  This is as intended.

 
 On Windows, in c/c++, the POSIX API is implemented as a sub-system 
 which in turn calls proprietary Windows time APIs, like 
 ::GetSystemTime(), ::GetFileTime() and related. Divining exactly how 
 those are behaving is a challenge. Some parts of the POSIX API are 
 just not implemented, and some versions of MSVC c/c++ implement 
 non-standard 64-bit versions.
 
 Also, not all versions of POSIX are equally good. I've found smoking 
 gun bugs in some implementations of gmtime() and related.

Yes.

 
 Meantime, as you note in 
 http://www.fysh.org/~zefram/time/prog_on_time_scales.pdf, 
 Disseminating Leap Schedule to Machines, is a missing link in the 
 whole UTC world is a well defined and reliable method of obtaining 
 the proper metadata (Leap Seconds table, announce signals, etc). This 
 needs to be addressed somehow by somebody.

I didn't write the referenced article.  I just scanned it, but don't 
see how is solves the problems POSIX tries to solve.  And there are 
plenty of articles on how time ought to be determined and represented - 
the matter is still very much in play with  respect to UTC and the 
possible dropping of leap seconds.  This may or may not be settled 
during my career.


 POSIX time is defined without reference to NTP,

 Indeed.  The two definitions are separate, but match in most of their
 design features.
 
 POSIX count steps back on Leap Second insertion. NTP count 
 freezes on Leap Second insertion. Either way there's an ambiguity, 
 so that's one design feature they share :-).
 
 NTP *does* refer to POSIX - Figure 4: Interesting Historic NTP Dates 
 refers to First day UNIX and locates it 63072000 seconds before 
 1972-01-01T00:00:00Z (UTC). This helps solve one problem - when, 
 exactly, was the POSIX the Epoch.

Ok.  I meant a normative reference, in the sense of coordinated 
standards.  An interesting historical note isn't really coordination.

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Joseph Gwinn]

On Sun, 19 Jan 2014 13:14:33 -0800, Brooks Harris wrote:
 On 2014-01-19 08:26 AM, Warner Losh wrote:
 On Jan 18, 2014, at 11:03 PM, Brooks Harris wrote:
 
 On 2014-01-18 08:53 AM, Warner Losh wrote:
 On Jan 18, 2014, at 6:31 AM, Magnus Danielson wrote:
 
 On 18/01/14 11:56, Poul-Henning Kamp wrote:
 In message 52da2a0f.9060...@rubidium.dyndns.org, Magnus 
 Danielson writes:
 
 If you where right about not basing it on the orbital debris, then we
 should not attempt to be using concepts like seconds, minutes, hours,
 days, weeks, months, years [...]
 As you are no doubt aware, the POSIX time_t does not do that.
 The POSIX time_t still tries to encode it, using some of the 
 rules that makes of UTC, including SI-seconds. However, the 
 argument was not about POSIX time_t, but about what Universal 
 in UTC actually means.
 POSIX time_t is explicitly not UTC.
 Ah, well, it is explicitly UTC, but not the UTC we'd like.
 
 section 3.150 Epoch says - The time zero hours, zero minutes, zero 
 seconds, on January 1, 1970 Coordinated Universal Time (UTC).
 No. It is *NOT* UTC. It omits leap seconds. It confuses the issue by 
 using the term UTC when it specifies something that doesn't actually 
 model UTC, but only an approximation of it, not the actual UTC. It 
 makes matters worse by specifying a UTC epoch.
 
 But its described behavior is not *modern* UTC (with Leap Seconds), 
 and this is made clearer by section A.4.15 Seconds Since the Epoch -
 That's rather my point. It is most definitely not UTC.
 
 Coordinated Universal Time (UTC) includes leap seconds. However, 
 in POSIX time (seconds
 since the Epoch), leap seconds are ignored (not applied) to provide 
 an easy and compatible
 method of computing time differences. Broken-down POSIX time is 
 therefore not necessarily
 UTC, despite its appearance.
 POSIX time_t isn't UTC. Broken down time isn't UTC either.
 
 Broken-down POSIX time is a YY-MM-DD hh:mm:ss representation - a 
 *calendar* date-time.
 
 POSIX behaves as an *uncompensated-for-Leap-Seconds* Gregorian 
 calendar counting scheme.
 Right, this is *NOT* UTC. That's why I said that it is explicitly 
 not UTC. It says so in the standard.
 
 We agree. The standard first explicitly says that it is UTC and then 
 it explicitly says it is *not* UTC.  Why should there be any 
 confusion about this? :-)

It's actually fairly simple.  To be UTC, one needs both the timescale 
origin and the progression rule to conform to TF.460.  

POSIX defines the origin of POSIX time in terms of UTC.  

However, the progression rule is *not* UTC, in that leap seconds are 
not applied (and so all days have exactly the same length, being 86,400 
seconds).  

So, POSIX time is *not* UTC.  One out of two isn't good enough, and the 
fact that broken-down time resembles UTC is irrelevant.

Joe Gwinn

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Embedded software

[Joseph Gwinn]

On Sun, 19 Jan 2014 16:02:54 -0700, Warner Losh wrote:
 
 On Jan 19, 2014, at 2:12 PM, Hal Murray wrote:
 
 The olson database updates will take care of that.
 
 One of the problems with leap-seconds is that they aren't 
 predictable and the 
 software in embedded gear doesn't get updated.  That also means the 
 time zone 
 data doesn't get updated.
 
 What sort of embedded gear uses time but not time zones?  Or are people 
 willing to gamble that Congress won't mess with DST anytime soon?
 
 All the embedded gear I've done runs on UTC. But it also has 
 requirements for 'cold start' that are incompatible with GPS and 
 couldn't be met if the system had been off across a leap second.  It 
 didn't deal with localtime, so DST insanity didn't matter so much...

Many Air Traffic Control (ATC) radars run on UTC (not local time) in a 
loose sort of way.  What saves them is that most ATC radars are 
mechanically rotated, with a typical rotation period of 12 to 15 
seconds (precision approach radars can be 2 seconds, but that's a 
different discussion).  The effect is one full circle of detections 
that appear to be out of position by one second's travel time, which 
causes a disturbance in the tracks, which disturbance soon dies out.

Full-scale tests have been done on operational hardware and software in 
simulation, where a leap second was emulated by manually stepping the 
clock.  For positive leaps (insert a second), there was no visible 
disturbance to the crawling-worm displays.  For negative leaps (omit a 
second), there were quite visible disturbances, but these also settled 
out.

The percentage error for omission of a second is larger than that for 
adding a second, and the difference in visible effect may be partly due 
to detections missing the coarse gate and being dropped in the rotation 
following the jump.  In later rotations, the fractional error is 
smaller, and the tracker picks up where it left of.

This is the bounding case.  ATC systems typically do not jump at the 
leap, they slide over 10 seconds or so.

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Embedded software

[Joseph Gwinn]

On Sun, 19 Jan 2014 23:31:00 +, Poul-Henning Kamp wrote:
 In message 20140119182454462945.77293...@comcast.net, Joseph Gwinn writes:
 
 This is the bounding case.  ATC systems typically do not jump at the 
 leap, they slide over 10 seconds or so.
 
 In Denmark they go hands off until stuff look normal again.

So, they step the clock (versus sliding smoothly), and just wait for 
the gyrations to subside?

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Common Calendar Time (CCT) -Brooks Harris

[Joseph Gwinn]

On Mon, 20 Jan 2014 00:16:13 + (UTC), Joseph S. Myers wrote:
 On Sun, 19 Jan 2014, Steve Allen wrote:
 
 On Sun 2014-01-19T07:39:51 +, Clive D.W. Feather hath writ:
 When I was on the ISO C (*NOT* ANSI c) committee, we looked at 
 the issue.
 Then we asked the expert community (that is, you lot), to come up with a
 consensus proposal that we could look at. As far as I know, the committee
 is still waiting.
 
 Where is the record of the communication?
 To whom was it addressed and how was it sent?
 If someone wants to contact the committee how should that be done?
 
 sc22w...@open-std.org (emails from non-members of the list are moderated).
 
 Note that:
 
 * The ISO C standard is not currently being revised, and while it isn't 
 being revised it's not possible to vote things into a future revision 
 (beyond Technical Corrigenda in response to Defect Reports); you need to 
 wait for work to start on a new version.
 
 * The other option for proposed ISO C features is a Technical 
 Specification, but there's a complicated process to start work on one, 
 involving several countries supporting a New Work Item Proposal.  You 
 won't get a TS started without several committee members interested in 
 working on it (and I haven't seen evidence of such interest in WG14).  And 
 then a TS does not form part of ISO C, unless the C standard is revised 
 and it's proposed and agreed to integrate the TS into it.  You can have a 
 study group, like the current one for parallel language extensions, 
 without going through that process, but you still need several committee 
 members interested.
 
 (There may be other options available under ISO processes, e.g. a 
 normative amendment such as was done for C90 in 1994/1995.  I don't think 
 they are likely to be applied in this case; there's been a need lately in 
 SC22 to push back on a notion coming from (at least some bits of) 
 ISO/IEC/JTC1 that TCs should only be issued within two or three years of 
 standard publication and after that there should be a new edition.)
 
 * Nothing happens in the C standard (when it *is* being revised) without a 
 WG14 paper proposing specific textual changes to be made to the standard.
 
 * There has sometimes been a mood in WG14 not to standardize things 
 without existing implementation practice.  The extent to which that rule 
 is followed varies (it was stated at the start of C11 development, but 
 then major features went in without such implementation practice).  
 Similar views have sometimes been expressed in POSIX.
 
 So, to improve ISO C standards for time and timezones and related issues 
 you need several interested committee members working on proposed 
 specifications, producing implementations of those specifications as 
 evidence of implementation practice (preferably) and attending meetings to 
 champion the proposals.
 
 (I'm the Convenor of the UK C panel.)

My experience is with POSIX, where the story is similar but far less 
complicated.

In summary, my advice to the Time Folk is to thrash out a single 
proposal and present it to the committee one hopes to convince.

And the Time Folk should *not* try to sort out the politics and 
theology of timescales in a non-time working group, or to define the 
One True Clock (paralleled on 
http://en.wikipedia.org/wiki/True_Cross).  This was tried in POSIX, 
devolving into a full-scale flamewar (resembling the current thread, 
but even louder), which led to the Time Folk being summarily ignored. 
It should be understood that while the committees want to do the right 
thing, they neither know nor much care about time, and will insist that 
their problems and stated requirements are addressed.

(I'm the Chair of the POSIX Committee, and their main time guy (the 
scars are healing nicely).)


Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Common Calendar Time (CCT) -Brooks Harris

[Joseph Gwinn]

On Sat, 18 Jan 2014 11:37:36 +, Zefram wrote:
 Brooks Harris wrote:
  The whole purpose of TAI is
 a realization of TT, right? TAI shields us (I mean us normal
 computer people, not astronomers or cosmologists) from the details of
 how TAI is maintained
 
 TAI does not shield you from the lack of atomic clocks prior to 1955.
 
 [NTP and POSIX time]
 I don't think so. Both are indeed counts of Seconds, and both have a
 relationship to UTC time.
 
 For POSIX, see
 http://pubs.opengroup.org/onlinepubs/009604499/basedefs/xbd_chap04.html,
 section 4.14, defining Seconds Since the Epoch as
 
 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.
 [...]
 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
 [...]
 The divisions in the formula are integer divisions; that is, the
 remainder is discarded leaving only the integer quotient.
 
 It's defined as a transformation of a broken-down UTC timestamp, not
 (despite its name) as a count of seconds since some instant.

No.  If your poke around into how time is used, you will discover that 
what is stored in the cound of seconds since the Epoch.  Broken-down 
time is used only when there is a human to be humored.


 NTP's definition, by contrast, does speak of counting seconds, but it
 doesn't count leap seconds.  It counts 86400 per UTC day regardless of
 leaps, and so is also effectively just a transformation of broken-down UTC
 timestamps.  Both NTP and POSIX time values are sometimes described as a
 count of non-leap seconds, which similarly gets across the essential
 point that the leap second history doesn't influence the scalar-UTC
 relationship.

POSIX time is defined without reference to NTP, which is its own world 
with its own standard.  Note that the NTP standard, RFC-1305, is dated 
March 1992, which is well after the first POSIX standard (1988 - the 
Ugly Green Book).  Nor does NTP have any reference to UNIX or POSIX.


Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Common Calendar Time (CCT) -Brooks Harris

[Joseph Gwinn]

On Sat, 18 Jan 2014 17:39:00 +, Zefram wrote:
 Joseph Gwinn wrote:
 No.  If your poke around into how time is used, you will discover that 
 what is stored is the count of seconds since the Epoch.  Broken-down 
 time is used only when there is a human to be humored.
 
 Sure, scalar time_t values are used underneath, and I didn't say
 otherwise.  That's what time_t is for.  The kernel even increments the
 time_t clock, most of the time, as if it's a linear count of seconds,
 which is how it behaves on the small scale outside the immediate
 vicinity of leap seconds.  But a kernel that knows about leap seconds
 then introduces a discontinuity in the scalar value, somewhere near each
 leap, to maintain the scalar-UTC relationship.
 
 POSIX time is defined without reference to NTP,
 
 Indeed.  The two definitions are separate, but match in most of their
 design features.

The word I would have used is parallel.  NTP and UNIX/POSIX solve 
different problems, but still the similarity wasn't quite a happy 
accident.

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Joseph Gwinn]

On Sun, 12 Jan 2014 10:58:40 +, Poul-Henning Kamp wrote:
 In message 52d257b6.6090...@edlmax.com, Brooks Harris writes:
 
 But time_t has always been UTC, because it was meant to be UTC.
 
 Oh, I see what you're saying. Of course - UTC in the historical non-Leap 
 Second period existed, and they intended time_t to reflect it.
 
 Nice try to twist things to your own viewpoint, but you are wrong.
 
 They meant UTC to be UTC.
 
 They had absolutely no opinion on leapseconds.

The original UNIX definition of the Epoch invoked GMT, and POSIX 
updated this to UTC as it was the obvious successor.  The POSIX crowd 
chose to ignore leap seconds, because one cannot expect an isolated 
system to know of such things, and it was not necessary to know to meet 
the requirements of UNIX/POSIX time, chiefly file modification 
timestamps to ensure (to within one second) causal time ordering. 
One-second resolution was fine enough to ensure causal order when the 
policy was adopted, but this fell apart in the 1980s.


 Leapseconds, UT, UT1, UT2 or for that matter astronomers or their
 opinions about time, played absolutely no role in the decision
 making process.

GMT is now (unofficially?) deemed to be UT1.

In practice, for probably the majority of systems, the time source is 
the user's wristwatch.

 
 Bell Labs were a telco-sidekick and the telco business used UTC
 to isolate local timezones and DST issues to a presentation issue.
 
 Do I need to remind you that it was telcos caused UTC to be CCITT
 business in the first place ?
 
 Apparantly the only computing person outside timelabs who cared
 about leapseconds prior to 1985 was Dave Mills.

Could be.


Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Joseph Gwinn]

On Sun, 12 Jan 2014 15:42:57 -0500, Greg Hennessy wrote:
 On 01/12/2014 02:47 AM, Poul-Henning Kamp wrote:
 In message 52d20beb.60...@edlmax.com, Brooks Harris writes:
 
 
 Yes, in my opinion its unfortunate they chose to use the term UTC in
 that context.
 
 They chose UTC because they meant UTC.
 
 I have this directly from multiple persons who were involved back
 then, including Dennis Ritchie who gave me the full sordid details
 about the early UNIX' requirement of weekly recompiles to update
 the epoch of the timekeeping.
 
 
 If they chose UTC because they meant UTC, then why do the
 man pages refer not to UTC, but to GMT?
 
 http://cm.bell-labs.com/7thEdMan/vol1/man2.bun
 
 It sounds like you are rewriting history.

No, he isn't.  In the UNIX before POSIX, it was GMT.  When the first 
POSIX standard was developed, GMT had been deprecated in favor of UTC, 
so POSIX changed to UTC.

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Joseph Gwinn]

On Sun, 12 Jan 2014 22:18:41 GMT, Michael Spacefalcon wrote:
 Joseph Gwinn joegw...@comcast.net wrote:
 
 In the UNIX before POSIX, it was GMT.
 
 Your use of the past tense is incorrect.  In non-POSIX UNIX, it (the
 system time definition) *is* GMT, present tense.  See my previous
 post.

Well, yes, but I guess it's a bit of hair splitting.  The UNIX docs may 
well still say GMT, but I bet what they really use is UTC, as that's 
what's distributed.  Getting true GMT (~UT1) is a bit more work that 
would seem necessary for 99.999% of users.

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Joseph Gwinn]

On Sat, 11 Jan 2014 10:39:32 -0700, Warner Losh wrote:
 
 On Jan 11, 2014, at 9:32 AM, Joseph Gwinn wrote:
 
 On Fri, 10 Jan 2014 21:35:25 -0700, Warner Losh wrote:
 
 On Jan 10, 2014, at 8:35 PM, Skip Newhall wrote:
 
 'Proscribe’ and 'prescribe' are distinct words:
 
 'Proscribe' means to forbid, disallow, or prohibit. “School rules 
 proscribe the use of pencils on exams.”
 
 'Prescribe' means to lay out specifications or rules about 
 something. In the manner prescribed by law.”
 
 I don’t know the context of the sentence the Magnus refers to.
 
 Prescribe is the word I intended. POSIX mandates, requires, 
 prescribes that time is UTC.
 
 No.  While POSIX broken-down time resembles UTC, the underlying 
 timescale (Seconds since the Epoch) is *not* UTC, in that every day 
 contains exactly 60*60*24= 86,400 seconds.  Leap seconds are *not* 
 applied.
 
 That's the problem with POSIX time_t. It specifies a mapping from UTC 
 to time_t, but the mapping isn't 1-1 onto. It tries to be UTC, but 
 also tries to paper over leap seconds by pretending they don't exist. 
 That's part of the craziness of POSIX time_t. It specifies something 
 that doesn't match UTC, but is expected to be much like UTC. It also 
 is UTC in the sense that it tracks UT1 within a second (ignoring 
 errors in realization on a specific system). It is a poorly modeled 
 approximation of UTC that makes certain compromises to get a 'simple 
 math' property, but pretends that leap seconds don't exist and are an 
 implementation detail specifically not specified.

Trying to force POSIX time into the UTC mold isn't going to go well.  

Read the official definition slowly, without the assumption that the 
committee really meant UTC but didn't know how to say it.  Every word 
was debated.  See the appended section of Rationale.


 The confusion arises because the POSIX Epoch is defined using UTC.  But 
 the progression rule is a form of TAI (with unknown but constant 
 offset).  POSIX background information follows.
 
 The progression rule doesn't say that. The offset to TAI changes at 
 each leap second. So it is mostly kinda sorta TAI with a fixed 
 offset, until a leap second happens. Then the offset changes.

The definition does not actually mention TAI (although it was proposed 
to do so).  I'm just pointing out that POSIX time is in effect a form 
of TAI.  Granted that the offset jumps on leap seconds if one is fed 
from UTC (via GPS), but this causes little trouble.  If fed from GPS 
System Time, the offset never changes.


 URL of index page: http://pubs.opengroup.org/onlinepubs/009695399/
 
 
 From POSIX Base Definitions volume: 
 
 3.149 Epoch
 The time zero hours, zero minutes, zero seconds, on January 1, 1970 
 Coordinated Universal Time (UTC).
 
 
 From the General Concepts volume:
 
 4.14 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
 
 This section says UTC and defines how it is related to UTC...

The key word is related.  This is not equality, and the choice of 
weasel word was deliberate.


 The relationship between the actual time of day and the current value 
 for seconds since the Epoch is unspecified.
 
 This sentence is the most lame part of the spec. We define this 
 value, but it doesn't have to match? Most implementors I've talked 
 with have suggested that this means the error is not bounded rather 
 than you can have random values second to second

There is a long history.  It was a big fight.  The trail is in the 
email archives, if anybody has the energy.  

Suffice it to say that the Time Folk kept quarreling about the One True 
Clock, while ignoring the needs of the POSIX world, until the POSIX 
Committee threw the Time Folk out in exasperation and stuck with what 
they had inherited from UNIX.

I did manage to fix the leap year computation (restore the 400-year 
rule), and remove the nonsense about double leap seconds.

Somewhere else, 


 How any changes to the value of seconds since the Epoch are made to 
 align to a desired relationship with the current actual time is 
 implementation-defined. As represented in seconds since the Epoch, each 
 and every day shall be accounted

Re: [LEAPSECS] drawing the battle lines

[Joseph Gwinn]

On Wed, 20 Mar 2013 22:46:01 -0700, Rob Seaman wrote:
 On Mar 20, 2013, at 8:28 PM, Joseph Gwinn joegw...@comcast.net wrote:
 
 True enough, but beside my point.  The relationship between UTC and UT1 
 is piecewise linear between leap seconds, so there are steps in the 
 first derivative at the joints between lines,and steps in zeroth and 
 first derivatives at the leap seconds.
 
 Ignoring the perpetual refrain about leap seconds being merely a 
 representational issue, Kevin's question was about point 9 of the 
 CCTF recommendation, which is an assertion about UT1 itself.  Saying 
 UT1 is unacceptable as a time scale is like saying John Harrison's 
 descendants should refund the longitude prize.  Many quantities can 
 serve as timelike independent variables.

I'm just summarizing what I think the ITU intended to say.

Arguing that the ITU is wrong in what they said does not change the 
translation.

 
 It's pretty clear that ITU intends to make UTC essentially like TAI, 
 but not just as a paper clock.
 
 If ceasing leap seconds would manage this transmogrification from 
 paper clock to real clock, than simply applying DTAI manages the same 
 thing.

I was just observing what their direction appears to be.  I don't have 
a vote in the ITU.


 And I will say that in the big radars I build, leap seconds are a real 
 problem, one that we solve by using GPS System Time in all but human 
 interfaces.
 
 So you recognized that UTC did not match your project requirements 
 and used a different widely available time scale that did.  How 
 exactly were you disadvantaged?  

The disadvantage was that many people believe UTC to be suitable, but 
don't notice or deal with the leap seconds, which is devastating in 
radar trackers for instance.  With one dish radar system, we were 
forced to use UTC because a major piece of reused software couldn't 
handle conversion between GPS System time and UTC, and so needed to run 
only UTC.  To verify if this would work, we artificially inserts both 
plus and minus time steps of one second.  Adding a second caused no 
visible disturbance.  Subtracting a second caused some gyrations, but 
these soon dissipated.  The dish rotation period was 12 seconds, so one 
second is almost 10% error in the detection timestamps, and this was 
enough.  A faster rotating radar would not have been able to handle 
such a step discontinuity. 


   The ITU is attempting to turn one 
 flavor of time scale into another.  The fallacy is the notion that we 
 shouldn't have two time scales in the first place.

Well, standards groups do do these things, and over time it is a great 
help.  I would look to the history of machine screw threads for a 
parallel.  

In my case, ceasing to have leap seconds will be helpful.  In your 
case, it's not helpful.  This is also true of all standards, which are 
thus decided by the balance.

Joe
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] drawing the battle lines

[Joseph Gwinn]

On Wed, 20 Mar 2013 20:16:49 -0700, Rob Seaman wrote:
 On Mar 20, 2013, at 6:02 PM, Joseph M Gwinn gw...@raytheon.com wrote:
 I would propose that ITU is using continuity and uniformity in their 
 mathematical definitions, implying that the intent is that at least 
 in definitional theory, UTC be mathematically continuous with all 
 its derivatives (noise being ignored).  This would exclude step 
 discontinuities (leap seconds) and piecewise linearity (like UT1).  
 Given that the length of a SI second is constant, what's left is a 
 UTC that is a constant offset from TAI, where the offset changes 
 only if so ordered.
 
 Relative to what?  If UT1 is an angle, then derivatives with respect 
 to angular time are stationary, and derivatives with respect to 
 atomic time vary.  At any rate, continuous is still the wrong word.  
 All the derivatives of sin(t) are continuous, but the function itself 
 is non-monotonic.

True enough, but beside my point.  The relationship between UTC and UT1 
is piecewise linear between leap seconds, so there are steps in the 
first derivative at the joints between lines,and steps in zeroth and 
first derivatives at the leap seconds.  No trig functions need apply.

It's pretty clear that ITU intends to make UTC essentially like TAI, 
but not just as a paper clock.

And I will say that in the big radars I build, leap seconds are a real 
problem, one that we solve by using GPS System Time in all but human 
interfaces.

Joe
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs