t might be
interesting for tinkerers.)
Gerry Ashton
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
With WWV and a older-style shortwave receiver, the public has the ability to
set a stopwatch or similar device to sub-second accuracy. More importantly, a
person who isn't a time lord can be reasonably certain they have accomplished
this task correctly.
With any other device I can think of, the
> On June 6, 2018 at 12:57 PM Rob Seaman wrote:
>
>
> Usual range of opinions. These guys think they've solved the problem for
> all time:
>
> https://news.wisc.edu/thank-the-moon-for-earths-lengthening-day/
>
> As you say, not much pertinent to leap seconds.
>
> Rob
> --
>
> I'm not s
> On March 20, 2018 at 3:07 PM Warner Losh wrote:
>
>
> On Tue, Mar 20, 2018 at 7:59 AM, GERRY ASHTON wrote:
>
> > Perhaps this is too obvious to mention, but if there is a desire to allow
> > |UTC-UT1| somewhat greater than 1 s, but much less than 1 minute, in
Perhaps this is too obvious to mention, but if there is a desire to allow
|UTC-UT1| somewhat greater than 1 s, but much less than 1 minute, in order to
schedule leap seconds further in advance, it will still be necessary to limit
each correction to 1 s. This is because a vast number of standards
> On October 23, 2017 at 1:37 PM Brooks Harris wrote, in
> part:
>
> The irreconcilable difficulty arises from UTC being a modification of
> the Gregorian calendar algorithm. The world (mostly) uses Gregorian, but
> then along comes this unpredictable and irregular Leap Second to upset
> the
ther?
>
In addition to any astronomical reasons for adding negative leap seconds, leap
seconds could be used to gradually align UTC to some atomic time scale such as
TAI or GPS. After 2016, I won't rule out any political event.
Gerry Ashton
__
> On February 1, 2017 at 3:24 AM Zefram wrote in part:
>
> The maths isn't done in the irregular radix. For the purposes of
> expressions such as "TAI - UTC" that require a UTC time to be reduced to
> a scalar value, that scalar is derived using the regular radix values.
> This means that, yes,
How I would interpret "offset":
Bulletin C 52
The difference between UTC and the International Atomic Time TAI is:
from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s
___
> ...On January 31, 2017 at 7:08 PM Steve Allen wrote in
> part:
> I prefer to think of a leap second as being truly intercalary.
> It is saying to atomic clock "It's not tomorrow yet, wait a second."
> It is between one calendar day of UTC and the next calendar day of UTC.
> It belongs to neith
> On January 30, 2017 at 7:21 PM Tom Van Baak wrote:
>
>
> >>from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s
> >>from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s
> >>
> >Pretty clear? Let's try. What does Bulletin C52 say about the
> >
On January 9, 2017 at 6:55 PM John Sauter
wrote in
part: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 [Preben Nørager] mean when [Preben Nørager said] "Leap
seconds are really
only a need
The Gregorian calendar and UTC with leap seconds are in harmony; the customary
change-of-day time with the Gregorian calendar is midnight, and the methods
used to establish midnight throughout most of the time the Gregorian calendar
has been in use did not approach accuracy of tens of seconds. I
> On December 29, 2016 at 6:00 PM Steve Allen wrote, in part:
>
> On Thu 2016-12-29T09:26:58 -0700, Warner Losh hath writ:
>
> > How do you deal with acquiring knowledge of leap seconds after you've
> > given out 'old' timestamps that might be affected by them? This is
> > best described as how
/cookbooks.html
C cookbook for time:
http://www.iausofa.org/sofa_ts_c.pdf
Gerry Ashton
> On December 13, 2016 at 3:19 PM Tom Van Baak wrote:
>
> Eric, and time nuts -- A very nice set of questions and an interesting
> application. In fact it's so time nutty that I'
The Microsoft Azure approach of moving the leap second to local midnight has
been discussed. I don't know enough about Azure to say if it is acceptable in
that context, but as a general approach, I object to midnight. National
authorities in the US and Canada have decided the hour shift for dayl
16 matches
Mail list logo
