[LEAPSECS] speeding up again?

-03-23 -210 µs 2023-03-30 -210 µs 2023-04-06 -200 µs 2023-04-13 -200 µs 2023-04-20 -190 µs 2023-04-27 -190 µs 2023-05-04 -180 µs 2023-05-11 -170 µs 2023-05-18 -160 µs -- Tony Finchhttps://dotat.at/ Fisher, German Bight: Cyclonic 3 to 5, becoming north or northwest 5 to 7, perhaps gale 8 later

[LEAPSECS] ITU-R WRC 2023 agenda

to listen to the report and not make any decisions about it? -- Tony Finchhttps://dotat.at/ Hebrides: Variable 3 at first in north, otherwise easterly or northeasterly 4 or 5. Moderate, occasionally slight in southeast. Showers. Good. ___ LEAPSECS mailing

Re: [LEAPSECS] King Charles

concluded. And that's certainly true in a practical sense, since decades ago the RGO ceased to maintain GMT as a form of UT1 or UT2. RGO stopped runing their PZT in 1984 and NPL took sole responsibility for the UK's time standards in 1985. -- Tony Finchhttps://dotat.at/ Faeroes: Cyclonic, becom

Re: [LEAPSECS] future access to solar time?

uot; your complaint does not make sense. The clock on the wall tells the time for social purposes, not for the position of the sun in the sky. -- Tony Finchhttps://dotat.at/ Isle of Man: West 5 or 6, backing south 3 or 4, then southeast 6 or 7 later. Mainly moderate, becoming slight for a time.

Re: [LEAPSECS] future access to solar time?

o find any specs for NMEA sentences that contain anything like UT1 or DUT1 or delta-T, but I expect they will be created before too long, as more GPS receivers support L5 signals. And there are other sources of UT1 like NIST's stunt NTP servers. -- Tony Finchhttps://dotat.at/ East Sole, Lundy, F

Re: [LEAPSECS] podcast from Orolia

get closer if things continue like this! -- Tony Finchhttps://dotat.at/ Lands End to St Davids Head including the Bristol Channel: West or southwest 2 to 4. Slight, mainly smooth in the Bristol Channel, becoming moderate later in west. Occasional rain or showers

Re: [LEAPSECS] Never mind DUT1, what happened to dX ?

me as the anomaly you pointed out. The LoD was creeping up: it was 24h-200µs Dec-Feb but in recent weeks it is down to 24h-210µs again... -- Tony Finchhttps://dotat.at/ Great Orme Head to the Mull of Galloway: South or southeast 6 to gale 8, decreasing 4 to 6 for a time. Slight or moderat

[LEAPSECS] leap seconds elsewhere

Some of you have already seen the recent discussion about leap seconds on the IANA tz mailing list. The thread starts at https://mm.icann.org/pipermail/tz/2021-April/030034.html John Sauter made some observations about Bulletin A which caught my interest, so I played around with the Bulletin A

Re: [LEAPSECS] Judah Levine of NIST

Steve Allen wrote: > Judah Levine has begun a multi-part essay > Everyday Time and Atomic Time I have been following this series via Judah Levine's author page, which has a relatively convenient list of the parts that have been published so far. (There doesn't seem to be an RSS feed, though.)

Re: [LEAPSECS] Leap second hiatus

John Sauter via LEAPSECS wrote: > 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,

[LEAPSECS] Leap second hiatus

I was inspired by last week's note from Michael Deckers to write some notes on the current LOD and UT1-UTC charts, https://fanf.dreamwidth.org/133823.html This is now being discussed on Hacker News with the usual topics such as leap hours and leap smear making an appearance

Re: [LEAPSECS] LEAPSECS Digest, Vol 153, Issue 3

Sanjeev Gupta wrote: > > I predict a scramble to SLS by the remaining Cloud Vendors when this > happens. Akamai, Amazon, Bloomberg, and Google have been smearing for years. I don't have a note for Apple or IBM or Oracle. Microsoft announced support for proper leap seconds in 2018, beautifully

[LEAPSECS] Bulletin C number 60

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 https://datacenter.iers.org/singlePlot.php?plotname=FinalsAllIAU2000A-LOD-BULA=9 Tony. -- f.anthony.n.finchhttp://dotat.at/

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

Warner Losh wrote: > > Have I forgotten any of the other details of leap seconds that are more > tribal knowledge than rigorously specified? The IERS Bulletins C state a value of UTC-TAI "until further notice". However the machine-readable files from IERS and NIST give an expiry date of a few

Re: [LEAPSECS] leap seconds in POSIX

Steve Allen wrote: > > http://hpiers.obspm.fr/eop-pc/index.php?index=C04=en > > ask to remove tidal variations Super, thanks! Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Kintyre to Ardnamurchan Point: West or southwest 4 to 6, increasing 7 or gale 8, backing south 4 or 5 later.

Re: [LEAPSECS] leap seconds in POSIX

Steve Allen wrote: > > The LOD effects are easier to see using the plots from the Paris > bureau of IERS by requesting to remove the predictable tidal > variations that basically look like noise on the second plot here. Do you have a link and/or instructions? I can't see how to get a chart like

Re: [LEAPSECS] leap seconds in POSIX

Steve Summit wrote: > * The leap second drought of 1999-2006 rather nastily coincided > with a gradual change in the computing industry from "nobody's > clocks are synchronized that well anyway, so a second here or > there doesn't matter" to the opposite. (But by the time we > realized

Re: [LEAPSECS] leap seconds in POSIX

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, because of the wide range of uses to which > time_t is put. In

Re: [LEAPSECS] Windows 10 time

Brooks Harris wrote: > On 2019-04-12 11:49 AM, Warner Losh wrote: > > > > Google + android might be able to get away with a change here, should > > Google decide to cope, but since they already just smear I doubt the > > idea would get enough traction to get the proper level of commitment > >

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

Warner Losh wrote: > How do they keep big Ben in sync these days? Eg, who decides it is running > fast or slow? I don't know about how they do it, but Frank King has written about how he keeps the University clock in Cambridge reasonably in sync: http://www.scy.org.uk/chimes.htm The Big Ben

Re: [LEAPSECS] Of stepping motors and leap seconds

Steve Summit wrote: > > I also have a detailed plan in my head -- I'm not sure I'll > ever manage to implement it -- for a computer-aided mechanical > pendulum clock. Reminds me of the Corpus Clock https://fanf.dreamwidth.org/96948.html aka the Chronophage. Tony. -- f.anthony.n.finch

Re: [LEAPSECS] the inception of leap seconds

Warner Losh wrote: > > Of course, Tom showed years ago having a different base frequency than > 9,192,631,770Hz would have fit the wobble of the earth better, but that was > settled in the late 50s / early 60s so we'd have to go farther back in time > to 'fix' that. Further than that :-) The

Re: [LEAPSECS] Windows Server 2019

Stephen Scott wrote: > Where is the standard for that? > Or at least some document that specifies that? The standard for leap seconds is ITU-R TF.460 https://www.itu.int/rec/R-REC-TF.460/en Tony. -- f.anthony.n.finchhttp://dotat.at/ disperse power, foster diversity, and nurture

[LEAPSECS] Leap smear at the IETF

There's a discussion about standardizing leap smear at the IETF. Carsten Bormann suggested the acronym “Smeared Leapsecond over twentyfour hours" — SLOTH. https://mailarchive.ietf.org/arch/msg/art/4LSfOGjp_Tb6yQdnhhvK5w3jucU Tony. -- f.anthony.n.finch http://dotat.at/ - I

Re: [LEAPSECS] Amazon canonizes leap smear

Amazon have been doing leap smear for their own systems for 2.5 years https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ What's new this week is Amazon making their NTP service available to their AWS customers. Tony. -- f.anthony.n.finch

Re: [LEAPSECS] leap second roundup 2017

Poul-Henning Kamp wrote: > > If you magically got all the paperwork changed, you would see a > repeat of the GMT fiasco, where UTC is still called "GMT" 50 years > later... GMT has had many definitions over its lifetime, including a 12h step, so I'm not convinced that

Re: [LEAPSECS] BBC radio Crowd Science

Warner Losh wrote: > On Tue, Jan 31, 2017 at 12:13 PM, Brooks Harris wrote: > > > > Of course, as we've been discussing, the specifications > > leave room for interpretation. > > Correct. They don't even talk about an offset. They just say that a > leap second

Re: [LEAPSECS] BBC radio Crowd Science

Michael.Deckers. via LEAPSECS <leapsecs@leapsecond.com> wrote: > >On 2017-01-30 13:06, Tony Finch wrote: > > > It's tricky. Bulletin C is pretty clear about when it thinks TAI-UTC > > changes: > > > >from 2015 July 1, 0h UTC, to 2017 January 1 0h U

Re: [LEAPSECS] BBC radio Crowd Science

Tom Van Baak wrote: > > it doesn't make much sense to have a defined delta for the last UTC > > second of 2016. > > No. > > So I see no reason or need to pick on "delta" as being in an > indeterminate state during a leap second. We have enough exceptions with > leap second

Re: [LEAPSECS] Compact encoding of the leap seconds list

Tony Finch <d...@dotat.at> wrote: > The plain text version is > > 6+6+12+12+12+12+12+12+12+18+12+12+24+30+24+12+18+12+12+18+18+18+84+36+42+36+18+5? I've changed the binary version to optimize for the common case of positive leap seconds some multiple of 6 months apart, which ma

Re: [LEAPSECS] alternative to smearing

Zefram wrote: > ("Julian epoch" is a somewhat confusing term: it refers to a linear > count similar to JD, but scaled by a factor of 365.25 such that over the > long term it is frequency locked to the years of the Julian calendar, > and with zero point chosen such that Julian

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

Hal Murray wrote: > > Anybody know when NTP supported it's first leap second? I think RFC 958 (Sept 1985) was the first NTP RFC, and it includes support for leap seconds. The earlier network time RFC's lack leap seconds. I don't know at what point after RFC 778 (April

Re: [LEAPSECS] alternative to smearing

Daniel R. Tobias wrote: > > 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. That's a very good

[LEAPSECS] Compact encoding of the leap seconds list

The plain text version is 6+6+12+12+12+12+12+12+12+18+12+12+24+30+24+12+18+12+12+18+18+18+84+36+42+36+18+5? There's a compressed binary version of the same idea which is 24 bytes. Details at http://fanf.livejournal.com/148164.html Tony. -- f.anthony.n.finch http://dotat.at/

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

Martin Burnicki wrote: > > If upstream servers aren't aware of the leap second and don't insert it, > then our server will see that its time is off by 1 sec after it has > (correctly) inserted the leap second. So a few minutes after the leap > second our server will

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

Martin Burnicki wrote: > > Please note that NTP servers not necessarily need to be providers for > leap second files. There are some well known sites which provide this > file, and the NTP software package from ntp.org comes with a script > which can be used to

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

Hal Murray wrote: > > Suppose I want to wait until some UTC date/time more than 6 months in the > future. A library routine doesn't have to compute how many seconds to wait > right now. It can break it down into chunks. Wait until the current leap > file expires, then

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

Martin Burnicki <martin.burni...@burnicki.net> wrote: > 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 a

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

Re: [LEAPSECS] Leap seconds still broken

Some vague reports of leap-second-related CDMA network outages (note, not load related since the leap second was several hours before new year in the USA) https://news.ycombinator.com/item?id=13294747 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn-- zr8h punycode

Re: [LEAPSECS] Leap seconds still broken

Another example of software crashing when time seems to go backwards: https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns/ Tony. -- f.anthony.n.finch http://dotat.at/ - I xn-- zr8h punycode ___

Re: [LEAPSECS] Leap seconds still broken

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 got it wrong - http://www.spinellis.gr/blog/20170101/ Tony. --

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

Warner Losh wrote: > > There's also other year reckonings for other cultures that produce > very long results depending on what you tag as "a year" The Jewish calendar uses intercalary months, so a leap year can be 385 days.

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

Brooks Harris 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

Re: [LEAPSECS] private smear goes public

Brooks Harris wrote: > Can you explain that copyright issue further? I was under the impression > Bulletin C and related from IERS were public. There was a discussion of this issue on the tz list in February: http://mm.icann.org/pipermail/tz/2016-February/023171.html Tony.

Re: [LEAPSECS] private smear goes public

Poul-Henning Kamp wrote: > > I don't know what the effective latency is from IERS -> TZdata -> distros -> > releases -> users -> computers, but 6 months is only going to be enough > if everybody pays maximum attention *EVERY* *BLOODY* *TIME*. The cascade actually goes IERS

Re: [LEAPSECS] A standard for leap second smearing

Steve Summit wrote: > > Me, I'd very much rather *not* add this sort of thing to (say) > NTP, because NTP doesn't have a problem with leap seconds. Except that every leap second is screwed up by a large proportion of NTP servers... Tony. -- f.anthony.n.finch

Re: [LEAPSECS] A standard for leap second smearing

Steve Summit wrote: > > I think there are aspects of the implementation of any smearing > that are maybe being glossed over. I think it's important to > distinguish pretty carefully between three distinct "clocks", > or views of time: > 1. The time exchanged between machines

Re: [LEAPSECS] Bloomberg announced its smear

Brooks Harris wrote: > > The short of it is Windows behave just like POSIX as far as I can tell, > except its epoch, represented as struct FILETIME, is 1601-01-01T00:00:00 > (UTC-like), which is, apparently the COBOL epoch (I didn't track down > the references on that). It

Re: [LEAPSECS] Bloomberg announced its smear

Brooks Harris wrote: > Note too the discussions of how they increment the smear so as to > not upset some receiver's PPL. Is anyone other than Google doing that? All the other smears I recall (UTC-SLS, Amazon, Bloomberg) have been piecewise-linear. (It isn't clear to me

Re: [LEAPSECS] Leap seconds win an IgNobel prize!

David Malone wrote: > Must have just been a citation? I don't see it mentioned in the final list. Ah, I now see that Eric Maskin was one of the Nobel prize winners helping out with the prize-giving. Oh well. Tony. -- f.anthony.n.finch http://dotat.at/

[LEAPSECS] Leap seconds win an IgNobel prize!

The full details should be posted at http://www.improbable.com/ig/winners/ but in the mean time (as it were) here is a teaser from their live-tweeting of the awards ceremony. (This is not the best award of the year, by a long shot!) https://twitter.com/improbresearch/status/779102825750097920

Re: [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

Steve Summit wrote: > > I think about Posix time_t in three ways: > > 1. It's utterly broken, in that it claims to be UTC, but fails to >handle the one facet that distinguishes UTC from other timescales. (It's actually UT(unspecified) but it's in denial) > 2. It's wildly

Re: [LEAPSECS] Leap second to be introduced at midnight UTC December 31 this year

Tom Van Baak wrote: > > Isn't the limit on DUTC 0.9s? So you can't have a leap second at the end > > of the month when | UT1 - UTC | < 0.1 > > Right, for LSEM to work, you'd have to extend the DUT1 limit a bit > beyond 0.9s. Historically, DUT1 has changed from 0.1s to 0.5s

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Tom Van Baak wrote: > > > Does your proposal allow for a Zero leap second > > Nope, LSEM avoids the zero leap second situation. That's the idea: to > always have a leap second. Either an add or a delete, at the end of > every month. The beauty is that it wouldn't violate how

Re: [LEAPSECS] leap seconds schedule prior to 1972

John Sauter wrote: > > I referenced your web site in my article, and used your schedule of > leap seconds for 1958 through 1971.  In effect, I am extending your > work back to -1000. Oh cool, thanks :-) I completely missed that when skimming your paper!

Re: [LEAPSECS] leap seconds schedule prior to 1972

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 complete paper is available on my web site, at  > >

Re: [LEAPSECS] Bong

Tony Finch d...@dotat.at wrote: Just heard the midnight (+0100) chimes from Big Ben on Radio 4 FM. The bong was one second late, so I gather they already applied the leap second. Or my DAB radio also buffers horribly even in FM mode... Radio not to blame judging by the 7 pips :-) Tony

Re: [LEAPSECS] EBML: yet another date format?

Hal Murray hmur...@megapathdsl.net wrote: POSIX uses 32 bits of seconds and 32 bits of nanoseconds. POSIX doesn't specify the size of time_t. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle, Faeroes: Southwest 4, backing southeast 5 or 6 later. Moderate, occasionally

Re: [LEAPSECS] Google, Amazon, now Microsoft

On 30 May 2015, at 23:05, Tom Van Baak t...@leapsecond.com wrote: I understand that's why JD rolls over at noon instead of midnight. But, for the other 7 billion people on the planet, it's nice that the calendar, and local legal time, and even MJD rolls over at midnight instead of noon. And

Re: [LEAPSECS] Google, Amazon, now Microsoft

On 31 May 2015, at 03:28, Rob Seaman sea...@noao.edu wrote: DST changes at 2am in the US and 1am in the EU. That is 01:00 UTC which is 02:00 standard / 03:00 summer time for most of the EU. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Hebrides: Southwest 5 or 6, becoming

Re: [LEAPSECS] Google, Amazon, now Microsoft

On 30 May 2015, at 06:52, Poul-Henning Kamp p...@phk.freebsd.dk wrote: The opererative detail is this: Microsoft has determined that clocks on tens of thousands of servers globally running Azure should switch to the leap second at midnight in the time zone where they are based.

Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News

Eric R. Smith ersm...@hfx.eastlink.ca wrote: it would follow that a POSIX compliant system has to know how many days have elapsed since the epoch, i.e. it needs to have some kind of access to the sky. Only to the extent that its owners want it to know the correct time. Tony. --

Re: [LEAPSECS] financial markets

Poul-Henning Kamp p...@phk.freebsd.dk wrote: What's going on here is that the biggest financial hub in the USA doesn't know the difference between UTC and GMT. That's because GMT (the official time promulgated by the RGO for civil use in the UK) has been the same as UTC since 1972 or before.

Re: [LEAPSECS] Vive la différence! (was Re: financial markets)

GMT is the British national timescale. It hasn't been Greenwich nor Mean Time for decades, so what it is called has nothing to do with its technical details. It has been and will remain synchronised to UTC or whatever international time standard replaces it. GMT has never had a stable technical

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

Brooks Harris bro...@edlmax.com wrote: On 2015-03-07 03:01 PM, Steve Allen wrote: I would say that the intent NTP and POSIX is to correspond to civil time in contemporary use. Therefore, for dates before 1972-01-01 NTP and POSIX are counting seconds of UT. This paragraph in your email

Re: [LEAPSECS] My FOSDEM slides

Martin Burnicki martin.burni...@meinberg.de wrote: I agree, but as I've tried to point out above I think a better project design would have been to use TAI instead of GPS time. PTP works natively with TAI, and you can easily convert between he two scales. I don't understand this paragraph.

Re: [LEAPSECS] final report of the UK leap seconds dialog

Ian Batten via LEAPSECS leapsecs@leapsecond.com wrote: An obvious example is the UK. Our legal time is GMT with DST, usually taken to be UT1 with DST. Our de facto civil time is UTC with DST, and over the years this has become more and more ingrained (the Greenwich pips on the hour on

Re: [LEAPSECS] final report of the UK leap seconds dialog

Kevin Birth kevin.bi...@qc.cuny.edu wrote: In my view, in a strictly Biblical perspective, the problem is with mean time not with leap seconds. I tend to go further and argue that people don't like to base their days on noon. DST is a bodge to recover a bit of seasonal movement to follow

Re: [LEAPSECS] Bulletin C and all that

Brooks Harris bro...@edlmax.com wrote: Agreed. Its really easier to implement end of (any) month. Checking for June and December just risks bugs and is not comprehensive anyway. But there have been real bugs due to leap indicators remaining set too long, leading to bogus leaps at the end of

Re: [LEAPSECS] Bulletin C and all that

Rob Seaman sea...@noao.edu wrote: The issue is policy versus implementation. The standard allows the end of every month, so any implementation (whether DNS or otherwise) should do likewise. The IERS June / December policy is appropriate for the current epoch - i.e., oversamples the UTC

Re: [LEAPSECS] DNS examples

Steffen Nurpmeso sdao...@yandex.com wrote: leap year calculations do not work correctly until the final introduction of the gregorian date, 1582-10-15. I think that should be first - the Julian to Gregorian migration did not complete until the 1900s. Tony. -- f.anthony.n.finch d...@dotat.at

Re: [LEAPSECS] stale leap second information

Warner Losh i...@bsdimp.com wrote: On Jan 16, 2015, at 3:37 AM, Tony Finch d...@dotat.at wrote: $ dig +short leapsecond.dotat.at | sed 's/:6:/:06:/' | sort 1972:06:30::23:59:60 …. 2012:06:30::23:59:60 2015:06:30::23:59:60 I’m *loving* this. Glad you like it, but caveat! I am

Re: [LEAPSECS] stale leap second information

Harlan Stenn st...@ntp.org wrote: DNSSEC needs accurate time (just to state what I expect is obvious). Yes (though in this case accurate means within several minutes of the correct time). I need to write up a proper description of my idea for bootstrapping time and DNSSEC. So far I have only

Re: [LEAPSECS] stale leap second information

Poul-Henning Kamp p...@phk.freebsd.dk wrote: However, I think it is a loosing strategy to send an ever longer list of addresses, it's only a matter of time before some random piece of DNS software does something stupid (again). Yes, the basic response size is 776 bytes so it is likely to have

Re: [LEAPSECS] stale leap second information

Speaking of stale information, I am amused by the summary box on the right-hand side of http://www.bipm.org/en/bipm-services/timescales/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Shannon, Rockall, Malin: Northwest backing west 6 to gale 8. High becoming very rough. Squally

Re: [LEAPSECS] stale leap second information

$ dig +short leapsecond.dotat.at | sed 's/:6:/:06:/' | sort 1972:06:30::23:59:60 1972:12:31::23:59:60 1973:12:31::23:59:60 1974:12:31::23:59:60 1975:12:31::23:59:60 1976:12:31::23:59:60 1977:12:31::23:59:60 1978:12:31::23:59:60 1979:12:31::23:59:60 1981:06:30::23:59:60 1982:06:30::23:59:60

Re: [LEAPSECS] Improvements since 2012

There were false leap second events six months ago. I didn't hear of any coinciding with the new year. See the brief thread starting at https://pairlist6.pair.net/pipermail/leapsecs/2014-July/005130.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at On 11 Jan 2015, at 21:17,

Re: [LEAPSECS] the big artillery

Sanjeev Gupta gha...@gmail.com wrote: As a general rant, I still complain that (roughly) year 8 to year 12 of my schooling required me to learn stuff in physics, and then the next year, often the same teacher would tell me what I had learnt was wrong, and this was the correct way.

Re: [LEAPSECS] the big artillery

So when I was googling around for more information about what paper timescales the BIPM publishes, I found this: http://iag.dgfi.badw.de/fileadmin/IAG-docs/Travaux2013/08_BIPM.pdf which says: The algorithm used for the calculation of time scales is an iterative process that starts by

Re: [LEAPSECS] the big artillery

Alex Currant via LEAPSECS leapsecs@leapsecond.com wrote: Despite what the recommendations might say, I think the TA(k) reported in the Circular T are not efforts by lab K to realize TAI, since it is hard to imagine how a lab could get a different offset attempting to realize TAI from

Re: [LEAPSECS] the big artillery

Zefram zef...@fysh.org wrote: Warner has said things like the UT1 second is 1e-9 different from the SI second. That statement implies that the UT1 second is a physical quantity, with dimensionality of proper time, which can thus be measured using the SI second as a unit. The UT1 second is

Re: [LEAPSECS] the big artillery

Poul-Henning Kamp p...@phk.freebsd.dk wrote: minutes and seconds are fractions of 60 and have been so since babylonian times for minutes and since 13-mumble for seconds. The etymology is actually helpful in this case rather than misleading as etymologies so often are. minute is short for pars

Re: [LEAPSECS] the big artillery

Gerard Ashton ashto...@comcast.net wrote: For example, the Standards of Fundamental Astronomy subroutine iauDat provides the delta between TAI and UTC, and the source code comments say UTC began at 1960 January 1.0 (JD 2436934.5) and it is improper to call the function with an earlier date.

Re: [LEAPSECS] the big artillery

Steve Allen s...@ucolick.org wrote: By the way, which USNO table is that? http://maia.usno.navy.mil/ser7/tai-utc.dat Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southwest Forties, Cromarty, Forth, Tyne, Dogger: Northerly 4 or 5, becoming variable 3 or 4, then southerly 5 to 7

Re: [LEAPSECS] Changing the name of UTC

Gerard Ashton ashto...@comcast.net wrote: Every time scale I've ever heard of has a projection into the past, before the time scale was fully defined. I am not aware of any consensus definition for proleptic UTC, unless you do the fully accurate model going from UT(2?) through the rate shifts

Re: [LEAPSECS] Do lawyers care (know) about leap seconds?

Ian Batten via LEAPSECS leapsecs@leapsecond.com wrote: I can't think of any (country, religion) pairs where the religion has a deep embedding of solar time and the country is sufficiently in hock to the religion that it would alter its civil timescale to suit. There were some relics in the tz

Re: [LEAPSECS] Do lawyers care (know) about leap seconds?

Steffen Nurpmeso sdao...@yandex.com wrote: This approach would satisfy all parties: humans can continue to enjoy the cultural achievement of a clock that exactly describes their home planet, and engineers can use TAI for satisfying airplane schedule calculations for businessmen. No. Planning

Re: [LEAPSECS] Do lawyers care (know) about leap seconds?

Kevin Birth kevin.bi...@qc.cuny.edu wrote: For most of human history there were no global time standards. In Europe, many city states had their own distinctive times--Nuremberg Time, Italian Time, Bohemian Time . . . But before there were standard times there were standard representations of

Re: [LEAPSECS] Do lawyers care (know) about leap seconds?

Steffen Nurpmeso sdao...@yandex.com wrote: I cannot imagine you wouldn't agree that having CLOCK_TAI (and CLOCK_LEAPDRIFT) make things easier. For most purposes we need civil time, and a TAI clock doesn't solve the problem that civil time is too difficult to get right. Tony. --

Re: [LEAPSECS] a big week for leaps at SG7 and WP7A

Stephen Colebourne scolebou...@joda.org wrote: I can safely say from my experience there, that if leap seconds are abolished it will not be with the British peoples approval. I got the impression from the emphasis on non-technical aspects that the consultation was designed to get that answer.

Re: [LEAPSECS] Leap second relationship to ISO 8601

Poul-Henning Kamp p...@phk.freebsd.dk wrote: For example, a date and time in New York City might be represented as 2014-07-04T00:00:00-05:00 [...] The former is incorrect. Incorrect where? The UTC offset in New York at that time was not -05:00 so that cannot be a time in New

Re: [LEAPSECS] Leap second relationship to ISO 8601

Poul-Henning Kamp p...@phk.freebsd.dk wrote: However for events in the future (meetings etc.) you need to record a time and a place, because the UTC offset and time zone rules are not predictable. The main problem here is to get people to give you enough information in the first place.

Re: [LEAPSECS] Leap second relationship to ISO 8601

Brooks Harris bro...@edlmax.com wrote: Its important to note 8601 is silent on how Daylight Savings Time is handled and provides no recommendation of how it might be indicated or represented. ISO 8601 does not represent daylight saving nor time zones. Looking closely you'll find there is no

Re: [LEAPSECS] Leap second relationship to ISO 8601

Gerard Ashton ashto...@comcast.net wrote: For example, if one wishes to use the format 2014-08-24, is it mandatory that the day begin at midnight according to some unspecified local time? ISO 8601 does not specify the time zone alignment of calendar days. It allows you to identify a date in

Re: [LEAPSECS] Leap second relationship to ISO 8601

Rob Seaman sea...@noao.edu wrote: A date is an integer. A timestamp is a real. (however represented) And this is a great example of why UTC is usually implemented incorrectly. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly

Re: [LEAPSECS] there was no leap second

Steve Allen s...@ucolick.org wrote: but at least one server saw its NTP server say there was https://twitter.com/theckman/status/483767831897440256 https://twitter.com/theckman/status/483785260920872960 And http://mailman.nanog.org/pipermail/nanog/2014-July/068004.html Tony. --

  1   2   3   >