Re: [LEAPSECS] UT1 offset

On Wed, Dec 27, 2023 at 6:04 AM Jim Lux wrote: > Let’s back of the envelope the impact of a 1 second error in a longitude > sight. > The Sun moves 360 degrees in 86400 seconds. A one second error is then > about 0.004 degree. But in equatorial km, let’s assume 40,000 km > circumference, so

Re: [LEAPSECS] prep for WRC 23

On Sat, Dec 23, 2023, 12:02 PM Poul-Henning Kamp wrote: > Michael Deckers via LEAPSECS writes: > > >> My Tl;dr version of the resolution is: > > > >> . Please keep DUT1 less than 100 seconds. > > > k) that the maximum value for the difference between UT1 and UTC > > should be

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

506 453-5142 > | > | University of New Brunswick > | > | Fredericton, N.B., Canada E3B 5A3 > | > |Fredericton? Where's that? See: http://www.fredericton.ca/ >| > > ----- > >

Re: [LEAPSECS] smear

On Mon, Mar 20, 2023 at 2:10 PM Steve Allen wrote: > On Mon 2023-03-20T19:36:51+ Michael Deckers via LEAPSECS hath writ: > > � This seems to be lenient enough to allow for not scheduling > > � a negative leap second even in the case that the difference > > � (UT1 - UTC) should go a bit below

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

On Mon, Mar 20, 2023 at 1:37 PM Michael Deckers via LEAPSECS < leapsecs@leapsecond.com> wrote: > > On 2023-03-20 07:54, Jürgen Appel via LEAPSECS wrote: > > > > In your Conclusion, you say "the CGPM resolution also stipulates that no > > change to current practices can occur before 2035." > >

Re: [LEAPSECS] leap minute or hour

On Fri, Nov 18, 2022 at 9:34 PM Zefram via LEAPSECS wrote: > Eric Scace wrote: > > This is much easier to deal with than writing code for future leap > > second changes on dates yet to be established/promulgated. > > It does ameliorate the problem of distribution of the leap schedule, > but

Re: [LEAPSECS] Alanna Mitchell in NYT

On Mon, Nov 14, 2022 at 10:40 AM Steve Allen wrote: > Starting tomorrow the CGPM meets in Paris. > Resolution D says leap seconds must die. > CGPM will almost certainly approve that resolution. > > https://www.nytimes.com/2022/11/14/science/time-leap-second.html I'm happy to see this... I

Re: [LEAPSECS] article for Metrologia

n't adequately addressed 20 years later. Warner Joe Gwinn > > On Sat, 29 Oct 2022 18:16:14 +0200, Steffen Nurpmeso wrote: > > Warner Losh wrote in > > : > > |On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso > > |wrote: > > |> Steve Allen wrote in > >

Re: [LEAPSECS] article for Metrologia

On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso wrote: > Steve Allen wrote in > <20221028045813.ga20...@ucolick.org>: > |On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ: > |> Levine, Tavella, and Milton have an upcoming article for Metrologia > |> on the issue of leap seconds in UTC

Re: [LEAPSECS] article for Metrologia

On Thu, Oct 27, 2022 at 8:25 PM Steve Allen wrote: > Levine, Tavella, and Milton have an upcoming article for Metrologia > on the issue of leap seconds in UTC > > https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b "We are sorry, that page has not been found..." Is that because I

Re: [LEAPSECS] fb/meta join the leap second haters

On Tue, Jul 26, 2022 at 5:33 PM Poul-Henning Kamp wrote: > So looking at the IERS LOD plot going all the way back it seems to > me that we have been missing the big signal for about five decades: > > > https://datacenter.iers.org/singlePlot.php?plotname=EOPC04_14_62-NOW_IAU2000A-LOD=224 > > How

Re: [LEAPSECS] podcast from Orolia

"What is a leap second and why don't we want it?" I wonder where this is going and if I'll like it more than my leap second rants. Warner On Tue, May 3, 2022 at 3:20 PM Steve Allen wrote: > Orolia has a 17 minute podcast about leap seconds > >

Re: [LEAPSECS] Fw: IERS Message No. 417: Questionnaire on time metrology, including leap seconds in UTC

scales, one must have additional information about them: where they deviate from some standard / benchmark and where they have disconformities (eg leap seconds) as well as for the span of time the information is valid over. Warner On Thu, Dec 17, 2020 at 11:34 AM Warner Losh wrote: > Tha

Re: [LEAPSECS] LOD reaches 0 s/d

On Thu, Nov 12, 2020 at 5:24 PM jimlux wrote: > On 11/12/20 3:45 PM, Poul-Henning Kamp wrote: > > > > > >> predicts that d(UT2)/d(TAI) = 1 after 2021-11-13, ie > >> the rates of UTT2 and TAI are expected to agree for the > >> next year. This has never happened since 1961.

Re: [LEAPSECS] LOD reaches 0 s/d

On Thu, Nov 12, 2020 at 4:46 PM Poul-Henning Kamp wrote: > > > > predicts that d(UT2)/d(TAI) = 1 after 2021-11-13, ie > > the rates of UTT2 and TAI are expected to agree for the > > next year. This has never happened since 1961. We may > > not need to abolish leap

Re: [LEAPSECS] Bulletin C number 60

On Sun, Jul 12, 2020, 9:07 AM Poul-Henning Kamp wrote: > > Tony Finch writes: > > > The LOD is hovering around 0 and the UT1-UTC chart is looking remarkably > flat. > > > > > https://datacenter.iers.org/singlePlot.php?plotname=FinalsAllIAU2000A-UT1-UTC-BULA=9 > > > > >

Re: [LEAPSECS] coördinated time

"I shall endeavor to point out all that experience has forced upon me." Wow! If that doesn't describe the discussions on this list to a T, I don't know what does :) Warner On Tue, Mar 31, 2020 at 11:12 AM Eric Scace wrote: >Attached are two letters discussing coördinated time: > >- G.

Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

On Thu, Feb 13, 2020, 12:36 PM Tom Van Baak wrote: > > I thought of Loran... but you need 2 stations for time, I thought... > > 2 (or more) Loran-C stations gave you more accurate time. But if you know > where you are, and since the stations don't move, you can manually adjust > for signal

Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

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

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

On Thu, Feb 6, 2020 at 7:17 AM Brooks Harris wrote: > On 2020-02-06 9:08 AM, Warner Losh wrote: > > > > On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak wrote: > >> Hi Hal, >> >> It's 2020. How on earth can NTP still not implement UTC correctly, in all >> cas

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

On Thu, Feb 6, 2020, 3:22 AM Tom Van Baak wrote: > Hi Hal, > > It's 2020. How on earth can NTP still not implement UTC correctly, in all > cases? Or is it a fundamental NTP design flaw? > Design flaw. NTP time stamps can't encode a leap second. It can therefore never really work in all cases.

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

On Tue, Feb 4, 2020 at 7:31 AM Brooks Harris wrote: > On 2020-02-04 2:54 AM, Warner Losh wrote: > > > > Have I forgotten any of the other details of leap seconds that are > > more tribal knowledge than rigorously specified? > > > > Warner > > > > >

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

On Mon, Feb 3, 2020, 6:01 PM Brooks Harris wrote: > On 2020-02-03 10:37 AM, Michael Deckers via LEAPSECS wrote: > > > > > >The 1970 report also contains the proposal that the CIPM should be > >responsible for the definition of UTC, and 49 years later, the CGPM > >in 2019 seems to

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

On Sat, Feb 1, 2020 at 10:57 PM Seaman, Robert Lewis - (rseaman) < rsea...@email.arizona.edu> wrote: > Tried to send this a few days ago, but it never showed up on the list. > Steve has provided gritty details since. > > > > Since roughly the second world war, the distinction between time-of-day

Re: [LEAPSECS] leap seconds in POSIX

On Sat, Feb 1, 2020 at 3:39 PM Brooks Harris wrote: > > (As I understand it time_t is deprecated and replaced by struct timespec > in modern POSIX systems. This does not eliminate the leap-second > difficulty.) > Kinda sorta... the timespec struct has a time_t inside of it. > The leap-second

Re: [LEAPSECS] leap seconds in POSIX

On Mon, Jan 27, 2020 at 8:17 AM Steve Summit wrote: > Hal Murray wrote: > > Does anybody know of a good writeup of how to fix POSIX to know about > > leap seconds and/or why POSIX hasn't done anything about it yet? > > I don't know why POSIX hasn't done anything, other than that > (1) it's an

Re: [LEAPSECS] leap seconds in POSIX

On Mon, Jan 27, 2020 at 5:35 AM Tony Finch wrote: > Zefram via LEAPSECS wrote: > > Hal Murray wrote: > > >I assume the basic idea would be something like switch the kernel to > use TAI > > >rather than UTC and implement conversion in some library routines. > > > > That's not a viable approach,

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

On Wed, Jun 12, 2019 at 8:39 AM Richard Langley wrote: > And a further nit-pick. The leap-second information is not included in the > GPS Almanac (as reported in news items), per se. Of course, it's in the > navigation message, but elsewhere in the Subframe 4 and 5 data. And it is > only needed

Re: [LEAPSECS] Windows 10 time

On Fri, Apr 12, 2019 at 9:39 AM Brooks Harris wrote: > Hopefully Linux will follow suit in some manner. This might be > accompanied with updating POSIX time in some manner to support Leap > Seconds.. > The last 20 attempts to do that have failed, sadly. time_t is quite pervasive and has a

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

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

Re: [LEAPSECS] is leap smear legal in Germany?

On Mon, Feb 4, 2019 at 11:14 AM Kevin Birth wrote: > Since law significantly lags behind technology, the leap smear is probably > not illegal in any private network in any country. After all, UTC is still > not the "legal" time in many countries. > > NTP was developed after rubber seconds. If

Re: [LEAPSECS] Running on TAI

On Fri, Jan 18, 2019 at 1:35 AM Martin Burnicki wrote: > Steve Allen wrote: > > On Thu 2019-01-17T18:12:25+0100 Martin Burnicki hath writ: > >> Hm, maybe that was originally the case. I wonder whether the folks who > >> wrote the text just had UTC in mind when they "invented" time_t. > > > > The

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

On Tue, Jan 15, 2019 at 10:09 PM Gary E. Miller wrote: > Yo Warner! > > On Tue, 15 Jan 2019 17:45:32 -0700 > Warner Losh wrote: > > > > > Except that's not a leap second. struct tm doesn't do leap seconds > > > > really. It kinda sorta does, but it kinda s

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

On Tue, Jan 15, 2019 at 1:50 PM Gary E. Miller wrote: > Yo Warner! > > On Tue, 15 Jan 2019 12:43:46 -0700 > Warner Losh wrote: > > > Except that's not a leap second. struct tm doesn't do leap seconds > > really. It kinda sorta does, but it kinda sorts doesn't. &g

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

On Tue, Jan 15, 2019 at 12:41 PM Rob Seaman wrote: > Isn't this covered (for instance) in section 20.3.3.5.2.4(b) of > IS-GPS-200J (https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf)? The > various libraries and operating systems listed deal with none of the > reference time scales (GPS, UTC,

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

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

Re: [LEAPSECS] the inception of leap seconds

On Wed, Aug 15, 2018 at 5:49 AM, Zefram wrote: > Another thing missing from the analogy is the distinction > between arithmetical and observational calendars, which is very relevant, > UTC being observational and the Julian calendar (the announcement's > comparand) being arithmetical. I wish

Re: [LEAPSECS] Windows Server 2019

On Mon, Jul 23, 2018 at 12:52 PM, Steve Allen wrote: > On Mon 2018-07-23T13:58:49-0400 Stephen Scott hath writ: > > I have not found any specifications or official documents that specify > that > > the leap second shall be incorporated just before the time instant > midnight > > UTC for all UTC

Re: [LEAPSECS] Windows Server 2019

On Mon, Jul 23, 2018 at 9:40 AM, Steve Allen wrote: > On Fri 2018-07-20T12:16:07-0600 Warner Losh hath writ: > > Unless you are at UTC+0, I don't see how this can be right... Leap > seconds > > happen during the day for most time zones... > > On Fri 2018-07-20T16:11:12

Re: [LEAPSECS] Windows Server 2019

On Fri, Jul 20, 2018, 12:05 PM Stephen Scott wrote: > I would agree and I am not a fan of leap second smearing. > A.) For an application that depends on an accurate frequency reference > smearing over 24 hours represents about a 11 ppm frequency shift. This > exceeds the tolerance specified for

Re: [LEAPSECS] Windows Server 2019

On Fri, Jul 20, 2018 at 6:03 AM, Nero Imhard wrote: > scs...@eskimo.com schreef op 2018-07-20 11:35: > > The question of what happens if you try to run a leapsec-aware > kernel downstream of a smearing NTP server is an interesting one. > My preferred answer is "Don't do that." > > > If that

Re: [LEAPSECS] Fwd: IERS Message No. 354: Recent changes to the IERS 14 C04 series / Bulletin B

In short, they used some bad values without realizing it, then followed a process that was flawed that amplified the bad values. Someone noticed the small, but accumulating error and they've updated their process and re-run the numbers. Did I miss something? Warner On Tue, May 8, 2018 at 8:28

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

On Tue, Mar 20, 2018 at 1:59 PM, GERRY ASHTON <ashto...@comcast.net> wrote: > > > On March 20, 2018 at 3:07 PM Warner Losh <i...@bsdimp.com> wrote: > > > > > > On Tue, Mar 20, 2018 at 7:59 AM, GERRY ASHTON <ashto...@comcast.net> > wrote:

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

On Tue, Mar 20, 2018 at 7:59 AM, GERRY ASHTON wrote: > Perhaps this is too obvious to mention, but if there is a desire to allow > |UTC-UT1| somewhat greater than 1 s, but much less than 1 minute, in order > to schedule leap seconds further in advance, it will still be

Re: [LEAPSECS] UT1 via NTP

On Mon, Mar 19, 2018 at 2:02 PM, Gary E. Miller wrote: > Yo Hal! > > On Mon, 19 Mar 2018 12:41:46 -0700 > Hal Murray wrote: > > > Perhaps we should setup a simple UDP server that responds with the > > UT1-UTC offset. The idea is that you can get a good

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

On Sun, Mar 18, 2018 at 11:12 PM, John Sauter < john_sau...@systemeyescomputerstore.com> wrote: > On Sat, 2018-03-17 at 22:52 +, Michael.Deckers via LEAPSECS wrote: > > > So, the likely future is that the limit on |UT1 - UTC| will be > > dropped, > > leap seconds will no longer be

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

On Fri, Mar 16, 2018 at 10:16 AM, Matsakis, Demetrios N CIV NAVOBSY, N3TS < demetrios.matsa...@navy.mil> wrote: > I was surprised to find phrases in the Lick web pages: "CCIR ignored the > advice that astronomers " and "squelched astronomers who insisted that leap > seconds would cause trouble".

Re: [LEAPSECS] leap second roundup 2017

On Mon, Oct 23, 2017 at 3:42 PM, Brooks Harris <bro...@edlmax.com> wrote: > On 2017-10-23 02:07 PM, Warner Losh wrote: > > Never has been really, but it was the objective for centuries. Local time > is obviously a gross approximation, but a very useful one. Before atomic >

Re: [LEAPSECS] leap second roundup 2017

On Mon, Oct 23, 2017 at 11:37 AM, Brooks Harris wrote: > On 2017-10-23 09:58 AM, Rob Seaman wrote: > >> Multiple timescales exist now for multiple purposes. Multiple timescales >> will exist under all scenarios. Debasing Universal Time is not a >> solution to any "real world"

Re: [LEAPSECS] leap second roundup 2017

On Mon, Oct 23, 2017 at 9:00 AM, Poul-Henning Kamp wrote: > > > > By that logic one should avoid intervals spanning the end of February > > because of leap days, and avoid any periods in the spring or fall (in > > either hemisphere) that might span local DST

Re: [LEAPSECS] leap second roundup 2017

On Mon, Oct 23, 2017 at 7:28 AM, John Sauter < john_sau...@systemeyescomputerstore.com> wrote: > On Sun, 2017-10-22 at 23:46 -0600, Warner Losh wrote: > > > > > > On Sun, Oct 22, 2017 at 11:02 PM, John Sauter <John_Sauter@systemeyes > > computerstore.com> w

Re: [LEAPSECS] leap second roundup 2017

On Sun, Oct 22, 2017 at 11:02 PM, John Sauter < john_sau...@systemeyescomputerstore.com> wrote: > On Sun, 2017-10-22 at 17:53 -0700, Steve Allen wrote: > > > > The BIPM has contributed > > CGPM draft Resolution "On the definition of Time-Scales" > > For two years various meetings have indicated

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] Negative TAI-UTC

On Tue, Feb 7, 2017 at 12:03 PM, Zefram wrote: > Clive D.W. Feather wrote: >>probability is that TAI-UTC will ever be negative? Should data structures >>be designed to handle this case or not bother? > > Data structures should certainly allow for the possibility, but in >

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

On Mon, Feb 6, 2017 at 6:39 AM, Zefram <zef...@fysh.org> wrote: > Warner Losh wrote: >>So either there's some weird math that lets one subtract two numbers >>that are different and get 0 as the answer, or the delta has to change >>at the start. > > To the extent t

Re: [LEAPSECS] Negative TAI-UTC

On Sat, Feb 4, 2017 at 11:12 AM, Brooks Harris <bro...@edlmax.com> wrote: > On 2017-02-04 12:24 PM, Warner Losh wrote: >> >> On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather <cl...@davros.org> >> wrote: >>> >>> Looking only into th

Re: [LEAPSECS] BBC radio Crowd Science

On Sat, Feb 4, 2017 at 10:32 AM, Steve Summit wrote: > Warner wrote: >> I think this is the crux of my problem with Tom's answer to my first >> leap second question. We have two times, that are obviously different >> that when subtracted produce 0 as the answer. x-y = 0 should

Re: [LEAPSECS] Negative TAI-UTC

On Sat, Feb 4, 2017 at 10:24 AM, Warner Losh <i...@bsdimp.com> wrote: > On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather <cl...@davros.org> wrote: >> Looking only into the future, not historical data, what do people think the >> probability is that TAI-UTC will ev

Re: [LEAPSECS] Negative TAI-UTC

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

Re: [LEAPSECS] BBC radio Crowd Science

On Sat, Feb 4, 2017 at 8:37 AM, Clive D.W. Feather wrote: > Now define the "linearization" of a broken-down time as: > > L = D*86400 + H*3600 + M*60 + S > > In TAI, L is the number of seconds since 00:00:00 on the epoch date. > > In UTC L is *NOT* the number of seconds since

Re: [LEAPSECS] BBC radio Crowd Science

On Wed, Feb 1, 2017 at 11:14 PM, Warner Losh <i...@bsdimp.com> wrote: > On Wed, Feb 1, 2017 at 10:37 PM, Zefram <zef...@fysh.org> wrote: >> Warner Losh wrote: >>>If you are going to willfully misunderstand, then I'm done being patient. >> >> I am not

Re: [LEAPSECS] BBC radio Crowd Science

On Wed, Feb 1, 2017 at 10:37 PM, Zefram <zef...@fysh.org> wrote: > Warner Losh wrote: >>If you are going to willfully misunderstand, then I'm done being patient. > > I am not willfully misunderstanding. I have tried to understand > what you're doing, and I've been

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

On Wed, Feb 1, 2017 at 1:50 AM, Zefram <zef...@fysh.org> wrote: > Warner Losh wrote: >>I'd suggest that you re-read what I wrote, because these two >>paragraphs do not represent that at all. > > It certainly involves a different result from what you stated, but as &g

Re: [LEAPSECS] BBC radio Crowd Science

On Tue, Jan 31, 2017 at 11:02 PM, Zefram <zef...@fysh.org> wrote: > Warner Losh wrote: >>Only for time_t computations. > > The POSIX expression for time_t, if taken entirely literally, does the > same thing. But that's not the only use of a scalar behaving in this way. >

Re: [LEAPSECS] BBC radio Crowd Science

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

Re: [LEAPSECS] BBC radio Crowd Science

On Tue, Jan 31, 2017 at 12:57 PM, Brooks Harris wrote: > On 2017-01-31 02:50 PM, GERRY ASHTON wrote: >>> >>> ...On January 31, 2017 at 7:08 PM Steve Allen wrote in >>> part: >>> I prefer to think of a leap second as being truly intercalary. >>> It is saying

Re: [LEAPSECS] BBC radio Crowd Science

On Tue, Jan 31, 2017 at 12:50 PM, Brooks Harris <bro...@edlmax.com> wrote: > On 2017-01-31 02:19 PM, Warner Losh wrote: >> >> On Tue, Jan 31, 2017 at 12:08 PM, Steve Allen <s...@ucolick.org> wrote: >>> >>> On Tue 2017-01-31T13:58:15 -0500, Brooks H

Re: [LEAPSECS] BBC radio Crowd Science

On Tue, Jan 31, 2017 at 12:41 PM, Brooks Harris <bro...@edlmax.com> wrote: > On 2017-01-31 02:04 PM, Warner Losh wrote: >> >> On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <bro...@edlmax.com> wrote: >>> >>> On 2017-01-31 12:33 PM, Warner Losh wro

Re: [LEAPSECS] BBC radio Crowd Science

On Tue, Jan 31, 2017 at 12:08 PM, Steve Allen wrote: > On Tue 2017-01-31T13:58:15 -0500, Brooks Harris hath writ: >> Ah, so who's right? > > I prefer to think of a leap second as being truly intercalary. > It is saying to atomic clock "It's not tomorrow yet, wait a second." > It

Re: [LEAPSECS] BBC radio Crowd Science

On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <bro...@edlmax.com> wrote: > On 2017-01-31 12:33 PM, Warner Losh wrote: >> >> On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit <scs...@eskimo.com> wrote: >>> >>> Tom Van Baak and Michael Decker wrote: >>

Re: [LEAPSECS] BBC radio Crowd Science

On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak wrote: >>> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5 >>What kind of arithmetic is that? > > Hi Michael, > > First, there's no problem with this, right? (Thanks to Steve for catching > typo) > >

Re: [LEAPSECS] BBC radio Crowd Science

On Mon, Jan 30, 2017 at 6:06 AM, Tony Finch wrote: > Michael.Deckers. via LEAPSECS wrote: >> >>My point was that Arias' labeling makes it clear that the >>latest discontinuity in TAI - UTC occurred when TAI assumed >>the value 2017-01-01 + 36

Re: [LEAPSECS] alternative to smearing

On Thu, Jan 12, 2017 at 9:12 AM, Clive D.W. Feather wrote: > Preben Nrager said: >> If you don't care about Christ, and the church, I can understand why you >> treat all timescales alike. But if you really care about the fundamental >> timescale of science and society, then I

Re: [LEAPSECS] next leap second

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

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

Keep in mind that leap seconds have a short shelf life. Over the next 1000 years, it's projected TAI - UT will grow to about an hour (2500-4500 if I'm reading https://www.ucolick.org/~sla/leapsecs/deltat.html right). In two thousand it will be about 4 hours due to quadratic acceleration. That's

Re: [LEAPSECS] alternative to smearing

On Thu, Jan 5, 2017 at 4:26 AM, Hal Murray wrote: > > [do something N years in the future] >> Except that's not how things are programmed. Programming it that way would >> be very inefficient in a part of the kernel that has to be ultra-efficient. >> Since you don't know

Re: [LEAPSECS] alternative to smearing

On Thu, Jan 5, 2017 at 3:42 AM, Hal Murray wrote: > >> 1) The leap day in February can be handled by any isolated or autonomous >> clock or timekeeping system. A leap second can only be handled with periodic >> direct or indirect communication with IERS, or manual

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

On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit <scs...@eskimo.com> wrote: > Warner Losh wrote: >> On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit <scs...@eskimo.com> wrote: >> > 2. Have xtime keep TAI. This has the advantage that it's not at >> >all wrong

Re: [LEAPSECS] alternative to smearing

On Wed, Jan 4, 2017 at 9:36 PM, Steve Summit <scs...@eskimo.com> wrote: > Warner Losh wrote: >> Steve Summit <scs...@eskimo.com> wrote: >> > The requirement for tables (and, correspondingly, the >> > "impossibility" of dealing with future UTC dates

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

On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit wrote: > 2. Have xtime keep TAI. This has the advantage that it's not at >all wrong or kludgey to represent TAI as a simple count of >seconds since the epoch, which of course xtime already is. >The objection, as

Re: [LEAPSECS] alternative to smearing

> The requirement for tables (and, correspondingly, the > "impossibility" of dealing with future UTC dates more than a few > months out) depends on what you're trying to do. You can *talk* > about the dates, and you can do interval arithmetic with a > precision of days, hours, or minutes,

Re: [LEAPSECS] Leap seconds ain't broken

On Tue, Jan 3, 2017 at 6:35 AM, Rob Seaman wrote: > And Steve is discussing a specific legacy telescope. That rather sums up the situation today with software. We have a specific legacy standard called POSIX that's causing all kinds of issues that pop up when you least

Re: [LEAPSECS] Leap seconds still broken

On Tue, Jan 3, 2017 at 4:35 AM, Tony Finch wrote: > Come on, some of the rest of you must have seen some failure reports, > beyond just having to reboot your telescopes :-) On a purely schadenfreude note: I find it extremely ironic that there are any telescopes that have issues

Re: [LEAPSECS] Leap seconds still broken

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

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

On Sat, Dec 31, 2016 at 1:12 AM, Clive D.W. Feather <cl...@davros.org> wrote: > Warner Losh said: >> I'd think that 1712 in Sweeden was the longest year with 31708800 SI >> seconds (give or take a few hundred milliseconds, my data-sniffing fu >> isn't up the c

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

On Sat, Dec 31, 2016 at 9:31 AM, Steve Summit wrote: > I'd like to say I'm not going to worry about that sort of case > too much -- clearly, we can't implement proper leap second > handling if we can't trust our time services to report them > properly! -- but based on what I'm

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

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

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

On Fri, Dec 30, 2016 at 10:11 PM, Rob Seaman <sea...@lpl.arizona.edu> wrote: > On Dec 29, 2016, at 1:35 PM, Warner Losh wrote: > > A lot of code could have been changed while the ITU fiddled, e.g., Mac OS X > was launched in 2001. > > > Could have, but didn’t... >

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

On Fri, Dec 30, 2016 at 9:52 PM, Steve Summit <scs...@eskimo.com> wrote: > Warner Losh wrote: >> On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray <hmur...@megapathdsl.net> wrote: >> >> One could imagine having a more complicated structure that could cope with >&

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

On Fri, Dec 30, 2016 at 6:47 PM, Steve Allen <s...@ucolick.org> wrote: > On Fri 2016-12-30T17:59:14 -0700, Warner Losh hath writ: >> if you were to transition to a TAI world, then you'd not be able to >> implement the latter for a TAI time of the UTC time at some >&g

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

On Fri, Dec 30, 2016 at 5:41 PM, Hal Murray wrote: > >> One could imagine having a more complicated structure that could cope with >> the inherent ambiguity in future times. I can't say "schedule an event >> exactly 1 year from now" for example without it. I need

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

On Fri, Dec 30, 2016 at 7:28 AM, Steffen Nurpmeso wrote: > Never having done kernel programming, this doesn't sound logical > to me. You have a clock source and a conversion algorithm. That > runs every time, maybe even millions time a second? Maybe kernels > exist which

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

On Thu, Dec 29, 2016 at 9:42 PM, Rob Seaman <sea...@lpl.arizona.edu> wrote: > On Dec 29, 2016, at 1:35 PM, Warner Losh <i...@bsdimp.com> wrote: > >>> A lot of code could have been changed while the ITU fiddled, e.g., Mac OS X >>> was launched i

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

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

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

On Thu, Dec 29, 2016 at 12:28 AM, Steve Summit wrote: > If we try to handle them better, two conclusions seem inescapable: > > 1. Posix-compatible time_t values will need to be smeared, >spreading the leap second out more gradually, to eliminate >sudden, unseemly jumps.

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

On Wed, Dec 28, 2016 at 2:21 PM, Brooks Harris <bro...@edlmax.com> wrote: > On 2016-12-28 02:29 PM, Warner Losh wrote: >> >> On Wed, Dec 28, 2016 at 10:33 AM, Brooks Harris <bro...@edlmax.com> wrote: >>> >>> The YMDhms count progression across the fi

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

On Wed, Dec 28, 2016 at 12:59 PM, Steve Summit <scs...@eskimo.com> wrote: > Warner Losh wrote: >> ...There's other systems that 'freeze' time during the leap second, >> only incrementing it by a tiny fraction for each gettimeofday call. > > Do you know which systems thos

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

On Wed, Dec 28, 2016 at 10:33 AM, Brooks Harris wrote: > The YMDhms count progression across the first Leap Second > (1972-06-30T23:59:60 (UTC)) as yielded by POSIX gmtime() is expected to be Or rather "something like the following," because POSIX doesn't say what happens

  1   2   3   4   5   6   >