[LEAPSECS] negative leap second milestone

[John Sauter via LEAPSECS]

According to the IERS, today, for the first time since the
establishment of the modern definition of UTC in 1973, the quantity
UT1-UTC crosses zero while increasing.  If this continues we will have
a negative leap second, probably some time in the 2030s.

https://datacenter.iers.org/data/html/bulletina-xxxvi-034.html

If you project the modern definition of UTC back in time, the last time
this would have happened was in 1894.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
get my PGP public key with gpg --locate-external-keys
john_sau...@systemeyescomputerstore.com



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] DUT1 = 0

[John Sauter via LEAPSECS]

I hope everyone noticed that the IERS issued Bulletin D 142 today,
which raises DUT1 from -0.1 to 0 as of July 28.  I attach the bulletin
and my chart of values of DUT1.  I predict a negative leap second
around the end of this decade.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
get my PGP public key with gpg --locate-external-keys
john_sau...@systemeyescomputerstore.com

  INTERNATIONAL   EARTH   ROTATION AND REFERENCE SYSTEMS  SERVICE   (IERS) 
SERVICE INTERNATIONAL DE LA ROTATION  TERRESTRE ET DES SYSTEMES DE REFERENCE


SERVICE DE LA ROTATION TERRESTRE
OBSERVATOIRE DE PARIS   
61, Av. de l'Observatoire 
75014 PARIS (France)
Tel. 33 (0) 1 40 51 23 35  
http://iers.obspm.fr
email: services.i...@obspm.fr  Paris,  6 July 2022

   Bulletin D 142


 

   ANNOUNCEMENT OF DUT1


From the

  28 July 2022, 0h UTC

until further notice, the value of DUT1 to be disseminated with the 
time signals will be


  DUT1 = 0.0 s
  

Bulletin D 143 should be issued in 2023
 
 
  
To unsubscribe: 
http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletin_registration.html 
 

 


DUT1.pdf
Description: Adobe PDF document


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] podcast from Orolia

[John Sauter via LEAPSECS]

On Thu, 2022-05-05 at 20:05 +0100, Tony Finch wrote:
> John Sauter via LEAPSECS  wrote:
> > 
> > One of the links on that page is to the draft of the resolutions
> > for
> > the 27th CGPM meeting, in November 2022. Resolution D notes that
> > "recent observations on the rotation rate of the Earth indicate the
> > possible need for the first negative leap second whose insertion
> > has
> > never been foreseen or tested". However, they are calling for an
> > increase in the maximum value of UT1-UTC by 2035, which would be
> > too
> > late to avoid the negative leap second, if current predictions hold
> > up.
> 
> I have just got today's Bulletin A. The LoD term in the equation for
> more
> distant estimates of UT1-UTC is now 24h - 280 µs, down from -270 µs
> last
> week. It has been dropping rapidly again since March, after
> increasing
> slowly for half a year..
> 
> My guesstimate for the negative leap second is now end of 2027, and
> likely
> to get closer if things continue like this!
> 

To illustrate Tony's point, here is a plot of the slope of the IERS's
estimates of UT2-UTC since 2005.  Values greater than zero predict a
negative leap second.  UT2 is UT1 with seasonal fluctuations removed.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
get my PGP public key with gpg --locate-external-keys
john_sau...@systemeyescomputerstore.com



UT2_slope.pdf
Description: Adobe PDF document


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] podcast from Orolia

[John Sauter via LEAPSECS]

On Tue, 2022-05-03 at 14:20 -0700, 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/
> 

One of the links on that page is to the draft of the resolutions for
the 27th CGPM meeting, in November 2022. Resolution D notes that
"recent observations on the rotation rate of the Earth indicate the
possible need for the first negative leap second whose insertion has
never been foreseen or tested". However, they are calling for an
increase in the maximum value of UT1-UTC by 2035, which would be too
late to avoid the negative leap second, if current predictions hold up.

Also, of course, it isn't true that negative leap seconds have never
been foreseen or tested. ITU-R TF.460-6 forsees negative leap seconds,
and Microsoft made testing applications for the ability to handle leap
seconds easier when they added support for leap seconds to Windows 10.

Notice that they "propose a new maximum value for the difference (UT1-
UTC) that will ensure the continuity of UTC for at least a century". To
avoid leap seconds for a century would mean increasing the maximum
allowed value of abs(UT1-UTC) to around 60 seconds, considering that
there have been 27 leap seconds in the last half century. I expect that
means that the leap second correction, when it comes, will be 60
seconds instead of 1. After a century of no leap seconds, having a leap
minute will cause a lot of anguish. Thus, this proposal has the effect
of wishing a big problem onto our descendents so we don't have a small
problem today.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
get my PGP public key with gpg --locate-external-keys
john_sau...@systemeyescomputerstore.com



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] DUT1 about to backtrack

[John Sauter via LEAPSECS]

On Fri, 2021-01-08 at 22:51 +, Michael Deckers wrote:
> 
> On 2021-01-08 19:57, John Sauter via LEAPSECS wrote:
> 
> > I attach a plot of historical values of DUT1 based on the old
> > issues of
> > Bulletin A kept on the IERS' web site.
> 
> 
> 
>     I think the graph of DUT1 is not quite correct, for instance:
> 
>     On 2009-01-01, there was a switch of DUT1 from -0.6 s to +0.4 s
> due 
> to a leap second (Bulletin C36)
>     On 2009-03-12, there was a switch of DUT1 from +0.4 s to +0.3 s 
> (Bulletin D102)
>     Your graph only has one switch, on 2009-01-01 from -0.6 s to +0.3
> s
> 
>     Michael Deckers.

I have corrected these errors and others with the assistance of Michael
Deckers.  The updated plot is attached.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
get my PGP public key with gpg --locate-external-keys
john_sau...@systemeyescomputerstore.com



DUT1.pdf
Description: Adobe PDF document
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] DUT1 about to backtrack

[John Sauter via LEAPSECS]

On Fri, 2021-01-08 at 22:51 +, Michael Deckers wrote:
> 
> On 2021-01-08 19:57, John Sauter via LEAPSECS wrote:
> 
> > I attach a plot of historical values of DUT1 based on the old
> > issues of
> > Bulletin A kept on the IERS' web site.
> 
> 
> 
>     I think the graph of DUT1 is not quite correct, for instance:
> 
>     On 2009-01-01, there was a switch of DUT1 from -0.6 s to +0.4 s
> due 
> to a leap second (Bulletin C36)
>     On 2009-03-12, there was a switch of DUT1 from +0.4 s to +0.3 s 
> (Bulletin D102)
>     Your graph only has one switch, on 2009-01-01 from -0.6 s to +0.3
> s
> 
>     Michael Deckers.
> 
I was getting the DUT1 values from Bulletin A, but as you point out
that is not very accurate.  I tried to use Bulletin D, but it omits the
change in DUT1 caused by a leap second.  To get an accurate chart I
will have to combine the information in Bulletin D with a table of leap
seconds.

Here is the chart based only on Bulletin D.  It shows that the current
interval of no change in DUT1 is the longest since 1991.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
get my PGP public key with gpg --locate-external-keys
john_sau...@systemeyescomputerstore.com



DUT1.pdf
Description: Adobe PDF document
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] DUT1 about to backtrack

[John Sauter via LEAPSECS]

The IERS specifies in Bulletin A the value for DUT1, which is an
approximation of UT1-UTC that is transmitted with time signals.  The
current value is -0.2, which has not changed since May of 2019, an
unusually long time.

If the IERS prediction of future values of UT1-UTC turns out to be
correct, the value of DUT1 will increase to -0.1 in July of 2021. 
Other than the jumps caused by leap seconds, that will be the first
increase in DUT1 since at least 2005.

I attach a plot of historical values of DUT1 based on the old issues of
Bulletin A kept on the IERS' web site.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
get my PGP public key with gpg --locate-external-keys
john_sau...@systemeyescomputerstore.com



DUT1.pdf
Description: Adobe PDF document
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap seconds, newspapers, earth rotation

[John Sauter via LEAPSECS]

On Wed, 2021-01-06 at 10:36 -0800, Tom Van Baak wrote:
> "Atomic clock scientists suggest shortening minute to 59 seconds"
> 
> This is so bad it's funny. [1] A newspaper headline that's inaccurate
> by 
> a factor of, just, 100 million.
> 
> Why? If time had 59 minutes per hour instead of 60 the clock rate
> would 
> be off by 0.983  And if we had a leap second (positive or negative, 
> doesn't matter), say every 3 years, the clock rate would be off by 
> 1.06e-8. The ratio of those two is 9.3e7, about 100 million.
> 
>  From a pedagogical perspective, it's a nice way to demonstrate just
> how 
> tiny a leap second adjustment really is.
> 
> By the way, a number of news web sites have been carrying "earth is 
> speeding up" and "50 years" stories the past week or so. I've read a 
> number of them. Ouch. Does anyone know who started it? Is there a way
> to 
> track it down?
> 
> It hope it wasn't LEAPSECS; we have had an influx of members in
> recent 
> months. Fortunately the mailing list has remained very technical, and
> pragmatic about the issue.
> 
> Thanks,
> /tvb
> 
> [1] 
> https://nypost.com/2021/01/05/atomic-clock-scientists-suggest-subtracting-a-second-from-minute/
> 

The story linked above contains a link to The Telegraph which is
blocked unless you are subscriber.  Here is an unblocked link to the
Telegraph story:

https://kaleistyleguide.com/news/2021/01/04/earth-spinning-faster-now-time-past-half-century/

The meat of the story is a quotation from Peter Whibberley, said to be
a senior research scientist with the National Physical Laboratory's
time and frequency group.  He is claimed to have said:

“It is certainly correct that the Earth is spinning faster now than at
any time in the last 50 years. 

“It’s quite possible that a negative leap second will be needed if the
Earth’s rotation rate increases further, but it’s too early to say if
this is likely to happen. 

“There are also international discussions taking place about the future
of leap seconds, and it’s also possible that the need for a negative
leap second might push the decision towards ending leap seconds for
good.”

The only reference to shortening the minute to 59 seconds is in the
headline in the New York Post story.  The headline writer appears to
have made up this claim without any regard for journalistic norms of
truth.  I do not usually read the New York Post so I do not know if
this is the regular practice there.

If you take the IERS projection of future values of UT2 literally, the
next leap second will be on December 31, 2047, and it will be a
negative leap second.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
get my PGP public key with gpg --locate-external-keys
john_sau...@systemeyescomputerstore.com



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap second hiatus

[John Sauter via LEAPSECS]

The November 19, 2020 IERS Bulletin A (volume XXXIII number 047) has
this line:

 UT1-UTC = -0.1728 + 0.1 (MJD - 59180) - (UT2-UT1) 

Taking this prediction of UT2 literally, it suggests that the next leap
second will be on June 30, 2246, and it will be negative.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E



UT2_slope.pdf
Description: Adobe PDF document
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] long interval predicted

[John Sauter via LEAPSECS]

I believe there will be several years between the the last leap second
and the next, as there was between December 31, 1998 and December 31,
2005.  The IERS publishes a long-term prediction of the average
rotation rate of the Earth, which they update in their Bulletin A each
week.  The August 6, 2020, issue of Bulletin A contains this line:

 UT1-UTC = -0.2147 - 0.00010 (MJD - 59075) - (UT2-UT1)   

UT2 captures the seasonal change in the length of day, so it can be
ignored for long-term estimates.  The important number, therefore, is
-0.00010, which I will call the UT1 slope.

The June 9, 2016, issue of Bulletin A contains this line:

 UT1-UTC = -0.1734 - 0.00147 (MJD - 57556) - (UT2-UT1)

Which has UT1 slope equal to -0.00147.  Since then the value of UT1
slope has increased steadily to its present value.  It is larger now
than it has been at any time since January 6, 2005, which is the oldest
issue of Bulletin A that I have been able to locate.  Based on the
current value of -0.00010 I estimate that the next leap second will be
on December 31, 2025, an interval of 9 years, which is longer than the
previous long interval of 7 years.

I attach a chart of UT1 slope since January 2005.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E



UT1_slope.ods
Description: application/vnd.oasis.opendocument.spreadsheet
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] no more listening to leap seconds?

[John Sauter]

> 
> Time and Fundamental Measurement Dissemination (-$6.3 million and
> -36 FTE) – NIST
> will continue to maintain the U.S. time standard, and continue to 
> advance the development of
> best in the world atomic clocks as part of its core foundational work
> in this area, and
> disseminate standard time through the internet. However, NIST will 
> discontinue the
> dissemination of the U.S. time and frequency via the NIST radio
> stations in Hawaii and
> Ft. Collins, CO. These radio stations transmit signals that are used
> to synchronize consumer
> electronic products like wall clocks, clock radios, and
> wristwatches, and may be used in other
> applications like appliances, cameras, and irrigation controllers.
> NIST will also scale back
> efforts to disseminate, and halt efforts to improve, and expand the 
> atomic spectra database that serves a wide range of users.

This sounds like the tactic used by schools when the voters threaten to
reduce their budget--they say they will eliminate their most popular
programs: football, other after-school sports, music, art and drama. 
That gets them the votes they need to prevent their budget from being
reduced.
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

Re: [LEAPSECS] next leap second

[John Sauter]

In honor of IERS Bulletin C56, I am updating my prediction of the next
leap second.  I now think it will be at the end of December 31, 2020.

I have a web page where I describe how I make my prediction.  To avoid
offending the list moderator I will not place the URL here, but if
anyone wants it I will be glad to provide it--just e-mail me.
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

Re: [LEAPSECS] next leap second

[John Sauter]

On Wed, 2017-01-11 at 13:07 +, Zefram wrote:
> John Sauter wrote:
> > While it is impossible to know for certain when the next leap
> > second
> > will occur, I predict it will be December 31, 2022.
> 
> I find that a surprising prediction.  What is your basis for it?
> 
> The extrapolating expression from the current Bulletin A
> <https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxx-0
> 01.txt>,
> which projects a linear evolution of UT2-TAI, suggests that UT1-TAI
> will approach -37.5 in early 2019 (actually passing it on 2019-02-
> 03),
> and then pass that value twice more early in the second half of 2019.
> So I'd expect the next leap second to happen on 2018-12-31 or 2019-
> 06-30.
> If there is no leap, this projection suggests that the UT1-UTC bound
> would
> be exceeded on 2020-01-19.  Extending all the way out to your
> proposed
> leap date, which is a dubious exercise given the crudity of the
> model,
> yields UT1-TAI ~= -39.228 at 2023-01-01, implying that we'd need to
> have
> two leaps between now and then, with 2022-12-31 being an early
> candidate
> for the *third* leap from now.
> 
> -zefram

Based on recent data from the IERS, I now think that the next leap
second will be on June 30, 2020, rather than December 31, 2020.
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

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

[John Sauter]

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.
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

Re: [LEAPSECS] Amazon canonizes leap smear

[John Sauter]

I added a comment to the blog post expressing my disappointment with
their use of smeared time, and referencing my paper on avoiding the use
of POSIX time_t for telling time.  The comment was initially held, and
has now disappeared.  I guess they don't like criticism.
John Sauter (john_sau...@systemeyescomputerstore.com)


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

Re: [LEAPSECS] leap second roundup 2017

[John Sauter]

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.
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

Re: [LEAPSECS] leap second roundup 2017

[John Sauter]

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?
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

Re: [LEAPSECS] Negative TAI-UTC

[John Sauter]

On Sat, 2017-02-04 at 16:41 +, 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?
> 
I think it is very unlikely that we will have 37 more negative than
positive leap seconds in the future.  See

https://upload.wikimedia.org/wikipedia/commons/5/5b/Deviation_of_day_length_from_SI_day.svg

for a graph of the deviation of the length of the day from 86,400 SI
seconds.  The red line would have to drop to 0 ms before TAI-UTC became
negative.

However, if I were designing the data structure I would use a 32-bit
integer for TAI-UTC, just to be safe.
John Sauter (john_sau...@systemeyescomputerstore.com)

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

Re: [LEAPSECS] BBC radio Crowd Science

[John Sauter]

On Tue, 2017-01-31 at 14:44 -0700, Warner Losh wrote:

...

> In both cases, we did need to know that 23:59 had 61 seconds, but we
> didn't need to have a special leap second flag associated with any of
> the timestamps for the math to work out right. Knowing that it has 61
> seconds sometimes is exactly the same thing as knowing that sometimes
> February has 29 days some years. The only difference is that one is a
> math formula for thousands of years, and the other is a table lookup.

...

In my time manipulation subroutines I have functions to compute the
length of the current and previous month, and the current and previous
minute, in both local time and UTC.  To compute the length of February
I do the Gregorian calculation.  To compute the length of minute 23:59
I look up the value of TAI-UTC in a table.
John Sauter (john_sau...@systemeyescomputerstore.com)

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

Re: [LEAPSECS] BBC radio Crowd Science

[John Sauter]

On Sun, 2017-01-29 at 15:09 -0500, Steve Summit wrote:
> Tom Van Baak wrote
> > John Sauter wrote:
> > > I had thought that TAI-UTC was the only information needed to
> > > convert
> > > from TAI to UTC [...] Is
> > > my new belief correct that you need both TAI-UTC and the
> > > knowledge that
> > > a leap second is in progress to convert from TAI to UTC?
> > 
> > Hmm, it sounds like your new belief is wrong too. [...] The table
> > is all
> > you need to decide how to convert between TAI/UTC and UTC/TAI. Yes,
> > the
> > code gets tricky near +/- N seconds of midnight, where N is |TAI-
> > UTC|.
> 
> I think John's point is that if all I have is a TAI timestamp t,
> and an interface to a leapsecond table that returns taioffset(t)
> for TAI time t, that's not quite enough to unambiguously compute
> the corresponding UTC timestamp.  If I take t and subtract
> taioffset(t), I don't know whether the UTC result I get should
> end in :60, so to speak.
> 
> As it happens, just last week I write a TAI-to-UTC conversion
> function, and I had to invent a new interface into my leapsecond
> table: it returns the TAI-UTC offset for a given time t, *and* it
> returns the time of the transition nearest to t, which is what's
> needed to make the leap-second determination John is talking about.

I think it would be sufficient to know the TAI-UTC value for the
current time, and for the current time + one second.  If the future
value is one greater than the current value, there is a leap second in
progress.
John Sauter (john_sau...@systemeyescomputerstore.com)

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

Re: [LEAPSECS] BBC radio Crowd Science

[John Sauter]

Thank you, Tom and Steve, for your corrections to my misunderstanding. 
Looking at the first part of Steve's table:

> 
> Positive leap second:
> 
>   TAI   UTC   TAI-UTC
>   00:00:34.023:59:59.035
>   00:00:34.523:59:59.535
>   00:00:35.023:59:60.035
>   00:00:35.523:59:60.535
>   00:00:36.000:00:00.036
>   00:00:36.500:00:00.536

TAI is the fundamental time scale, with UTC derived from it.  As TAI
advances, you can calculate UTC by subtracting TAI-UTC from it.  At TAI
= 34 seconds, TAI-UTC is 35 and the corresponding UTC time is 23:59:59.
 That can be arithmetically correct only if you don't count the leap
second, so let's not count it.

When the TAI time is 35 seconds, you would think the UTC time would be
0 seconds, but because of the leap second it is 23:59:60.  Thus, the
value of TAI-UTC doesn't tell you everything you need to know to
convert from TAI to UTC: you also have to know that there is a leap
second in progress.

When the TAI time is 36 seconds, and TAI-UTC is now 36, the UTC time is
0, which is what you would expect.

I had thought that TAI-UTC was the only information needed to convert
from TAI to UTC, and therefore that it could not be a step function
because of positive leap seconds.  I see now that I was mistaken.  Is
my new belief correct that you need both TAI-UTC and the knowledge that
a leap second is in progress to convert from TAI to UTC?
John Sauter (john_sau...@systemeyescomputerstore.com)

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

Re: [LEAPSECS] BBC radio Crowd Science

[John Sauter]

On Sun, 2017-01-29 at 15:33 +, Michael.Deckers. via LEAPSECS wrote:
> 
> On 2017-01-29 04:48, John Sauter writes about labeling a positive
> leap second 59 as done by Felicitas Arias:
> 
> > She prefers to label the leap second as a second 23:59:59, but the
> > UTC
> > definition calls it 23:59:60.
> 
> Yes, of course -- I did not want to dispute that.
> 
> 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.

Based on the definition of UTC, it seems to me that there are two
cases, both of which are very simple.  For a negative leap second, the
change in TAI - UTC happens instantly at UTC midnight, which is one
second after 23:59:58, when the difference changes by -1.  For a
positive leap second, the change happens gradually over the time of the
leap second, from 23:59:60 to midnight, when the difference slowly
changes by +1.

> And about the "danger" of leap seconds through computer
> failures, John Sauter writes:
> 
> 
> > I would not blame leap seconds but the programmer who did not
> > properly
> > test for leap seconds when developing his software.  Leap seconds
> > have
> > been around for over 30 years, so it isn't like they are a new
> > requirement.
> 
> Of course you are right -- leap seconds cannot be blamed for
> computer
> failures, but careless programmers and inconsistent or incomplete
> program specifications may well be.
> 
> But my point was not who or what was to blame -- I rather wanted
> to
> indicate circumstances where even the slowest bureaucracy can
> react swiftly in a very pragmatic manner: if the presence of
> leap seconds might cause harm to human health then their
> abolition
> is likely. See the introduction of the unit Sv as a special name
> for Gy by the BIPM as an example.
> 
> Michael Deckers.

This sounds like an interesting story--can you provide more details, or
a reference?  I was able to learn only the basic facts:

http://www.bipm.org/metrology/ionizing-radiation/units.html

John Sauter (john_sau...@systemeyescomputerstore.com)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[John Sauter]

On Sat, 2017-01-28 at 20:56 +, Michael.Deckers. via LEAPSECS wrote:
> 
> On 2017-01-28 17:33, Steve Allen wrote:
> > BBC radio Crowd Science took a listener question about
> > What is the Real Time?
> > and produced a half hour tour that included three atomic Time Lords
> > Whibberley, Matsakis, and Arias.
> > http://www.bbc.co.uk/programmes/p04q778b
> > and concluded pretty much saying that we have a choice.
> 
> Thanks for that link!
> 
> I find it remarkable that Arias in effect stated
> that the discontinuities of the difference TAI - UTC
> happen at the beginning of leap seconds, so that
> positive leap seconds are labeled as the second
> 59th seconds of a minute. Neither the ITU definition
> of UTC nor the IERS bulletins about leap seconds
> specify that detail, unfortunately.

She prefers to label the leap second as a second 23:59:59, but the UTC
definition calls it 23:59:60.

> She is also stated to call leap seconds a
> "dangerous thing" -- as soon as this is
> substantiated (such as by a loss of health
> connected with a computer misinterpretation
> of leap seconds) it will be a powerful argument
> for their abolition.
> 
> Michael Deckers.

I would not blame leap seconds but the programmer who did not properly
test for leap seconds when developing his software.  Leap seconds have
been around for over 30 years, so it isn't like they are a new
requirement.
John Sauter (john_sau...@systemeyescomputerstore.com)

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

Re: [LEAPSECS] next leap second

[John Sauter]

On Thu, 2017-01-12 at 09:18 -0800, Michael Shields via LEAPSECS wrote:

> It might also be helpful if we understood better how these models are
> used to decide when to announce leap seconds.  I don't know currently
> what criteria the IERS uses, except the overall parameters of keeping
> > UT1-UTC| < 0.9 s and preferring to have leap seconds in June or
> 
> December instead of other months.
> 
> For example, here's Bulletin A from 2016-06-30:
> 
> https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxix-0
> 26.txt
> 
> 2016-12-31 (MJD 57753): -0.45079 s
> 2017-06-30 (MJD 57934): -0.73759 s
> 
> You might have expected either of these days to have leap seconds.
> The next week, Bulletin C Number 52 announced a leap second for
> 2016-12-31.  The actual value of UT1-UTC on that day was about
> -0.407858 s.
> 
> The predictions looked similar on 2014-06-26:
> 
> https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxvii-
> 026.txt
> 
> 2014-12-31 (MJD 57022): -0.46583 s
> 2015-06-26 (MJD 57199): -0.67258 s
> 
> Again, either December 2014 or June 2015 could have had leap seconds.
> But in this case the leap second was deferred.  It happened on
> 2015-06-30, when UT1-UTC was -0.6760362 s
> (https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/207/bulletinb-330
> .txt).

I tried to find an algorithm that would predict the IERS announcements
of leap seconds, but failed.  Here is the closest I was able to come:

Take a span of time in which the difference between UT1 and UTC is
continuously between 0.1 and 0.9.  This is the span in which a leap
second is permitted.  You can't do a leap second when the difference is
less than 0.1 because that would make the new difference greater than
0.9.

Within that span, look for a December 31 or June 30.  If you find
exactly one, that is the leap second date.  If you find more than one,
choose the one in which the difference between UT1 and UTC is closest
to 0.5.  It is in principle possible for there to be no December 31 or
June 30 within the span, though that hasn't happened yet.  If it does,
choose March 31 or September 30.  If they are also missing from the
span, choose the last day of any month.

That algorithm comes close to the actual schedule, but does not exactly
match.  Perhaps someone can improve the algorithm and we can apply it
to predict future leap seconds.  Keep in mind that the IERS may have
improved their algorithm since 1972, so we may be looking at a moving
target.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] next leap second

[John Sauter]

On Wed, 2017-01-11 at 13:07 +, Zefram wrote:
> John Sauter wrote:
> > While it is impossible to know for certain when the next leap
> > second
> > will occur, I predict it will be December 31, 2022.
> 
> I find that a surprising prediction.  What is your basis for it?
> 
> The extrapolating expression from the current Bulletin A
> <https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxx-0
> 01.txt>,
> which projects a linear evolution of UT2-TAI, suggests that UT1-TAI
> will approach -37.5 in early 2019 (actually passing it on 2019-02-
> 03),
> and then pass that value twice more early in the second half of 2019.
> So I'd expect the next leap second to happen on 2018-12-31 or 2019-
> 06-30.
> If there is no leap, this projection suggests that the UT1-UTC bound
> would
> be exceeded on 2020-01-19.  Extending all the way out to your
> proposed
> leap date, which is a dubious exercise given the crudity of the
> model,
> yields UT1-TAI ~= -39.228 at 2023-01-01, implying that we'd need to
> have
> two leaps between now and then, with 2022-12-31 being an early
> candidate
> for the *third* leap from now.
> 
> -zefram

My prediction is based on combining the information from two sources. 
The first is the IERS predictions for UT1-UTC, at this URL:

https://datacenter.iers.org/eop/-/somos/5Rgv/latestXL/7/finals.all/csv


It shows the value of UT1-UTC was -0.4078580 on December 31, 2016, and
0.5911620 on January 1, 2017, immediately after the leap second.  It
predicts a value of 0.1021884 on January 13, 2018, which is a decrease
of 0.4889736.  If the rate of decrease is constant the next leap second
will be around December 31, 2018 or perhaps June 30, 2019, which is the
same as your estimate.

My second source is the estimates of delta T from Stephenson, Morrison
and Hohenkerk.  Their data is at this URL:

http://astro.ukho.gov.uk/nao/lvm/

If you look at their projections from 1950 to 2016, they expect delta T
to be 68.04 at the beginning of 2016.  Looking at the projections for
2017 to 2500, they expect delta T to be 67 at 2017, then 68 until 2020,
and increase to 70 by 2030.  I regard the decrease from 2016 to 2017 as
a glitch in the join between two tables, so I regard their paper as
predicting no change in delta T from 2016 to 2020.  

In order to create my table of leap seconds before 1972, I simulated
the IERS process using historical delta T data.  Extending that
simulation forward, I predict December 31, 2022 as the next leap
second.

It will be interesting to see what actually happens.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

I have updated my time papers to reflect Bulletin C number 53 from the
IERS, which confirmed that there will not be a leap second for at least
six months.  "Extending Coordinated Universal Time to Dates Before
1972" is at this URL:

https://commons.wikimedia.org/wiki/File:Extending_Coordinated_Universal_Time_to_Dates_Before_1972.pdf

Building upon the results presented in that paper is "Avoid Using POSIX
time_t for Telling Time", at this URL:

https://commons.wikimedia.org/wiki/File:Avoid_Using_POSIX_time_t_for_Telling_Time.pdf

The latter paper includes some subroutines to make it easy for
application programmers to use the tm structure rather than time_t. 
Steve Summit has kindly agreed to host that software on his web site
for those who are unable to extract it from the PDF file, at this URL:

http://www.eskimo.com/~scs/time/sauter/

I would appreciate any feedback that anyone would care to provide on
these papers.  I am particularly interested in knowing about errors in
the software.  It is my hope that this software will be used by
application programmers to avoid the bugs caused by time running
backwards that we saw in the most recent leap second.

While it is impossible to know for certain when the next leap second
will occur, I predict it will be December 31, 2022.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Mon, 2017-01-09 at 13:41 +0100, Preben Nørager wrote:
> On Tue Jan 3 14:18:52 EST 2017, John Sauter wrote:
> 
> "I regard leap seconds as a reasonable compromise between the needs
> of civil time and of science. Civil time needs a clock that tracks
> the days and the seasons. Science requires a clock that measures time
> in precise intervals. UTC provides both, using leap seconds to keep
> atomic time synchronized with the rotation of the Earth."
> 
> I think there is something wrong with that argument. Civil
> timekeeping holds both a clock, and a calendar. The calendar track
> the seasons, while the clock track the time. If it is to be said,
> that the clock track the days, it is important to notice the
> difference between apparent time, and mean time. The clock track
> either the sun (apparent time), or the seconds (mean time). 
> 
> When the Nautical Almanac in 1833 substituted mean for apparent solar
> time, an important step was taken. From now on chronometry was to
> rely on mechanical clocks, and with the invention of atomic clocks,
> the tracking of the 24-hour day (86400 international seconds) can now
> happen without any daily tracking of the sun.     
> 
> The question really is whether the calendar needs the daily tracking
> of the sun or not. And the answer to that question obviously depend
> upon which calendar we want!  
> 
> I think the disagreement about leap seconds, really is a disagreement
> about which calendar to use for civil timekeeping. If we agree to use
> the proleptic gregorian calendar (ISO 8601) there is really no need
> for leap seconds. That calendar track the seasons well, and with the
> slight modification, to add the additional rule that years evenly
> divisible by 4000 are not leap years, it would track them even
> better. 
> 
> Leap seconds are really only a need for those who do not want to see
> the proleptic gregorian calendar become universal. For instance for
> those who want to use the julian period, as the basis for one
> calendar or another, because they must somehow rely on apparent time,
> and not mean time, because the julian period count apparent solar
> days. 
> 
> Let us use ISO 8601, and abolish leap seconds all together.

ISO 8601 handles leap seconds perfectly well.  In ISO 8601 format, the
most recent leap second was named 2016-21-31T23:59:60Z.

I don't understand what you mean when you say "Leap seconds are really
only a need for those who do not want to see the proleptic gregorian
calendar become universal."  I would have no objection to the proleptic
Gregorian calendar becoming universal (though I would not force it on
anyone who did not like it) and yet I am a supporter of leap seconds.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] IERS Bulletin C number 53

[John Sauter]

 INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) 

SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE


SERVICE DE LA ROTATION TERRESTRE
OBSERVATOIRE DE PARIS
61, Av. de l'Observatoire 75014 PARIS (France)
Tel.  : 33 (0) 1 40 51 23 35
FAX   : 33 (0) 1 40 51 22 91
Internet  : services.i...@obspm.fr

 Paris, 9 January 2017
   

 Bulletin C 53

 To authorities responsible
 for the measurement and 
 distribution of time 




  INFORMATION ON UTC - TAI
  

 NO leap second will be introduced at the end of June 2017.
 The difference between Coordinated Universal Time UTC and the 
 International Atomic Time TAI is : 

 from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s

 Leap seconds can be introduced in UTC at the end of the months of December 
 or June,  depending on the evolution of UT1-TAI. Bulletin C is mailed every  
 six months, either to announce a time step in UTC, or to confirm that there 
 will be no time step at the next possible date.


Christian BIZOUARD
Director
Earth Orientation Center of IERS
Observatoire de Paris, France
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Sat, 2017-01-07 at 09:38 -0500, Daniel R. Tobias wrote:
> On 6 Jan 2017 at 22:44, Hal Murray wrote:
> 
> > I think there are two different types of wait.  One is the simple
> > wait N 
> > seconds.  The other is wait until a specified date-time, say a
> > month from 
> > now.  They really are different so I don't see how to make your
> > "one 
> > interface" work.
> 
> It seems you can come up with quite a few "types of wait", or types 
> of scheduling for future events, appointments, announcements, and so 
> on, all of which ought to be supported in robust calendaring / 
> scheduling programs.
> 
> * Events scheduled for a fixed point relative to local civil time at 
> a specific place; its point in absolute time can change if time
> zones 
> or daylight saving rules shift. Most local events, work shifts, and 
> so on are like that.
> 
> * A fixed point relative to a particular named time zone, like "U.S. 
> Eastern time". National TV networks tend to schedule their
> broadcasts 
> this way. This won't shift in response to time zone boundary
> changes, 
> like if Indiana decides to change time zones between Eastern and 
> Central, but will reflect changes in daylight saving shift dates
> that 
> apply zone-wide.
> 
> * Fixed point relative to UTC; won't change for time zone and 
> daylight saving shifts, but will reflect leap seconds.
> 
> * Fixed point relative to a leapless atomic scale such as TAI or
> GPS; 
> its' place relative to UTC will shift for leap seconds, and its
> place 
> relative to local time will shift for leap seconds, daylight saving, 
> and time zone shifts.
> 
> * Interval-time wait by absolute number of SI seconds (ignoring 
> leaps, time zones, and the like).

I think a more common kind of wait is by number of SI seconds, ignoring
time zones but not leaps.  For example, if a device timeout is
specified as 5 seconds, you want to give it 5 seconds to respond, even
if one of those seconds is a leap second.

> * Interval-time wait by number of some larger unit such as minutes, 
> hours, days, or years as reckoned in some particular time scale; 
> there may be leaps built in to it.
> 
> Some of these can also be put into some turmoil if more drastic 
> calendar-system changes are made such as the Julian/Gregorian shift 
> (and any future such thing that might be needed millennia from now 
> when the current calendar proves astronomically inadequate).
> 

While the operating system and system libraries should provide support
for implementing all of these kinds of wait, the responsibility for
distinguishing them is in the application.  A scheduling application
given "03:00" needs to know whether the time is local or UTC, and if it
is local time whether "03:00" really means 3 AM or 3 hours after
midnight, the difference being due to daylight saving time.

An example of application-specific interval calculation is paychecks
for third-shift workers.  Labor law says workers get paid for the
number of hours they work, no matter what the clock says.  If I work
from midnight to 8 AM, I get paid for 8 hours on most days, but once a
year I get 9 hours pay for 9 hours of work, and once a year I get 7
hours pay for 7 hours of work.

Fortunately, leap seconds are small enough adjustments that the labor
laws don't care about them, or we would have to adjust a worker's pay
whenever a leap second fell on the worker's shift.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Fri, 2017-01-06 at 22:44 -0800, Hal Murray wrote:

> 
> I hate bloat and crufty code as much as anybody.  A library routine
> to handle 
> all the quirks of leap seconds and leap years and daylight savings
> seems 
> reasonable to me.  But maybe I'm overlooking somethings, so that's
> why I 
> asked.

I have published such a library.  See

<https://commons.wikimedia.org/wiki/File:Avoid_Using_POSIX_time_t_for_T
elling_Time.pdf>

or just search the Web for "Avoid Using POSIX time_t for Telling Time".

If you find that I've missed something, please let me know.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

On Sat, 2017-01-07 at 07:18 -0500, Steve Summit wrote:

> Well, I've concluded I really don't want to put leap seconds
> in the filesystem anyway, for a different set of reasons.
> On leap-second days, clock_gettime(CLOCK_UTC) and
> clock_gettime(CLOCK_REALTIME) necessarily return slightly
> different times.  The legacy calls gettimeofday() and time()
> return whatever CLOCK_REALTIME returns.  And file timestamps
> have to be touched with whatever CLOCK_REALTIME returns, too,
> because Posix says that stat() yields time_t timestamps, and
> legacy code is allowed to fetch the time and touch a file and
> fetch the file's mtime and expect the two timestamps to be nearly
> identical, not to differ by up to a second if smearing is in
> progress.  If you put leap seconds in the filesystem, you have to
> start smearing or unsmearing the timestamps on every stat() call,
> plus you have to have some flag, or different call, by which the
> caller can request whether he wants leapsecond-aware timestamps
> back or not.  Another fine mess, and this one I have no interest
> in tackling.

Perhaps there could be a kernel boot parameter which specified that
CLOCK_REALTIME should act just like CLOCK_UTC.  This would allow brave
souls to work through the problems caused by a fully-UTC kernel,
including EXT4 not storing all 64 bits of a timeval in its mtime, atime
and ctime fields.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[John Sauter]

On Sat, 2017-01-07 at 10:56 +, Zefram wrote:
> 
> No, the Gregorian calendar is yet another thing that doesn't imply
> 86400-second days.  (POSIX time_t is another.)  There's a general
> pattern
> here that whenever there's some construct that counts or labels days,
> and is (as most are) silent on the fine internal structure of those
> days,
> you (Brooks) interpret it as specifying that the days consist of
> exactly
> 86400 SI seconds.  (Or atomically-realised seconds, which you do not
> distinguish from SI seconds.)  I cannot think of an occasion when you
> have drawn that inference and been correct.
> 
> -zefram

I beg to differ.  The POSIX definition of time_t (4.16 Seconds since
the Epoch) says "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 for by exactly 86400
seconds."

See <http://pubs.opengroup.org/onlinepubs/9699919799/>.
john Sauter (john_sau...@systemeyesocmputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

On Wed, 2017-01-04 at 21:58 -0700, Warner Losh wrote:

> 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.
> 
When the kernel reports time in UTC, it adds 1e9 to the nanoseconds
field of a timeval to indicate that a leap second is in progress. 
Thus, a properly-interpreted timeval never runs backwards.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Wed, 2017-01-04 at 19:04 +0100, Preben Nørager wrote:
> On Wed, 2017-01-04 at 18:11 +0100, John Sauter wrote:
> 
> "I am curious: since you do not think my moral concern is future
> generations, what do you think it is?"
> 
> I think your moral concern is the misguided belief, that abolishing
> leap seconds will mean our official time will depend solely on cesium
> atoms, with no connection to the rotation of the earth. But that
> belief is in my view misguided, because, as we have already agreed
> upon, our gregorian calender keeps our time in synchronization with
> the seasons, as they appear on earth because of the rotation of the
> earth around the sun. So the connection between our time and earth
> rotation is in that way everlasting - with leap seconds or without.
> But maybe you are a Brit who would just like to se british time
> correspond to universal time forever? 
> 
> Preben

Thank you for answering my question; it turns out that our positions
are more in agreement than I had thought.

I do not believe that abolishing leap seconds will mean our official
time will depend solely on Cesium atoms, with no connection to the
rotation of the Earth.  Rather I believe that abolishing leap seconds
will require a future generation to re-synchronize official time with
the rotation of the Earth, as was done with the seasons in 1582, and
that it is wrong of us to force that burden on them for our
convenience.

Imagine that you are Julius Caesar, reforming the calendar.  You have a
choice of leap year algorithms: every four years, or a more complex
formula that keeps the calendar closer to the astronomical year.  Your
astronomers urge the latter, but you are conflicted: the simpler
formula is more likely to be applied accurately, but the consequence is
that a future generation will have to skip 10 days and adopt the more
complex calculation anyway.  What is the right choice to make?

In Caesar's case the civil servants who managed the calendar after his
death couldn't even count to 4 accurately, but computers are better
today.

By the way, I am not a Brit; I am a mostly-retired computer programmer
living in New Hampshire, USA.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Wed, 2017-01-04 at 16:29 +0100, Preben Nørager wrote:
> On Wed, 2017-01-04 at 15:25 +0100, John Sauter wrote:
> 
> "Preben, You and I disagree on this issue.  For me this is
> fundamentally a moral
> concern.  I believe that each generation should handle its problems
> as
> best it can, leaving to the next generation only unforeseen problems.
>  
> The tension between the need of civil society and science for a time
> scale that simultaneously matches the Earth and atomic time is met by
> the Gregorian Calendar and UTC.
> The reform that brought the calendar back into synchronization with
> the
> seasons was proposed several times but got no traction until 1582.
> That generation bit the bullet and suffered the dislocation of
> dropping
> 10 days from the calendar rather than continue to defer the problem.
> It took centuries for everyone to get on-board, but today almost
> everyone uses the Gregorian calendar.
> UTC, as it is defined today with leap seconds, is a similar
> challenge.
> We can fix the buggy software or we can cause a problem for the next
> generation.  I feel that it would be immoral to remove an adequate
> solution just because we are too lazy to write code correctly."
> 
> --
> 
> Dear John,
> The existing leap-second-system will not last forever. Because of
> future deceleration of earth rotation, the need for leap seconds will
> sometime become so immense, that future generations will have to have
> another system anyway. And as I said international atomic time, with
> national official time zones, seems the best way forward. I agree
> with you that the gregorian reform was a good thing, but there were
> actually two different aspects of that reform. The first was the new
> rule for leap years. That new rule brought the calendar back into
> synchronization with the seasons and hurra for that. The other aspect
> was the dropping of ten days. I don't know exactly why the march
> equinox shall occur allways around march 21. Would allways around
> march 11 not have been just as good? Anyway, meeting the need for
> synchronization with the seasons is not the same as meeting the need
> for synchronization with solar noon. The gregorian calendar can meet
> the need of the one, and atomic time with time-zones can meet the
> need of the other. I think honestly your moral concern is not future
> generations, but something else.  
> Preben

Dear Preben,

I agree that the existing leap second system will not last forever, but
it will be about 1000 years before we need more than one leap second
per month, and that's a long time in my book.

I believe the dropping of 10 days was to get the calendar synchronized
with the traditional dates of the seasons, as they were in the third
century.  The equivalent in UTC would be to adjust the time zone so
that 12:00 local time corresponds to the Sun being high in the sky.

I am curious: since you do not think my moral concern is future
generations, what do you think it is?  Feel free to answer privately if
you don't think your answer is suitable for the leap seconds mailing
list.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Wed, 2017-01-04 at 09:42 -0500, Michael Rothwell wrote:
> The Gregorian calendar doesn't mess up how computers keep track of
> time, like leap seconds do. Neither do time zones. Leap seconds are
> different -- a special kind of awful.

I don't regard leap seconds as being a special kind of awful.  The
Gregorian calendar has February, which if it had been introduced in
1972 would have been regarded as "awful" for computers because it has a
variable length.  Most computer software deals with February correctly
because it has been around longer than computers.  The same is true of
time zones.  Leap seconds, with its variable-length minutes, seems
worse only because it was introduced relatively recently.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Sun, 2017-01-01 at 16:29 -0500, John Sauter wrote:
> 
> If anyone has difficulty extracting the software from the PDF using
> okular, e-mail me and I will provide the files separately.

Steve Summit has been kind enough to host the code on his web site.

The URLs are:
http://www.eskimo.com/~scs/time/sauter/tmcode.tar.gz
http://www.eskimo.com/~scs/time/sauter/tmcode.zip
ftp://ftp.eskimo.com/home/scs/sauter/tmcode.tar.gz
ftp://ftp.eskimo.com/home/scs/sauter/tmcode.zip

There is also a cover page at:
http://www.eskimo.com/~scs/time/sauter/index.html

John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] JD & MJD, UT1 & UTC

[John Sauter]

On Wed, 2017-01-04 at 15:22 +0100, Martin Burnicki wrote:
> John Sauter wrote:
> > I did some experimenting with this on Fedora 25, Linux kernel
> > 4.8.15- 300.fc25.x86_64.  I found that adjtimex sets STA_NANO and
> > returns nanoseconds only when NTP has been running for a while. 
> > John Sauter (john_sau...@systemeyescomputerstore.com)
> 
> Ah, interesting.
> 
> Did you also have a chance to see if the kernel returns microseconds
> rather then nanoseconds if ntpd has *not* set this flag?
> 
> Thanks,
> Martin

Yes.  I determined that if NTPD has been running for only a short time
the value returned is microseconds and the STA_NANO flag is not set.

The code looks like this:

/* Subroutine to return the current UTC time in a tm structure
 * and the number of nanoseconds since the start of the last second.  
 */
int
time_current_tm_nano (struct tm *current_tm, int *nanoseconds)
{
  struct timex current_timex;
  int adjtimex_result;

  /* Fetch time information from the kernel.  */
  current_timex.status = 0;
  current_timex.modes = 0;
  adjtimex_result = adjtimex (_timex);

  /* Format that information into a tm structure.  */
  gmtime_r (_timex.time.tv_sec, current_tm);

  /* If the kernel told us we are in a leap second, increment
   * the seconds value.  This will change it from 59 to 60.  */
  if (adjtimex_result == TIME_OOP)
{
  current_tm->tm_sec = current_tm->tm_sec + 1;
}

  /* Return the number of nanoseconds since the start of the last
   * second.  If the kernel's clock is not being controlled by
   * NTP it will return microseconds instead of nanoseconds.  */
  if (current_timex.status & STA_NANO)
*nanoseconds = current_timex.time.tv_usec;
  else
*nanoseconds = current_timex.time.tv_usec * 1e3;

  return (0);
}

During the recent leap second I also verified that adjtimex returns TIME_OOP.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] JD & MJD, UT1 & UTC

[John Sauter]

On Wed, 2017-01-04 at 13:40 +0100, Martin Burnicki wrote:
> 
> In the ntpd source code I see a number of places like this:
> 
> #ifdef STA_NANO
>   clock_offset = ntv.offset / 1e9;
> #else /* STA_NANO */
>   clock_offset = ntv.offset / 1e6;
> #endif /* STA_NANO */
> 
> So this is interpreted here as nanoseconds or microseconds depending
> on
> whether STA_NANO is defined *at compile time*.
> 
> IMO this is not an optimal solution. I've seen cases under Linux
> where
> the timex.h file shipped with the kernel source
> (/usr/src/linux/include/linux/timex.h) and used to compile the kernel
> defined STA_NANO, while an older copy of timex.h shipped with glibc
> (/usr/include/linux/timex.h) did *not* include it. Since the latter
> is
> used by default when compiling a user space application like ntpd
> this
> resulted in an ntpd binary which assumed the adjtimex() returns
> microseconds, while in fact the kernel deals with nanoseconds.
> 
> So a better solution would be if the the kernel sets the STA_NANO bit
> if
> it provides nanoseconds, and applications check at runtime if the bit
> is
> set in the status returned by adjtimex().
> 

I did some experimenting with this on Fedora 25, Linux kernel 4.8.15-
300.fc25.x86_64.  I found that adjtimex sets STA_NANO and returns
nanoseconds only when NTP has been running for a while.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Wed, 2017-01-04 at 13:57 +0100, Preben Nørager wrote:
> We don't know how future generations will see the "problem", if leap
> seconds are abolished. As generations today see it, the "problem" is
> that without leap seconds the sun is getting ahead or behind the
> official international timescale, so that the noon transit not
> normally will occur around 12 midday. I think leap seaconds are to be
> abolished, as soon as possible, and that we should leave to future
> generations the only logical way to deal with that "problem". The
> only logical way is to continue praksis, and let each sovereign
> nation individually decide, how many minutes and/or hours its
> official time is ahead or behind the international timescale.
> Currently the time in Denmark is 1 hour ahead of international time
> (UTC), but I don't see any problem if future generations in Denmark
> should decide, that Denmark instead of 1 hour, is 1 hour and 30
> minutes, or 2 hours ahead. Great Britain, and other nations, should
> get used to a constant difference between international time, and
> national time, but I dont see why they should not live comfortably
> with that, like everybody else.
> 
> Preben

Preben,

You and I disagree on this issue.  For me this is fundamentally a moral
concern.  I believe that each generation should handle its problems as
best it can, leaving to the next generation only unforeseen problems.  

The tension between the need of civil society and science for a time
scale that simultaneously matches the Earth and atomic time is met by
the Gregorian Calendar and UTC.

The reform that brought the calendar back into synchronization with the
seasons was proposed several times but got no traction until 1582. 
That generation bit the bullet and suffered the dislocation of dropping
10 days from the calendar rather than continue to defer the problem. 
It took centuries for everyone to get on-board, but today almost
everyone uses the Gregorian calendar.

UTC, as it is defined today with leap seconds, is a similar challenge. 
We can fix the buggy software or we can cause a problem for the next
generation.  I feel that it would be immoral to remove an adequate
solution just because we are too lazy to write code correctly.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Tue, 2017-01-03 at 14:53 -0500, Michael Rothwell wrote:
> 
> 
> On Tue, Jan 3, 2017 at 2:18 PM, John Sauter <John_Sauter@systemeyesco
> mputerstore.com> wrote:
> > On Tue, 2017-01-03 at 13:28 -0500, Michael Rothwell wrote:
> > >
> > > This was probably covered elsewhere, and I apologize if I missed
> > it,
> > > but I have a question:
> > > Why are you in such favor of leap seconds?
> > >  
> > > -- 
> > > Michael Rothwell
> > > mich...@rothwell.us
> > > (828) 649-ROTH
> > 
> > I regard leap seconds as a reasonable compromise between the needs
> > of
> > civil time and of science.  Civil time needs a clock that tracks
> > the
> > days and the seasons.  Science requires a clock that measures time
> > in
> > precise intervals.  UTC provides both, using leap seconds to keep
> > atomic time synchronized with the rotation of the Earth.
> > 
> > Some people who are inconvenienced by leap seconds are pushing for
> > their removal.  The effect of removing leap seconds will be to
> > burden
> > future users of civil time, who will see their clock no longer
> > tracking
> > the rotation of the Earth, and have to do something about it.  I
> > feel
> > it is unethical to burden a future generation for our convenience,
> > since that future generation has no voice in today's decisions.
> > 
> > The inconveniences of leap seconds can be overcome by fixing the
> > software that doesn't handle them correctly.  Doing that is a big
> > job,
> > bigger than fixing the software that didn't handle the year 2000
> > correctly.  We don't need to fix all the software today, we can
> > chip
> > away at it, and encourage newly written software to handle time
> > correctly.
> 
> 
> I think you are hopelessly naive. :)
> 
> How many years (or centuries) would it take for the lack of leap
> seconds to become a problem? 
> 
>  
> >     John Sauter (john_sau...@systemeyescomputerstore.com)
> > 
> > --
> > PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E
> > 
> 
> 
> 
> -- 
> Michael Rothwell
> mich...@rothwell.us
> (828) 649-ROTH

It doesn't matter how many years or centuries it takes for the lack of
leap seconds to become a problem.  It only matters that it does,
eventually, become a problem only for people who are now unborn.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

On Tue, 2017-01-03 at 13:28 -0500, Michael Rothwell wrote:
> 
> This was probably covered elsewhere, and I apologize if I missed it,
> but I have a question:
> Why are you in such favor of leap seconds?
>  
> -- 
> Michael Rothwell
> mich...@rothwell.us
> (828) 649-ROTH

I regard leap seconds as a reasonable compromise between the needs of
civil time and of science.  Civil time needs a clock that tracks the
days and the seasons.  Science requires a clock that measures time in
precise intervals.  UTC provides both, using leap seconds to keep
atomic time synchronized with the rotation of the Earth.

Some people who are inconvenienced by leap seconds are pushing for
their removal.  The effect of removing leap seconds will be to burden
future users of civil time, who will see their clock no longer tracking
the rotation of the Earth, and have to do something about it.  I feel
it is unethical to burden a future generation for our convenience,
since that future generation has no voice in today's decisions.

The inconveniences of leap seconds can be overcome by fixing the
software that doesn't handle them correctly.  Doing that is a big job,
bigger than fixing the software that didn't handle the year 2000
correctly.  We don't need to fix all the software today, we can chip
away at it, and encourage newly written software to handle time
correctly.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[John Sauter]

I have updated my paper on avoiding the use of POSIX time_t for telling
time, adding some example code and some recommendations for improving
the Linux kernel.  The updated paper is at the same URL:

<https://commons.wikimedia.org/wiki/File:Avoid_Using_POSIX_time_t_for_T
elling_Time.pdf>

I intend to update it again when the IERS issues their next Bulletin C.

I would appreciate comments on it from the readers of the leap seconds
discussion list.  I would also appreciate its widespread distribution
among application programmers, since its use will reduce the frequency
of bugs related to leap seconds, and thus decrease the pressure to
eliminate leap seconds in 2023.

If anyone has difficulty extracting the software from the PDF using
okular, e-mail me and I will provide the files separately.
    John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

On Wed, 2016-12-28 at 14:01 +0800, Sanjeev Gupta wrote:
> 
> On Tue, Dec 27, 2016 at 11:36 PM, John Sauter <John_Sauter@systemeyes
> computerstore.com> wrote:
> > > Also note that many large radar systems have built-in simulators,
> > > used 
> > > for system integration during development and for training
> > > thereafter.  
> > > Such simulators need to be able to work using system time that is
> > > not 
> > > the present, say to rerun recorded observations or to simulate
> > > future 
> > > or past scenarios.  In both cases, the GPS receiver does not know
> > > the 
> > > correct leap second offset to use.  The usual solution is an 
> > > application-provided table all past leap seconds, plus the next
> > leap 
> > > second (if known).  The table is updated manually.
> > 
> > That sounds like a fine solution.  It would be nice if the table
> > were
> > maintained by the group of people who needed it, so that everyone
> > wouldn't have to update his own table.
> > 
> 
> If I have understood you correctly, this is publicly available, based
> on the IERS Bulletin C:
> 
> https://www.ietf.org/timezones/data/leap-seconds.list
> 
> -- 
> Sanjeev Gupta
> +65 98551208     http://www.linkedin.com/in/ghane

You have understood me correctly; I was assuming that the radar systems
 did not use the NTP format for their leap seconds file.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

On Mon, 2016-12-26 at 11:57 -0500, Joseph Gwinn wrote:
> 
> > John Sauter (john_sau...@systemeyescomputerstore.com) responded:
> > 
> > Thank you for your comments, Joe.
> > 
> > I agree that POSIX defines its own time scale for time_t, but that
> > is
> > not how it is being used.  Everyone sets their computer’s clock to
> > UTC,
> > no matter what the standard says, and no matter how many seconds
> > have
> > passed since 1970-01-01T00:00:00Z.
> 
> Many but not all people set their clocks to UTC.  See my item 3
> above.
> 
> Probably the majority of computer users never heard of UTC.

Sorry, that was an over-simplification on my part.  I should have said
"almost everyone" since you described a case in which the time was
deliberately set to a non-UTC time scale.  In addition, I should have
said that almost everyone sets their clock to a time "based on" UTC,
specifically their local time.  They also set their computer's time
zone variable to their local time zone.

>  
> > I have long heard that a design goal of POSIX was that it be
> > functional
> > in an isolated system, but I am not sure what that really means.  A
> > totally isolated computer might as well be switched off, since
> > nothing
> > communicates with it. 
> 
> Yes, that is a major goal.  Isolated means just that.  Think of a 
> computer system at the bottom of a mine, or in a submarine.  Most
> such 
> computers do not need to know UTC - local time is adequate.
>  
> 
> >  That isn’t a reasonable meaning for “isolated”
> > in this context, so what, really, is an isolated computer?  Perhaps
> > it
> > means a computer with a very limited set of sensors for input, and
> > a
> > very limited set of effectors for output.  If that is the case,
> > surely
> > one of the sensors can be a GPS receiver so the computer can keep
> > its
> > clock accurate.  If not, then perhaps the computer’s clock doesn’t
> > need
> > to be accurate, and therefore has no need to update its leap second
> > table.  
> 
> In many systems, the GPS signal is simply not available, so a GPS 
> receiver would be useless.  
> 
> And, as you mention, many sensors don't need to know UTC (or TAI or 
> anything else) - local system time is adequate.  Time since last 
> boot-up is very common in such applications - see section 4 above.
> 
> 
> >   However, if a computer is going to track the Sun across the
> > sky, it will need access to astronomical data, because the position
> > of
> > the Sun in the sky cannot be predicted to within a second five
> > years in
> > the future.  Realistically, an “isolated” computer needs whatever
> > inputs are required for it to do its job, and that might include
> > the
> > time.
> 
> Systems that need to track the Sun this will provide GPS or the
> like, 
> to be able to perform their mission.  It does not follow that all 
> systems have any need of astronomical data.  Usually, self-
> consistency 
> and stability are the big requirements.
> 
>  
> > The TAI time scale was synchronized to UTC when it was created in
> > 1958,
> > and has since not counted leap seconds.  Similarly, the Navstar GPS
> > system was synchronized to UTC in 1980 and has since not counted
> > leap
> > seconds, making GPS time a fixed offset from TAI.  GPS receivers,
> > like
> > your radar systems, convert to UTC when displaying time.  The
> > Navstar
> > GPS satellites are informed of an upcoming leap second, and pass
> > that
> > down to the receivers, so they can display UTC correctly. I
> > suppose 
> > your radar systems do the same.  
> 
> Depends on application.  Not all will display UTC. In many radar 
> systems, the GPS receiver is instead configured to emit GPS System 
> Time, not UTC, to avoid leap seconds.  See section 3 above.

Perhaps I misunderstood.  I thought you said that the internal time was
converted to UTC for display.  Perhaps some, but not all, radars do
that?

> Also note that many large radar systems have built-in simulators,
> used 
> for system integration during development and for training
> thereafter.  
> Such simulators need to be able to work using system time that is
> not 
> the present, say to rerun recorded observations or to simulate
> future 
> or past scenarios.  In both cases, the GPS receiver does not know
> the 
> correct leap second offset to use.  The usual solution is an 
> application-provided table all past leap seconds, plus the next leap 
> second (if known).  The table is updated manually.

That sounds like a fine solution.  It would b

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

[John Sauter]

On Mon, 2016-12-26 at 19:55 -0700, Warner Losh wrote:

> 
> I think it has been too late since the 80's (so we're 30 years too
> late to fix this problem). 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. Without changing the broken APIs, introducing new, non-broken
> ones won't help: people will still be using the bogus APIs. Since
> it's
> impossible to fix all this code, POSIX has, de-facto, defined what
> time is (even though that definition flies in the face of the current
> definition). UTC may well be superior to POSIX's notion, but that's
> entirely besides the point. It's not better enough that people will
> be
> motivated to fix all this code, especially since public education
> about proper (meaning UTC-ly correct) is so lacking. While it might
> result in a better world if POSIX were able to change, it isn't. It
> can't. Efforts in this area are doomed to fail, alas. However, since
> it is a matter of pride for both sides, we'll sadly continue in the
> bogus state where we have the side that has the overwhelming weight
> of
> implementation thinking they are right (or at least not wrong), and
> the side that knows the math and knows their way is better because it
> lacks the flaws of the other guys (but without the mind-share in the
> right places to be implemented correctly universally).
> 
> That's what I mean that POSIX has de-facto changed UTC. It's not a
> value judgement on UTC, per se. The marketplace has effectively voted
> with its feet, and change would be too expensive. Sadly, change on
> either side is seen as too expensive, so we'll likely continue with
> the impedance mismatch until it causes enough major chaos to force a
> change.
> 
> Warner

I do not share your pessimism.  Computer programming is in its infancy:
programmable computers are less than 100 years old.  If UTC will
actually last 1000 years, as I think it will, there is plenty of time
to correct 30 years of badly-written code.  Yes, there are millions of
lines to correct, but we managed the Y2K problem without major
disruption.

We can fix the code that is easy to fix, and write new code correctly. 
Eventually, the amount of bad code will decrease to the point that
instances of bad code will be embarrassing to their maintainers.  That
will be the tipping point after which the amount of bad code will
decline quickly.  It might take take a century or so, but it can be
done.  The increase in the frequency of leap seconds will help: in 1000
years there will be a leap second at the end of each month.

You speak of public education, mind share and the overwhelming weight
of implementation.  Those factors can be overcome.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

On Tue, 2016-12-27 at 01:28 +, Tony Finch wrote:
> Brooks Harris <bro...@edlmax.com> wrote:
> > 
> > The time_t 1970 epoch is fixed with respect to internal POSIX
> > calculations,
> > but it "slips" a second with respect to UTC with each (positive)
> > Leap Second
> > introduction because "23:59:60" goes missing.
> 
> "Slip" makes it sound like a retrospective change in the relationship
> between UTC and time_t, with the scales sliding against each other,
> but it
> doesn't change - there's a fixed relationship between UTC second
> labels
> and time_t second labels, which remains the same however many leap
> seconds
> there are. In fact time_t is defined in terms of that relationship,
> and
> "seconds since the epoch" is just a simplified gloss.
> 
> Tony.

By not specifying the exact time of the Epoch, the standard causes
"seconds since the Epoch" to mean just an encoding of UTC into an
integer, rather than also the number of seconds since a fixed time.  I
did an experiment recently in which I used the time function to ask the
kernel for the "seconds since the Epoch", then subtracted that many
seconds from the current time, using the Tony Finch table of leap
seconds between 1958 and 1972.  The result I got was 1970-01-
01T00:00:28Z.  Next year it will be 1970-01-01T00:00:29Z.

"Seconds since the Epoch" is worse than a simplified gloss.  It is
misleading, though not quite false, since the standard doesn't say what
the Epoch is.  The name implies incorrectly that it is a count of
seconds since some vaguely-defined but fixed time.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

On Tue, 2016-12-27 at 12:34 +, Robert Jones wrote:
> 
> As a minor note, the SQL standard requires timestamps to be in the 
> format (simplified to ignore timezones, variable precisions, etc) 
> mmddhhmmss.ss where it is currently for the implementor to 
> decide how to do the date and time manipulations.
> 
> SQL 2008 standard
> 
> 4.6.2 Datetimes (extracts)
> 
> — TIMESTAMP — contains the s YEAR, MONTH,
> DAY, 
> HOUR, MINUTE, and
> SECOND
> 
> A datetime value, of data type TIME WITHOUT TIME ZONE or TIMESTAMP 
> WITHOUT TIME ZONE,
> may represent a local time, whereas a datetime value of data type
> TIME 
> WITH TIME ZONE or TIMESTAMP
> WITH TIME ZONE represents UTC.
> 
> in the SQL 2008 standard see NOTE 101 — Datetime data types will
> allow 
> dates in the Gregorian format to be stored in the date range
> 0001–01–01 
> CE through
> –12–31 CE. The range for SECOND allows for as many as two “leap 
> seconds”. Interval arithmetic that involves leap seconds
> or discontinuities in calendars will produce implementation-defined
> results.
> 
> Robert

"Produce implementation-defined results" is a cop-out, considering that
there is a leap second every few years.  If we can fix the software so
that leap seconds are routinely handled correctly, the standard can
remove that last sentence.
John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

On Mon, 2016-12-26 at 08:43 -0500, Brooks Harris wrote:
...
> 
> I wonder if the computer industry might not have long since adopted a
> more accurate UTC-based local time timekeeping system if a
> specification for one actually existed. But it doesn't, and that, it
> seems to me, should be the objective; to develop a suite of
> specifications that consolidates the UTC specs, codifies the meaning
> and representation of local time, and specifies reverse compatible
> mapping to existing systems. This needs to be accompanied by format
> and protocol specifications together with reference implementations.
> Without a plan its hard to imagine how convergence on a uniform
> timekeeping system comes about.
> 
> The existing systems are not going to be replaced; they all need to
> be supported while defining a more uniform and UTC-accurate set of
> procedures that may be used in parallel with, beside, on top of, or
> in conjunction with, existing systems. If we keep arguing about what
> UTC and POSIX are or are not because we don't like one or the other I
> don't see how we get very far.
> 
> -Brooks

I'm not a great fan of standards, myself.  I once quipped that "The
purpose of standards is to make the future repeat the mistakes of the
past, rather than invent their own."  However, if you think it is
important to have standards for local timekeeping based on UTC, then I
urge you to begin work on them.  UTC itself already has a formal
document describing it: TF460-6 at <https://www.itu.int/dms_pubrec/itu-
r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf>.  The representation of
local time has a standard: ISO 8601, though people pretty much use RFC
3339 instead.  POSIX has time_t (bletch) and the tm structure.

Standards for local time based on UTC should reflect what people are
actually doing.  If what people are doing is wrong, then I feel we
should correct current practices first, and then write the standard.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

On Sun, 2016-12-25 at 18:53 -0800, Steve Allen wrote:
> On Sun 2016-12-25T19:37:31 -0700, Warner Losh hath writ:
> > I think that POSIX has de-facto redefined UTC, and it's time that
> > the
> > UTC standard catch up to this quiet revolution.
> 
> POSIX has defined that the time scale upon which time_t is based has
> the characteristics of every time scale other than UTC.  That is,
> there are 86400 "seconds" in a "day".  That will stay true until
> POSIX is in use for civil time somewhere else than on earth.
> 

The fact that POSIX defines a time scale different from UTC is a
problem for POSIX, not for UTC.  People use UTC in their computers, and
don't care what the POSIX standard says.

> It is less clear is what kind of "seconds" and "days" POSIX wants,
> largely because the current UTC did not make the distinction clear.
> Thus for POSIX the "seconds" being ticked and "days" of the calendar
> must be related by the factor 86400, which is not the case in UTC as
> defined by CCIR/ITU-R.
> 
> It is clear that devices implementing POSIX must rely on the time
> signals in radio broadcasts.  Too much infrastructure already exists
> which relies on those broadcasts.
> 
> It is clear that the agencies implementing the radio broadcasts will
> never return to rubber seconds, and will not approve of smears.
> 
> So the only change that can happen to the nature of radio broadcasts
> is to start counting atomic days of atomic seconds.
> 

No, that isn't the only change that can happen.  Another possibility is
that the radio broadcasts do not change and people ignore the POSIX
standard, keeping time according to UTC.  As long as you don't use
POSIX time_t, that is doable.

> It is not clear that the name UTC is sacrosanct to POSIX.
> The machines simply do not care what humans call that time scale.
> 
> It is clear that some humans do care about the name UTC.  I have not
> seen any of the agencies make arguments about why the radio broadcast
> time scale cannot change its name.  It has done so in the past, and
> the world did not care.
> 
> --
> 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
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

On Sun, 2016-12-25 at 19:37 -0700, Warner Losh wrote:
> > I agree that POSIX defines its own time scale for time_t, but that
> > is
> > not how it is being used.  Everyone sets their computer’s clock to
> > UTC,
> > no matter what the standard says, and no matter how many seconds
> > have
> > passed since 1970-01-01T00:00:00Z.
> 
> I think that POSIX has de-facto redefined UTC, and it's time that the
> UTC standard catch up to this quiet revolution. Standards are
> important, but UTC isn't sacrosanct, nor is DUT1 < 0.9s. When they
> took a pass at defining a model that reflected reality, the
> pervasiveness of time_t has effectively redefined UTC. It's too late
> to redefine the standard, or define a new standard to use: that ship
> sailed sometime in the 80's.
> 
> Warner

I disagree completely.  I consider UTC superior to POSIX.  It is POSIX
that must change to conform to UTC, not UTC that must change to conform
to POSIX.  While it is too late to redefine time_t, it is not too late
to stop using it in favor of something better, and that something
better is the tm structure.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

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

[John Sauter]

Joseph Gwinn (joegw...@comcast.net) wrote:

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

John Sauter (john_sau...@systemeyescomputerstore.com) responded:

Thank you for your comments, Joe.

I agree that POSIX defines its own time scale for time_t, but that is
not how it is being used.  Everyone sets their computer’s clock to UTC,
no matter what the standard says, and no matter how many seconds have
passed since 1970-01-01T00:00:00Z.

I have long heard that a design goal of POSIX was that it be functional
in an isolated system, but I am not sure what that really means.  A
totally isolated computer might as well be switched off, since nothing
communicates with it.  That isn’t a reasonable meaning for “isolated”
in this context, so what, really, is an isolated computer?  Perhaps it
means a computer with a very limited set of sensors for input, and a
very limited set of effectors for output.  If that is the case, surely
one of the sensors can be a GPS receiver so the computer can keep its
clock accurate.  If not, then perhaps the computer’s clock doesn’t need
to be accurate, and therefore has no need to update its leap second
table.  However, if a computer is going to track the Sun across the
sky, it will need access to astronomical data, because the position of
the Sun in the sky cannot be predicted to within a second five years in
the future.  Realistically, an “isolated” computer needs whatever
inputs are required for it to do its job, and that might include the
time.

The TAI time scale was synchronized to UTC when it was created in 1958,
and has since not counted leap seconds.  Similarly, the Navstar GPS
system was synchronized to UTC in 1980 and has since not counted leap
seconds, making GPS time a fixed offset from TAI.  GPS receivers, like
your radar systems, convert to UTC when displaying time.  The Navstar
GPS satellites are informed of an upcoming leap second, and pass that
down to the receivers, so they can display UTC correctly.  I suppose
your radar systems do the same.  Your description of a typical radar
system in part 4 is even simpler: just a count of seconds since its
Epoch, converted to UTC for display.  I am not clear from 

Re: [LEAPSECS] Leap second smearing test results

[John Sauter]

Warner Losh wrote:

These are the reasons I hate leap seconds: they are of dubious value
and cause all kinds of havoc because nobody expects them to work, and
the programming standards are written as if they don't exist.

John Sauter wrote:

Dubious value: leap seconds cause UTC, and thus civil time, to track
the sun.  I don't regard that value as dubious.

Warner:

So do time zones. People that care about DUT1 can get it over the
internet these days. UTC isn't precise enough for them anyway. There
are some folks with legacy gear that can't easily be changed (mostly
telescopes), so I feel for them since often they have hired someone to
build the telescope, maybe years ago, and changing now would be quite
costly. The error that leap seconds correct is ~21 parts per billion
(today). Leap days correct an error of ~1.1%, so the comparison isn't
too apt. The value is mostly theoretical, but they won't be around
forever since the quadratic acceleration of leap seconds will mean in
the future we'll need to come up with a better way to cope. Leap years
are still good for maybe 10k years before we have to adjust. Leap
seconds are unlikely to be viable in a thousand years.

John:

The idea behind leap seconds is to deal with a long-term problem by
making corrections so small that most people don’t care, or at most
laugh, when told about them.  For almost everyone, leap seconds are
inconsequential, and that’s a good thing.  The current definition will
do for about 1000 years, until the skew between the UTC and UT1 rates
gets large enough that we need a leap second before the end of the
month to keep abs(UTC – UT1) below 0.9.

=

John:

Cause all kinds of havoc because nobody expects them to work:
expectations can be changed by fixing the applications so that they do
work.  Fixing applications takes time, and expectations will lag behind
the fixes, but given time the problem is not unsolvable.

Warner:

The problem is almost unsolvable. Changing expectations is impossible.
Leap seconds are too flakey to teach once in programming class. They
are too unpredictable to provision long enough in advance for the life
of a system (unlike leap days). They are just a second, so nobody
allocates resources to fix issues: they just live with the results.
There's been no sign that things have improved in the last 15 years
since I started working in the field, so while I admire your optimism,
I'm too jaded to share it. Until you can address the systemic bias
against leap seconds in the world, they will continue to be the bastard
child of time keeping, with only the most pedantic getting them right.

John:

Perhaps I am, as you say, excessively optimistic.  Maybe I am tilting
at a windmill, but I would rather light a candle than just scream into
the darkness.  I am attempting to address the systemic bias against
leap seconds in the world by making it easier to handle leap seconds
correctly than ignore them.  See my “Avoid Using POSIX time_t for
Telling Time”.

=

John:

The programming standards are written as if they don't exist: no longer
completely true--POSIX, for example, implicitly acknowledges their
existence before requiring applications to pretend they don't
exist.  Standards follow practice: when applications routinely handle
leap seconds correctly, their techniques will be incorporated into
standards.

Warner:

POSIX time_t says they don't exist. Therefore, they don't exist. There
is some lip-service to leap seconds in struct tm, but until time_t can
cope, the standard is hopelessly broken. The number of programs that
use time_t is huge, and almost none of them get leap seconds right (the
one that do have to use extra data not covered by the standard to get
it right). The POSIX committee is actively hostile to changing this
state of affairs and has made the engineering decision that it's just a
second, and people don't get it right, so they simplify the problem by
assuming they don't exists, or if they do they are handled outside of
the standard somehow because there's no way to unambiguously encode
them in the standard for time_t.

So, you can say those things, but I'm not at all optimistic that things
will change.

Of course, that won't change the fact that they are part of the
standard, and something more sensible than throw a 1 second error (or
worse) needs to happen. Especially the "or worse" part given the number
of bugs related to leap seconds in the past that were more than just a
small time keeping error. So I get that computers should implement them
right, but until they are "right by default" we'll need skewing to
paper over the worst of it.

John:

We are not slaves to standards—they exist to serve our needs.  If we
need to keep track of time accurately, and find a way to do so, the
standards will catch up.  POSIX time_t is fatally flawed when used for
the purpose of telling time.  The standard is so weasel-worded as to be
practically meaningless. 

I do not advocate changing the 

Re: [LEAPSECS] Leap second smearing test results

[John Sauter]

On Thu, 2016-12-22 at 21:50 -0700, Warner Losh wrote:
> 
> These are the reasons I hate leap seconds: they are of dubious value
> and cause all kinds of havoc because nobody expects them to work, and
> the programming standards are written as if they don't exist.
> 
> Warner

Dubious value: leap seconds cause UTC, and thus civil time, to track
the sun.  I don't regard that value as dubious.

Cause all kinds of havoc because nobody expects them to work:
expectations can be changed by fixing the applications so that they do
work.  Fixing applications takes time, and expectations will lag behind
the fixes, but given time the problem is not unsolvable.

The programming standards are written as if they don't exist: no longer
completely true--POSIX, for example, implicitly acknowledges their
existence before requiring applications to pretend they don't exist. 
Standards follow practice: when applications routinely handle leap
seconds correctly, their techniques will be incorporated into
standards.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] alternative to smearing

[John Sauter]

An alternative to smearing is to persuade applications to deal with UTC
and the Gregorian calendar as it is, with its variable-length months
and minutes.  In support of that alternative, I am making available
some subroutines which applications can use to deal with time.  This is
an update to the preliminary code that I previously posted to the leap
seconds mailing list.  The code can be extracted from the PDF file at
this URL:

<https://commons.wikimedia.org/wiki/File:Avoid_Using_POSIX_time_t_for_T
elling_Time.pdf>

The subroutines use a table of changes in Delta T to track leap
seconds.  Most of the table in these subroutines was computed based on
the latest research into historical values of Delta T from F. R.
Stephenson, L. V. Morrison and C. Y. Hohenkerk in this paper:

<http://rspa.royalsocietypublishing.org/content/472/2196/20160404>

The computations are described in an update of my earlier paper on this
subject, at this URL:

<https://commons.wikimedia.org/wiki/File:Extending_Coordinated_Universa
l_Time_to_Dates_Before_1972.pdf>

I would be glad for any comments anyone might have on my work.
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[John Sauter]

On Sun, 2016-10-09 at 15:12 -0400, Brooks Harris wrote:

> > I took the lack of mention of leap seconds to mean that leap
> > seconds
> > ere not a problem.  The output of the NISTDC units is an
> > astonishingly
> >  accurate 1 pulse per second.  That feeds NTP, which handles leap
> > seconds using a table.  As long as the table is kept up to date,
> > everyone agrees on each second's name.
>  Except the one to be called -MM-DDT23:59:60.
> 
> There are 86401 pegs in the (positive) Leap Second UTC day. There are
> 86400 holes in traditional timescales in which to put them. Something
> has to to go missing - the mapping is indeterminate. Common practice
> of introducing Leap Seconds on local timescales simultaneous with its
> introduction at UTC places these indeterminate labels at different
> time-of-day points along each local timescale. Non standardized and
> politically driven Daylight Savings rules further complicates when
> these indeterminate moments occur. Meantime there is no standardized
> way to keep the Leap Second tables automatically updated to begin
> with.
> 
> -Brooks

Not being a traditionalist myself, I don't feel that there is anything
wrong with 23:59:60 as a label for a particular second.  Thus, I don't
feel the need to map the 86,401 seconds of the last day of 2016 into
86,400 "holes", and therefore I do not suffer any indeterminacy.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[John Sauter]

On Sat, 2016-10-08 at 15:58 -0600, Warner Losh wrote:
> On Sat, Oct 8, 2016 at 2:43 PM, Steve Allen <s...@ucolick.org> wrote:
> > 
> > On Fri 2016-10-07T11:48:25 -0600, Warner Losh hath writ:
> > > 
> > > Accurate, Traceable, and Verifiable Time Synchronization for
> > > World
> > > Financial Markets
> > > 
> > > http://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf
> > > 
> > > Market synchronization requirements today are 1s. However, in
> > > August
> > > 2017 they become 50ms. Good thing normal market hours on the US
> > > exchanges avoids the leap second...
> > 
> > Notably missing in this document is any mention of the term leap
> > second.
> > More surprising is no mention of TAI, despite the numerous
> > references
> > to the use of IEEE 1588 PTP for the timing systems.
> > It's like getting a tour map that describes the route but fails to
> > mention that along the way there's a bridge out.
> 
> Yes, it's like all the other systems I worked on that required
> external UTC to be correct at all times, even when the GPS receiver
> doesn't yet know the current number of leap seconds. I'll have to
> pass
> the leap second comment along to the author...
> 
> Warner

I took the lack of mention of leap seconds to mean that leap seconds
ere not a problem.  The output of the NISTDC units is an astonishingly
 accurate 1 pulse per second.  That feeds NTP, which handles leap
seconds using a table.  As long as the table is kept up to date,
everyone agrees on each second's name.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bloomberg announced its smear

[John Sauter]

On Sun, 2016-09-25 at 19:08 -0700, Christopher Hoover wrote:
> Steve,
> 
> Google smears, too[1].  Smearing is a good engineering solution for
> datacenter-scale computing and planet-wide databases [2].
> 
> Disclosure: I"m at Google.
> 
> -christopher.
> 73 de AI6KG
> 
> [1] https://googleblog.blogspot.com/2011/09/time-technology-and-leapi
> ng-seconds.html
> [2] http://research.google.com/archive/spanner.html

Google says in the blog that they did the smearing to avoid the need to
review all of their time-sensitive code.  Those of us who love leap
seconds need to spend the next 10 years doing that code review, and the
necessary testing and bug fixing to get everything working in the
presence of leap seconds.

We also need to fix operating systems and subroutine libraries so that
when application programmers, who don't care about leap seconds, write
their code it will "just work".

If we do that, then the next time the issue is considered there will be
much less motivation to abandon leap seconds.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] a less intrusive procedure

[John Sauter]

On Thu, 2016-07-21 at 10:27 -0700, Tom Van Baak wrote:
> Time to mention this again...
> 
> If we adopted the LSEM (Leap Second Every Month) model then none of
> this would be a problem. The idea is not to decide *if* there will be
> leap second, but to force every month to have a leap second. The IERS
> decision is then what the *sign* of the leap second should be this
> month.
> 
> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with
> UTC, not so much by rare steps but by dithering. There would be no
> change to UTC or timing infrastructure because the definition of UTC
> already allows for positive or negative leap seconds in any given
> month.
> 
> Every UTC-aware device would 1) know how to reliably insert or delete
> a leap second, because bugs would be found by developers within a
> month or two, not by end-users years or decades in the future, and 2)
> every UTC-aware device would have an often tested direct or indirect
> path to IERS to know what the sign of the leap second will be for the
> current month.
> 
> The leap second would then become a normal part of UTC, a regular
> monthly event, instead of a rare, newsworthy exception. None of the
> weird bugs we continue to see year after year in leap second handling
> by NTP and OS's and GPS receiver firmware would occur.
> 
> Historical leap second tables would consist of little more than 12
> bits per year.
> 
> Moreover, in the next decade or two or three, if we slide into an era
> where average earth rotation slows from 86400.1 to 86400.0 to 86399.9
> seconds a day, there will be zero impact if LSEM is already in place.
> 
> /tvb

I suggest a less intrusive procedure which would have some of the same
benefits.

Every serious project includes a test procedure to verify that the
product is working.  That test procedure involves running the product
within a test harness which feeds it inputs and records its outputs.
 Within that test harness, pretend that every minute ends with either a
positive or negative leap second.  Bugs in the handling of leap seconds
will thus be found very quickly.

This procedure can be implemented by a product developer without
getting co-operation from the IERS or any other external entity.
 However, it does not address the problem of timely access to the IERS.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E


signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] request for "Earth's Variable Rotation from 750BC to present"

[John Sauter]

On Tue, 2016-05-10 at 05:21 -0400, lmorr49...@aol.com wrote:
> Dear John,
>  
> We have been revising the work we displayed at the 2015 IAU meeting,
> and are in the final stages of preparing it for publication, probably
> in the Phil. Trans. R. S. (Lond.). When this has been accepted for
> publication, I will send you a copy, which will contain an internet
> link to tables of our results. Please write to me again in a few
> months time, when I will know the progress of the paper.
>  
> Leslie Morrison

Thank you, Dr. Morrison.  I will do that.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds Schedule Prior to 1972

[John Sauter]

If you received the above message directly the URL is correct, but in
the archives it includes the period at the end of the sentence,
rendering it invalid.  For the benefit of those who see only the
archive, here is the URL again, this time without a trailing period:

https://www.systemeyescomputerstore.com/proleptic_UTC.pdf

    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] Leap Seconds Schedule Prior to 1972

[John Sauter]

I have updated my proposal for a schedule of leap seconds prior to 1972
based on the Earth's rotation rate, which was deduced from ancient
observations of the Sun and Moon.  The revised paper is available on my
web site, at 

https://www.systemeyescomputerstore.com/proleptic_UTC.pdf.


Since the last revision I have corrected some minor errors in the
tables and included the complete list of leap seconds since -1000 as an
embedded file.

I would be grateful for any additional criticism, particularly any
suggestions for improving the paper.  It is my goal to publish this
paper on arXiv.org, perhaps in the astro-ph section.
John Sauter (John_Sauter at systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Wed, 2016-04-27 at 13:57 -0700, Steve Allen wrote:
> 
> ISO 8601 specifies the Gregorian calendar, and 500 years ago there
> could be nobody using the Gregorian calendar.
> 
> 500 years ago there were only a handful of clocks that had a minute
> hand, and they were not accurate to a minute a day.
> 
> Whether or not this scheme uses ISO 8601, please be sure that the
> accompanying documentation explains that it cannot correspond to
> contemporary records of 500 years ago.
> 
> --
> Steve Allen <s...@ucolick.org>   WGS-84
> (GPS)
> UCO/Lick Observatory--ISB   Natural Sciences II, Room
> 165   Lat  +36.99855
> 1156 High StreetVoice: +1 831 459 3046  Lng
> -122.06015
> Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250
> m

The accompanying documentation explains at great length that this time
scale does not correspond to civil time.  It is intended for use by
historians writing about past events for a non-specialist audience.  It
is similar proleptic Gregorian, which is used by Mayan scholars who
want to describe a date using terminology that is familiar to the
general reader.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Wed, 2016-04-27 at 11:41 -0400, Brooks Harris wrote:
> Hi,
> 
> One quick comment - 
> 
> Couldn't we computer folks start to use the very sensible ISO 8601
> date format? For example
> 
> EXPIRATION_DATE=2457751 # 2016 12 28
> 
> -Brooks
> 

I used Day Month Year with the month as a three-letter abbreviation
because the leap-seconds.list file from IETF (and I think others) does
it this way.  That is also my excuse for using "#" as the comment
marker.
    John Sauter (john_sau...@systemeyescomputerstore.com)

PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

I have written the sample code that Hal suggested, along with its data
file.  I attach both to this e-mail message, and they are included as
embedded files with the updated paper, which is at the usual URL:

https://www.systemeyescomputerstore.com/proleptic_UTC.pdf

The data file is preliminary, going back only to just before 1700.
 That is enough to be useful, but it does not cover the whole date
range.  The data also appears in the paper as a new table in section 8:
Extraordinary Days by Julian Day Number.  Completing the data file will
add about 25,000 lines to it, which might make the paper excessively
long if it were included as a table.  Would a shorter table be
acceptable, even after the data file is completed?

Also, any other comments on the paper would be appreciated.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E

#
# Table of Extraordinary Days.
#
# Copyright © 2016 by John Sauter.
# Licensed under the Creative Commons Attribution-ShareAlike 4.0 International
# license.  See https://creativecommons.org/license/by-sa/4.0/.
#
# A program that wishes to measure the time between two dates needs to know
# the length of each day.  Most days are ordinary days, of 86,400 seconds,
# but a few have 86,399 or 86,401 seconds, to keep clocks synchronized with
# the rotation of the Earth.  For dates since 1972, the IERS maintains a
# list of extraordinary days.  For earlier dates, we must imagine that
# current timekeeping rules were in effect and project a list of extraordinary
# days.  See "Extending Coordinated Universal Time to Dates Before 1972."
#
# This table of extraordinary days can be read by any program that needs
# the information.  It uses a simple format with three kinds of lines:
# (1) empty lines, like this one.  Note that any line can end with a comment,
# which starts with "#".  (2) symbol=value lines, which assign a value to
# a symbol.  Certain symbols have meaning, as described below.  (3) data lines,
# formatted as two numbers: the Julian Day Number of the extraordinary day
# followed by the value of DTAI at the end of that day.  Data lines must be
# ascending: earlier dates must come before later ones.
#
# The Julian Day Number is a simple count of days, starting on
# November 24, -4713.  DTAI is the difference between International Atomic
# Time (TAI) and Coordinated Universal Time (UTC).  That value is 0
# on January 1, 1958.  Every extraordinary day changes the value of DTAI
# by +1 for days with 86,401 seconds, or -1 for days with 86,399 seconds.
# Since the data lines must be ordered, each will have a DTAI that differs
# from the preceeding and succeeding line by plus or minus 1.
#
# The symbols used in this file are as follows:
#
# START_DATE the Julian Day Number of the beginning of the data.  There may
# be extraordinary days before this date, but they are not recorded in this
# file.  An attempt to determine the time between two dates, either of which
# is before the START_DATE, should be regarded as an error.
#
# END_DATE is the Julian Day Number of the end of the data.  There may be
# extraordinary days after this date, but they are not recorded in this file.
# An attempt to determine the time between two dates, either of which is
# after the END_DATE, should be regarded as an error.
#
# EXPIRATION_DATE is the Julian Day Number after which this file should have
# been updated.  If you find yourself using this file after its EXPIRATION_DATE,
# look for an updated version of the file.  If necessary you can update it
# yourself, using IERS Circular C.
#
# CHECKSUM is 64 hex digits of the SHA256 hash of this file, excluding the
# CHECKSUM line.  The sample reading software verifies the checksum, to
# defend against accidental corruption.
#
START_DATE=2341607  # 31 Dec 1698
END_DATE=2457751# 28 Dec 2016
EXPIRATION_DATE=2457751 # 28 Dec 2016
#
# The data extends from just before 1700 through 2015.  I intend to extend
# it to earlier dates, back to -1000.
#
# JDDTAI Day Month Year
2341607 -22 # 31 Dec 1698
2341788 -23 # 30 Jun 1699
2341972 -24 # 31 Dec 1699
2344163 -23 # 31 Dec 1705
2347815 -22 # 31 Dec 1715
2355120 -21 # 31 Dec 1735
2358773 -20 # 31 Dec 1745
2361695 -19 # 31 Dec 1753
2363156 -18 # 31 Dec 1757
2366078 -17 # 31 Dec 1765
2369730 -16 # 31 Dec 1775
2376305 -17 # 31 Dec 1793
2377035 -18 # 31 Dec 1795
2378131 -19 # 31 Dec 1798
2384339 -20 # 31 Dec 1815
2386531 -21 # 31 Dec 1821
2387261 -22 # 31 Dec 1823
2387992 -23 # 31 Dec 1825
2389088 -24 # 31 Dec 1828
2390914 -25 # 31 Dec 1833
2392375 -26 # 31 Dec 1837
2395297 -25 # 31 Dec 1845
2398949 -24 # 31 Dec 1855
2400776 -25 # 31 Dec 1860
2401506 -26 # 31 Dec 1862
2402237 -27 # 31 Dec 1864
2402602 -28 # 31 Dec 1865
2403332 -29 # 31 Dec 1867
2404063 -30 # 31 Dec 1869
2404428 -31 # 31 Dec 1870
2404793 -32 # 31 Dec 1871
2405524 -33 # 31 Dec 1873
2405889 -34 # 31 Dec 1874
2406620 -35 # 31 Dec 1876
2406985 -36 #

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Mon, 2016-04-25 at 13:28 -0400, Brooks Harris wrote:
> 
>  Yup. But "proleptic UTC" as you are doing it is a useful
> engineering approximation for "civil time" purposes on Earth. It
> gets a little dicey if you ask what proleptic UTC time it was when
> the impact that created the moon occurred. Were there Leap Seconds
> before that?
> -Brooks

It is not my intent that proleptic UTC with leap seconds should ever be
considered a civil time, any more than proleptic Gregorian is
considered a civil time.  Yes, there were leap seconds before the
impact that created the moon.  Leap seconds are defined by atomic time
and the rotation rate of the Earth, so proleptic UTC with leap seconds
can, in principle, be extended back to the Earth's beginning.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Mon, 2016-04-25 at 09:40 -0400, Brooks Harris wrote:
> 
>  Hi John, 
> "understood and widely used ", yes. Standardized by an international
> standards organization, I'm not sure. Anyone know of one? There's a
> lot of things in timekeeping that are done on a "common practice" or
> "de facto standard" basis. In some cases these are not as commonly
> understood as one might wish.

I also don't know of an ISO standard for the Julian Day Number, but it
has been used by astronomers for about 400 years, and everybody seems
to agree on its definition.

> >  Doing something non-standard just to create a unique time scale
> > doesn't seem like a good enough reason.
>  It can avoid any ambiguity of interpretation if its clearly defined
> especially its alignment to 1972-01-01 
> 00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC).
> 

To be sure, but it is also possible to avoid any ambiguity of
interpretation by using a well-understood and widely-used method for
specifying days.

> Julian Day has an epoch of "12 noon 1 JAN -4712 (4713 BC)". Beyond
> that you've got to go to a "proleptic Julian Date" which is not
> exactly "standard". A negative 86400 second day number extends to the
> arbitrarily distant past depending on how many bits you decide to
> carry.
> 
> Julian Day may be OK. But somebody might ask when, exactly, did the
> Chicxulub meteor impact? I know that's beyond your scope but your
> timescale extended further as need arose.
> 

I suspect negative Julian Day Numbers isn't "a standard" because there
is little need for them.  I myself don't have any problem with negative
Julian Day Numbers.  The meteor hit at approximately Julian Day Number
-24,105,840,000.  Maybe someday we will know when it hit to the day, or
even the second.

A really good time scale would start with the Big Bang and count time
using a fundamental unit something like Planck time, about 10 to the
-43 seconds.

> > 
> > I am happy for programs which read the data file to compress it to
> > suit
> > their needs, but TAI-UTC won't fit in 11 bits if you want to go
> > back to
> > the year -1000, which has a DTAI over 25,000.
>  
> Right. Depends on how far back you want to go. 11-bits TAI-UTC gives
> you 2048 Leap Seconds, so, by your table 1, back to year 1000 or
> there abouts. That would be good enough for a lot of historical
> events. Who uses it for what would drive the implementation choices.
> 32-bits is very lightweight. Its just an observation - your target
> range is bigger.
> 
> -Brooks
> 

-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Sun, 2016-04-24 at 20:33 -0400, Brooks Harris wrote:
> Hi John,
> 
> I like the idea in general, even if its a solution in search of a
> problem. I think many fields would find it useful if it found
> agreement and acceptance.
> 
> Consider this:
> 
> For your "specification" I'd suggest you define the data type
> generically so it can be implemented, represented, and transported by
> various platforms and technologies - c/c++, Java, .NET, XML, REST,
> SQL, etc, etc.
> 
> There are two critical data values: the "date" value and the TAI-UTC
> value. Some *comments* in YMDhms form is probably be helpful (what
> does date -123456 mean?), but the "date" variable value takes
> precedence.
> 
> Define day zero as the first day of the integral UTC era - 1972-01-01 
> 00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC) is the calibration point
> at which the relationship between atomic time and observed mean solar
> time was made to converge on exactly 10 integral seconds as
> determined by the development process of UTC.
> 
> Use negative 86400 second days as the "date" variable. Thus the last
> day of your timescale is -1, which is also the last day of the
> "rubber band UTC era" .
> 
> With that you've created a timescale of your own with no confusion or
> controversy with Julian date, MJD, or NTP seconds and with an
> unambiguous relation to UTC. A statement of how each of these are
> aligned to your proleptic timescale might be useful or necessary but
> your timescale is not dependent on the definitions or interpretation
> of these other timescales.
> 
> The range is as high as you want - its probably not necessary to
> point out a signed 64-bit day number value is a very large number of
> days, something like -25,252,216,391,115,000 years, which should
> cover it. I'll leave it to your research to decide how many Leap
> Seconds that might require.  :-)
> 
> I'd also point out a data type using a 21-bit day number counter and
> an 11-bit TAI-UTC value variable can support a range of approximately
> 3000 years in 4 bytes, 32-bits. This is a nice small data type
> suitable for fast transfer and compact storage in binary
> implementations.
> 
> -Brooks
> 

Hi Brooks,

I agree that the data file should have comments which express the dates
as year-month-day.  However, I don't understand the benefit of coding
the date as negative 86,400-second days.  There is already a well-
understood and widely used coding for days: the Julian Day Number.
 Doing something non-standard just to create a unique time scale
doesn't seem like a good enough reason.

I am happy for programs which read the data file to compress it to suit
their needs, but TAI-UTC won't fit in 11 bits if you want to go back to
the year -1000, which has a DTAI over 25,000.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Sat, 2016-04-23 at 21:44 +0800, Sanjeev Gupta wrote:
> 
> > 
> How far back do we have to go before we have multiple leap seconds
> *per day* ?
> 
> -- 
> Sanjeev Gupta
> +65 98551208     http://www.linkedin.com/in/ghane

I don't have an exact figure, but the length of Earth's day changes by
about 2.3 milliseconds per century, so it will take something like
50,000 years for an ordinary day to be 86,399 or 86.401 seconds.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Sat, 2016-04-23 at 02:34 -0700, Hal Murray wrote:
> 
> Keyword-value is good.
> 
> You may want to allow comments on the end of content lines.
> 
> The julian-day and year-month-day look redundant.  I wouldn't do
> that.  It 
> leads down the rathole of what to do if they don't agree.
> 
> Don't over engineer it.  Write some sample code.
> 
> 

Challenge accepted!  I should have some code to post, along with a
sample data file, in a few days.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Fri, 2016-04-22 at 14:22 -0700, Paul Hirose wrote:
> 
> That term "extraordinary day" is new to me in the context of UTC. Is
> it 
> something you invented? In the paper you use it repeatedly and avoid 
> saying "leap second" until the conclusion, where you propose a name
> for 
> the new time scale ("proleptic UTC with leap seconds").
> 

I did invent the term "extraordinary day".  I tried to avoid the term
"leap second" because I was concerned that the term would cause
confusion among those new to the subject.  A "leap year" is a year with
an extra day.  A day with an extra second should therefore be called a
"leap day", but instead we call the extra second a "leap second".  Then
there is the "negative leap second", when we have a day of 86,399
seconds.

To avoid what I felt was confusing terminology I invented two kinds of
"extraordinary day", one with 86,399 seconds and the other with 86,401
seconds.  A day with 86,400 seconds is an "ordinary day".
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Fri, 2016-04-22 at 01:59 -0700, Hal Murray wrote:
> john_sau...@systemeyescomputerstore.com said:
> > 
> > I agree that publishing a table is a good idea.  Any suggestions
> > on the format? 
> ntpd knows how to parse a file with times when leap seconds did
> and/or will 
> happen.  Sample here:
>   http://www.ietf.org/timezones/data/leap-seconds.list
> It's got enough comments to explain what's going on.
> 
> It's using NTP time - relative to 1 January 1900, 00:00:00
> 
> You could use the same format with negative numbers for before 1900
> or pick 
> your own starting point.
> 
> 

I like using DTAI instead of Delta T in the second column, since DTAI
is based on TAI, which drives UTC, whereas Delta T is based on TT.
 However, I don't like the coding for the first column.  It goes
negative before 1900, as you mentioned, and it seems too NTP-oriented.
 How about just using the Julian Day Number?  Column 1 can be the
Julian Day Number of the extraordinary day, column 2 can be the new
value of DTAI reached at the end of the day, and the text after the #
can be the date spelled out.  Since DTAI is defined as 0 on January 1,
1958, an entry would be

2436204 0 # 31 Dec 1957

Strictly speaking, Julian Day Number 2436204.0 is noon on December 31,
1957, but we are just using the number to specify the day, not to
specify the time within that day.

What do you think?
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Thu, 2016-04-21 at 23:56 -0700, Hal Murray wrote:
> > 
> > Think about the code that some poor programmer is going to have to
> > write as
> > they read your PDF. Instead of an if-else-if sequence that goes on
> > for
> > pages, is there a simpler way to generate pUTC? I mean, no human is
> > going to
> > read your PDF and manually go through the guidelines you present.
> > So maybe
> > think of the code first instead of the prose. 
> The if-else mess can be turned into a loop scanning a table.  (or
> binary 
> search)
> 
> If the table format is anything sane, you could publish the table
> someplace 
> public and give it a name.  If somebody comes along with a better
> proposal, 
> they can publish their table.  Any paper that uses this technique
> needs to 
> specify which table they use.
> 
> I think there is already something similar for correcting carbon-14
> dates.  
> If you publish a paper using C-14 dating, you specify which
> corrections you 
> used.
>   https://en.wikipedia.org/wiki/Radiocarbon_dating#Atmospheric_variat
> ion
> 
> 
> 

I agree that publishing a table is a good idea.  Any suggestions on the
format?
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

On Thu, 2016-04-21 at 18:49 -0700, Tom Van Baak wrote:
> > 
> > Hi Tom,
> > 
> > The values presented in the 2004 Morrison and Stephenson paper are
> > already smoothed using a series of cubic splines and a parabola
> > prior
> > to -700.  See their table 1 and its discussion.  The authors
> > recommended simple interpolation between the listed years, so I did
> > that rather than add additional smoothing.
> Right. Just use their polynomial then, or go back to their original
> data.
> 

Based on your suggestion, I found an earlier paper, at 

<http://www.caeno.org/_Feat/pdf/F53_Stephenson_Delta-T%20complex%20anal
ysis.pdf>.

However, I doubt that going back to their original data, and repeating
their analysis, will result in a simpler form of the table, with as
much accuracy.  Consider that they "patched" their table in the 2005
paper--a simpler form would have to include that.

> > 
> > To me, the only troubling thing about creating a high-precision
> > representation of low-precision data is the implication that the
> > result
> > has greater accuracy than its source.  I attempted to address that
> > in
> > my conclusion by stating that the choice of extraordinary days in
> > ancient times is somewhat arbitrary.
> With pUTC you're already throwing away 90% of what UTC stands for.
> The only thing you retain is applying a leap second just before
> midnight. So instead of pages of prose that describe how to do the
> mapping, with every century or decade different, why not just
> generate a function that converts JD into a proleptic leap second
> count. Since pUTC is fictitious anyway, there's no requirement to
> have the leaps at the end of a month or weirdly spaced on the 15th or
> 28th/29th/30th/31st. Instead just generate a leap on the day when
> it's needed, regardless of what day number or month number it is.
> 
> I say this because you're generating a subjective table, one based on
> data from a fitted polynomial, which is itself based on measurements
> of dubious accuracy in the first place, measurements that can be
> revised from time to time depending on historical research. The whole
> thing doesn't pass my smell test.
> 
> The other way to think about it, what are you minimizing or
> maximizing in the design of your tables. If someone else comes up
> with a different table design, how do you choose which is better. Is
> minimum RMS of |DUT1| the goal? Must |DUT1| < 0.9 s? How can you be
> sure? Can you have double leaps instead of single leaps twice a
> month? Must the leaps occur only at the end of a month? Why not space
> them every 365 / N days within a year? Then again, at this level
> you're dealing with JD anyway, so pUTC doesn't itself need to be tied
> to years, or arbitrary power of ten boundaries. Morrison and
> Stephenson's use of year isn't exactly strict.
> 
> Think about the code that some poor programmer is going to have to
> write as they read your PDF. Instead of an if-else-if sequence that
> goes on for pages, is there a simpler way to generate pUTC? I mean,
> no human is going to read your PDF and manually go through the
> guidelines you present. So maybe think of the code first instead of
> the prose.
> 
> It looks to me like you have a subjective solution looking for a
> poster child problem. I would feel much better if you or anyone else
> on the list could start with a couple of real examples of a problem,
> and then consider what algorithmic solutions solve the problem.
> 
> /tvb

My goal in the paper is to extend the modern definition of UTC back in
time.  Hence, I use the rules of UTC whenever possible.  Thus,
extraordinary days are the last day of the month, and are limited to
86,399 or 86,401 seconds.  Considering that Morrison and Stephenson did
the heavy lifting in determining delta T, I wished to defer to them.

To address the coding problem, I have been thinking that I should
create a table of extraordinary days and publish it.  That would make a
good follow-up to the paper, in my opinion.

Yes, this is a solution looking for a problem.  Perhaps there is a
problem out there looking for a solution, and by publishing this paper
I can bring the two together.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

I neglected to mention the URL for my revised paper.  It is

https://www.systemeyescomputerstore.com/proleptic_UTC.pdf

    John Sauter (john_sau...@systemeyescomputerstore.com)

-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] Leap Seconds schedule prior to 1972

[John Sauter]

I have updated my proposal for extending UTC to dates before 1972.
The principal changes are the removal of the section on NTP and a
somewhat hand-waving justification for using atomic time before the
invention of the atomic clock.  I have also addressed the other 
feedback provided here by going into more detail about the meaning of 
table 1, acknowledging UTC before 1972, and proposing a name for the 
time scale.

I am requesting additional feedback on the revised paper.

Here is the justification for using atomic time prior to the invention 
of atomic clocks:

``For a time scale to be useful for measuring events, it must be based
on some physical property that can be measured.  UTC is based on the
SI second, which is defined as the duration of 9,192,631,770 periods
of the radiation corresponding to the transition between the two 
hyperfine levels of the ground state of the cesium 133 atom when it is 
at rest with respect to the Earth, at a temperature of 0 degrees 
Kelvin, and located at mean sea level.  These measurements are made 
continuously by national laboratories around the world.  The data is 
sent to the International Bureau of Weights and Measures, which 
combines the information and disseminates International Atomic Time,
upon which UTC is based.

``A time scale used for scientific measurements must be rigorously 
defined and robustly measured, as International Atomic Time is.  If we 
try to extend this definition backward into ancient times, we run into 
the problem that there were no atomic clocks before 1955, and 
therefore nobody was measuring the SI second as it is presently 
defined.

``However, when describing ancient events, we do not need to actually 
measure time, we can instead imagine that we are measuring it.  For 
example, we say that the Big Bang that marked the start of the 
Universe took place 13.8 billion years ago.  In this context,
``years'' does not refer to the number of times that the Earth has 
gone around the Sun since the Big Bang, because the solar system has 
only been in existence for the last 4.54 billion years.  Instead, we 
take the present duration of a year and project it back in time,
thus imagining that we are measuring time using the year as it 
presently exists.

``Similarly, we can imagine that atomic clocks have been measuring
time for the last 3,000 years, and use that as our time scale.  This 
imaginary time scale does not have the precision of International 
Atomic Time, since there were not, in fact, atomic clocks 3,000 years 
ago, but it is sufficient for our limited purpose.''

Thank you,
John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap seconds schedule prior to 1972

[John Sauter]

On Wed, 2016-04-13 at 00:37 +0100, Zefram wrote:
> John Sauter wrote:
> > 
> > https://www.systemeyescomputerstore.com/proleptic_UTC.pdf.
> Your abstract says you provide a leap schedule for 1900 to 1971, but
> actually you provide a leap schedule for -1000 to 1971.  The abstract
> seems to suggest some distinction in objective between what is done
> for
> the 20th century and for the preceding 2900 years, aiming to "cover"
> the latter but "construct a table of leap seconds" for the former, a
> distinction that doesn't seem to make sense and doesn't actually
> exist
> in the paper.  (You do give the leap table in a second format for the
> 20th century portion, but in substance this is only duplicating part
> of
> the table earlier in the paper.)
> 
> Your proleptic leap schedule generally looks sane.  I haven't checked
> the numbers in detail.  It is good to incorporate Tony Finch's pUTC,
> as
> you do.  Where more than 12 leaps are required in a year, your
> extension
> to leaping on the 15th day of a month is sensible.
> 
> Your delta-T table confuses points in time with the intervals between
> them.  The delta-T column itself applies to (the start of?) the
> specific
> year listed, but the "change in delta-T" and "seconds per year"
> columns
> apply to the interval between the year listed on that line and the
> year
> listed on the following line.
> 
> The column labelling for that table, and its accompanying text, isn't
> great.  You should state what delta-T means, address units, and
> generally
> make clearer what the table means.
> 
> You write generally as if UTC exists only for 1972 onwards.  You
> should
> acknowledge the existence of the former (1961 to 1971) rubber-seconds
> UTC, and make clear that your schedule is not a proleptic extension
> of
> the whole of UTC but only of the leap-seconds form of UTC.
> 
> Your NTP material is mostly a mistake.  For NTP's purpose of clock
> synchronisation, it needs to know about contemporary leap seconds,
> but
> has no need for knowledge of historical leap seconds.  There is
> therefore
> no value, for this purpose, in extending the historical leap schedule
> further back.  It is entirely erroneous to suppose that this paper
> has
> any bearing on NTP, and I see no value in the paper mentioning NTP.
> Some of the specific things you say about NTP are in error, but I
> won't
> go into detail due to this overriding concern.
> 
> You should address the question, currently ignored, of what time
> scale
> your proleptic UTC is based on.  If your aim is to fully construct
> a time scale, this is a necessary component.  Actual UTC, both of
> the leap-seconds form and the rubber-seconds form, is defined as
> a transformation of TAI.  TAI is only defined back to some time in
> 1955, because it is defined by the actual operation of atomic clocks.
> This covers Finch's pUTC, but you go far further back, millennia
> before
> there are any atomic clocks.  The delta-T figures that you used are,
> strictly, referenced to TT.  To construct a usable time scale you'll
> need
> to use something close to TT as the basis, and manage the transition
> between your proleptic basis time scale and the real TAI-based UTC.
> I'd be inclined to use the basis TAI(TT) = TT - 32.184 s prior to
> 1977,
> switching to TAI at 1977-01-01T00:00:00 TAI when by definition
> TAI(TT)
> = TAI, though this does mean using a different basis from the real
> UTC
> for five years of real leap-seconds-UTC history.
> 
> It would be helpful for you to provide a distinctive name for the
> time
> scale that you construct.  "Proleptic UTC" is a reasonable
> description,
> but not sufficiently specific to use as a name.
> 
> -zefram
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

Thank you for your detailed criticism, Zefram.  I will think about what
you have said and revise the article.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap seconds schedule prior to 1972

[John Sauter]

On Mon, 2016-04-11 at 11:10 -0700, Steve Allen wrote:
> On Mon 2016-04-11T10:17:33 -0400, John Sauter hath writ:
> > 
> > Using ancient observations of the Sun and Moon, construct a time
> > scale
> > using the modern definition of Coordinated Universal Time to cover
> > the
> > past 3,000 years. Use the 20th century portion of that time scale
> > to
> > construct a table of leap seconds from 1900 through 1971 for NTP.
> I find this to be akin to offering an answer to this question:
> What is the arcsine of -2?
> 
> While there may be some applications which need that sort of answer,
> in general it is important to recognize that prior to 1972-01-01
> there
> were no civil applications making use of SI seconds.  Every practical
> application before 1955 was using mean solar seconds.
> 
> A time scale based on SI seconds extended back to 1900 does not
> correspond to any contemporary use.  The nature of time scales in
> actual use over history is necessarily piecewise continuous.
> Applications should be aware of that and make a choice about whether
> they want conceptual simplicity or a particular kind of technical
> accuracy.  In general it is better for the characteristics of the
> time
> scale to be driven by the needs of the application rather than
> supplied in the absence of particular requirements.
> 
> So this is cool, and may be applicable to some applications, but I'm
> not sure which ones those are.
> 
> --
> Steve Allen <s...@ucolick.org>   WGS-84
> (GPS)
> UCO/Lick Observatory--ISB   Natural Sciences II, Room
> 165   Lat  +36.99855
> 1156 High StreetVoice: +1 831 459 3046  Lng
> -122.06015
> Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250
> m

Thanks for taking the time to read the article, Steve.  You are, of
course, correct that the choice of time scale needs to be driven by the
needs of the application.  As you hint, this is a solution looking for
a problem.  It is my hope that by publishing the article perhaps it can
find a problem.

The application I have in mind is similar to Mayan scholars who write
for a general audience, and use proleptic Gregorian so they can express
dates in a familiar form.  Perhaps there is an application that wishes
to describe times that are precise to the second, but are a thousand
years ago.
    John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] leap seconds schedule prior to 1972

[John Sauter]

I have proposed a schedule of leap seconds prior to 1972 based on the
Earth's rotation rate, which was deduced from ancient observations of
the Sun and Moon.  The complete paper is available on my web site, at 

https://www.systemeyescomputerstore.com/proleptic_UTC.pdf.

I would be grateful for any criticism, particularly any suggestions for
improving the paper.  It is my goal to publish this paper on arXiv.org,
perhaps in the astro-ph section.

Here is the abstract:

Using ancient observations of the Sun and Moon, construct a time scale
using the modern definition of Coordinated Universal Time to cover the
past 3,000 years. Use the 20th century portion of that time scale to
construct a table of leap seconds from 1900 through 1971 for NTP.

John Sauter (john_sau...@systemeyescomputerstore.com)
-- 
PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



signature.asc
Description: This is a digitally signed message part
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs