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

Steve Summit wrote: >And this is eerily similar to the idea of using a struct >timespec with a nonnormalized tv_nsec field. For that matter, tm_sec==60 is the same class of trick too. We're just varying at which digit position we stuff in an out-of-radix value. >the UTC-aware

Re: [LEAPSECS] alternative to smearing

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 apologize if I

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

Tony Finch wrote: > Even though NTP can represent current UTC correctly, it often gets leap > seconds wrong. It does not give confidence that we will be able to > reduce bugs by teaching more code about leap seconds, when NTP cares > about time and gets it wrong, and most code cares much less. I

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

> On Jan 3, 2017, at 9:56 AM, Steve Allen wrote: > > Also not completely surprising was that we saw one of the pool.ntp.org > > servers (not Google) in use by our machines was clearly making a leap > smear available. You were pretty lucky then. It was

Re: [LEAPSECS] Leap seconds ain't broken

Tom Van Baak wrote: > That reminds me. I don't suppose we could get google, et al. to > rename it UTX instead of UTC? On a related note, there's the issue of knowing/confirming what kind of time an NTP server is giving you. (Stephen Colebourne was asking about this last month, too.) It'd be

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

zephram wrote: > It is sometimes useful to split an MJD value into integral and fractional > parts. The integral part is the Modified Julian Day Number (MJDN), > and I call the fractional part the Modified Julian Day Fraction (MJDF). > When applied to a leapless time scale [...] MJDF is always in

Re: [LEAPSECS] alternative to smearing

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

Re: [LEAPSECS] alternative to smearing

On Sun, Jan 1, 2017 at 4:29 PM, John Sauter < john_sau...@systemeyescomputerstore.com> wrote: > 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

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

On Tue 2017-01-03T17:46:34 +, Tony Finch hath writ: > I haven't mentioned the usual litany of NTP servers getting it wrong, Also not completely surprising was that we saw one of the pool.ntp.org servers (not Google) in use by our machines was clearly making a leap smear available. -- Steve

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

Warner Losh wrote: > We have a > specific legacy standard called POSIX that's causing all kinds of > issues that pop up when you least expect it I haven't mentioned the usual litany of NTP servers getting it wrong, including servers run by national time labs. It's pretty

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] Time math libraries, UTC to TAI

Martin Burnicki wrote: >Of course it would be great if there was an API call which executes fast >to yield a high performance, and returns a timestamp plus an associated >status code consistently, in an atomic operation. A read-only adjtimex() does return all of this information, at least on

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] Time math libraries, UTC to TAI

Sanjeev Gupta wrote: > 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 Not to forget the new tzdist protocol which can be used to update the leap second table dynamically across the network.

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

Steve Summit wrote: > The answer is that on a system with the mods installed, #1 > happens all the time for the system calls time(), gettimeofday(), > and clock_gettime(CLOCK_REALTIME). It does not happen for > adjtimex, on the assumption that that's what ntpd is using. > #2 happens only when you

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

Sorry for jumping in so late. Zefram wrote: > Warner Losh wrote: >> Except that it does advance... It plays the second twice, once with >> the pending leap set, and once with it cleared I though. The current implementation of ntpd just calls clock_gettime( CLOCK_REALTIME ) to retrieve receive

Re: [LEAPSECS] Leap seconds ain't broken

> There are subtleties to timekeeping. Removing leap seconds wouldn’t remove > the subtleties, rather it would promote them to significantly more > importance, perhaps “breaking” even more software and systems. > > Rob Now that several dominate vendors of computing are using smeared leap

[LEAPSECS] Leap seconds ain't broken

Hi Tony, > Come on, some of the rest of you must have seen some failure reports, > beyond just having to reboot your telescopes :-) To be clear, our telescopes were powered down for winter storms. And Steve is discussing a specific legacy telescope. Other telescopes I’ve been associated with

Re: [LEAPSECS] Leap seconds still broken

OpenNTPD failed to handle unsynchronized NTP pool servers gracefully: http://www.shellguardians.com/2017/01/openntpd-leap-seconds-and-other-horror.html Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet: Variable 4, becoming northwest 4 or 5,

Re: [LEAPSECS] Leap seconds still broken

http://mailman.nanog.org/pipermail/nanog/2017-January/thread.html * Hurricane Electric NTP servers missed the leap second * Cisco ASR 100X watchdog triggered reboot Come on, some of the rest of you must have seen some failure reports, beyond just having to reboot your telescopes :-) Tony. --

[LEAPSECS] The leap second on BT's speaking clock

"At the third stroke, the time from BT will be 12 o'clock precisely. beep beep (gap) beep" https://twitter.com/womump/status/815976395906174976 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Biscay: East 5 or 6, becoming variable 4. Slight or moderate.