/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
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
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 observat
t 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.c
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.
>
>
>
>
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.
>
>
>
>
, 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 S
ry. 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 seco
.
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
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
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
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
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
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)
-
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 (joh
On Sun, 2017-10-22 at 23:46 -0600, Warner Losh wrote:
>
>
> On Sun, Oct 22, 2017 at 11:02 PM, John Sauter computerstore.com> wrote:
> > On Sun, 2017-10-22 at 17:53 -0700, Steve Allen wrote:
> > >
> > > The BIPM has contributed
> > > CGPM draft
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
ve 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@le
ngth 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...@syst
h of the day.
I am located in the US and have programmed in FORTRAN. Algol was my
first language but it also uses index-1 arrays.
If you project far enough into the past or future, leap seconds are not
always on the last day of the month, so for those applications the day
is not redundant.
John Sauter (john_sau...@systemeyescomputerstore.com)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
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 n
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 pr
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
> >
h 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
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 finger
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 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
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
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
M, 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
ings, 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 s
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...@systemeyescomputer
tual 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
n, 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 f
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 misgu
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
he 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
Descriptio
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
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 f
; 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)
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...@systemeyescomputers
On Tue, 2017-01-03 at 14:53 -0500, Michael Rothwell wrote:
>
>
> On Tue, Jan 3, 2017 at 2:18 PM, John Sauter mputerstore.com> wrote:
> > On Tue, 2017-01-03 at 13:28 -0500, Michael Rothwell wrote:
> > >
> > > This was probably covered elsewhere, and I apolo
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 E24
o 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 D25
On Wed, 2016-12-28 at 14:01 +0800, Sanjeev Gupta wrote:
>
> On Tue, Dec 27, 2016 at 11:36 PM, John Sauter computerstore.com> wrote:
> > > Also note that many large radar systems have built-in simulators,
> > > used
> > > for system integration
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
>
ntury 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
loss. 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 E5F
ce 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)
tch) 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 fin
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 ti
letely. 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.
Joh
ot;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 you
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
xist.
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
D
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)
-
ot 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.
es, 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
econds, 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 5
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 ac
en 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 t
://www.systemeyescomputerstore.com/proleptic_UTC.pdf
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
://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
v.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 ma
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
as comments they could be changed
easily. Perhaps we should show both forms. What do other people on
this list think should be done?
John Sauter (john_sau...@systemeyescomputerstore.com)
--
PGP fingerprint = E24A D25B E5FE 4914 A603 49EC 7030 3EA1
9A0B 511E
signature.asc
Description:
y 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 = E2
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
pact 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
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 sta
ng 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
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
hat 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 4
keyword=value lines contain such things as start date, end
date, expiration date and checksum.
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
__
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
Do you think that would be reasonable? If so, how would you
format it?
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
__
I 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...@system
>
> 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
> io
e. 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
creat
. I attempted to address that in
my conclusion by stating that the choice of extraordinary days in
ancient times is somewhat arbitrary.
John Sauter (john_sau...@systemeyescomputerstore.com)
--
PGP fingerprint = E24A D25B E5FE 4914 A603 49EC 7030 3EA1
9A0B 511E
sig
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
ale. 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
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. Th
On Tue, 2016-04-12 at 07:58 -0600, Warner Losh wrote:
>
>
> On Mon, Apr 11, 2016 at 8:17 AM, John Sauter omputerstore.com> wrote:
> > I have proposed a schedule of leap seconds prior to 1972 based on
> > the
> > Earth's rotation rate, which was deduced from
On Tue, 2016-04-12 at 11:40 +0100, Tony Finch wrote:
> John Sauter wrote:
>
> > 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 co
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
&
ersal 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
signatur
87 matches
Mail list logo
