Re: [LEAPSECS] UT1 offset
Warner Losh writes: > Still, even 50m can be a lot if you are flying over a narrow mountain pass > in a plane that can't just fly super-high above it... Celestial navigation requires you to be able to see something through the windows. If that is an option the sane pilot would look at the terrain. Also: When celestial navigation is possible, most vessels travel a lot further than 50 meters during the time it takes to make a measurement of the necessary precision. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] prep for WRC 23
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 no less > than 100 seconds, taking into account the constraints of the > technological systems > expected to be used to disseminate this value, " You're right, I misread that. They /really/ dont want to ever see a leapsecond or leapminute, do they ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] prep for WRC 23
Resolution 655 was approved by the WRC plenary, reportedly in a very routine manner and with with neither drama nor long speeches. The full text of the resolution is on page 399 of the provisional final acts: https://www.itu.int/dms_pub/itu-r/opb/act/R-ACT-WRC.15-2023-PDF-E.pdf My Tl;dr version of the resolution is: Timescales are not spectrum regulation, we defer to CPGM and BIPM on that, but will handle any fall-out as far as radio signals go. Please keep DUT1 less than 100 seconds. Then BIPM then issued this press release: https://www.bipm.org/en/-/2023-12-12-wrc-dubai Which I read as death notice for the leap-second, with further details of the funeral to announced after CPGM's meeting in 2026. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] speeding up again?
Tom Van Baak writes: > Steve, > > > We can probably put a lot of the blame onto El Niño > > That sounds plausible but I'm suspicious of quick and simple explanations. I dont think the primary El Niño phenomena involves enough mass transport to measurably change the angular momentum. It is mostly just a vertical inversion phenomena, which changes the evaporation from the sea surface. It has far ranging secondary effects, but those are mostly orthogonal to the rotation, so their effect is also attenuated. What I wonder is if anybody has done the angular rotation math on major forrest fires ? They convert a lot of trees from rigidly rotating surface mass to gasses, but I have no idea what the total incinerated mass might be... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Multidecadal variation of the Earth’s inner-core rotation
Brooks Harris writes: > Multidecadal variation of the Earth's inner-core rotation Thanks a LOT! If I read this right, 1955 was the worst possible time for IAU define the second ? In 1955, purely by accident, the inner core was at the same stage of it's multidecal oscillation (Extended data, fig 7), as when Newcomb made the astronomical observations in the 1890'ies on which IAU based their definition of the second, and so, presumably, all the contemporary LOD observations, moon camera and all that, gave results close to Newcombs. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Inside GNSS published an update of my CGSIC talk
Warner Losh writes: > So my first choice is > always 'none, cope with shifting civil time on the scale of centuries' but > my second choice is 'schedule for the long-term average and don't worry > about going > 1s' . The long-term average used to be "a leapsecond every 18 months - give and take" and based on that I have previously also advocated for the "announce leap-seconds at least 10 years in advance" idea. We have now seen "patently geophysically impossible" negative leapseconds become even money in slightly less than two years. The nearest we get to a scientific explanation for that, is hand-waving in the general direction of "climate change", even though not even the most dire climate models move enough water around. So do we in fact even have a "long-term average" to steer towards right now ? I expect we would end up repeating the "Oops too little - Oops too much" steering we saw back in the rubber-second years. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] ITU-R WRC 2023 agenda
Tony Finch writes: > It is almost a year until the world radiocommunication conference, but to > my surprise there is already an agenda. (I am also amused that there is a > pre-meeting meeting in April) This is not unusual for technical organizations where governments votes, because public hearings, legislatie action, appropriations or a referendum might be required, to settle how the country should vote. You will see similar slow-motion in organizations of maritime and air traffic for instance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap minute or hour
Demetrios Matsakis via LEAPSECS writes: > Another one, about traffic accidents, showed a whole bunch of wiggles = > over a year, and said that one of those coincided with a DST switch. That one is actually pretty well documented in Europe, but most of the extra accidents are wildlife-strikes. Transpires that wildlife adapts to our rythm of life, but do not get the memo that tomorrow rush-hour will be one hour different. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap minute or hour
Clive D.W. Feather writes: > Stick with what people are used to, which is (mostly) shifts of an hour. Yeah, well... That's the disadvantage of handling it at the political level: There is no discernible upper limit to how stupid politicians can be about timezones. Apart from 15 minute and 30 minute deltas, there is a clear tendency to make changes with far too short notice. The good news is that stupid timezone decisions can only hurt the geographical area controlled by the politicians, so there is a feedback-mechanism in place. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap minute or hour
Steve Allen writes: > On Mon 2022-11-14T21:22:27+0000 Poul-Henning Kamp hath writ: > > I doubt the will manage to convince the other 99+% to do something > > as deranged as a leap-minute. > > > Thanks to timezones and DST, less than 1% of the worlds population > > live where mean solar time is correct to a minute. > > The reason we got leap seconds in the first place is that one country > changed its law so that the rubber/elastic seconds of original UTC > became illegal. Steve please drop the conspiracy theories. We got leap-seconds because a second of variable duration was useless for several rapidly developing technologies, from atoms to space via the laser and digital telecom. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap minute or hour
Eric Scace writes: > If a leap minute were to be added/removed at some future date > when UTC became significantly more that 30 seconds different from > mean solar time, [...] Thanks to timezones and DST, less than 1% of the worlds population live where mean solar time is correct to a minute. I doubt the will manage to convince the other 99+% to do something as deranged as a leap-minute. Full hour shifts, on the other hand, can be done merely by changing the time-zone, and they can be done through the normal political process, aligned to recognized borders. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Alanna Mitchell in NYT
Joseph Gwinn writes: > And the likelihood is that software written (at great expense) to > prepare for what will be in 30 years from now will be a dead loss, > outmaneuvered by technological and scientific progress. I would never attempt that. My point is more that you get a lot of mileage out of the KISS principle when it comes to designing standards and APIs. And "86400 seconds per day" is a lot more KISS than "86400±1 seconds per day" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Alanna Mitchell in NYT
Joseph Gwinn writes: > > I believe I recently saw PHK ruminating that forward compatibility in > > computing is at least as important as backward compatibility because > > the next 30 years of software need to know where they are going. The other side of my arguent is that more software will be created in the next 30 years than were created in the previous 30 years, so if you want to optimize for more code being correct, you need to concentrate on getting it right for the future, not for the past. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Alanna Mitchell in NYT
Warner Losh writes: > I'm happy to see this... I talked to Judah 20-odd years ago about this and > he was hopeful then. And with a 2035 deadline we might just get to see if our implementations of negative leap-seconds work before it is too late. Yes, it should have happened 20 years ago. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] article for Metrologia
Joseph Gwinn writes: > On Sun, 30 Oct 2022 07:08:25 +0000, Poul-Henning Kamp wrote: > The other ting to keep in mind is the immense existing codebase of > unix kernels et al, not to mention application code depending on > those kernels. This is the mistake we IT-people keep doing again and again: Forwards compatibility is /far/ more important than backwards compatibility. For one thing, there is a finite amount of code to be backwards compatible with, whereas the amount of future code is practically infinite. Back in 1990 we had what, 30 years of legacy code for a quite small industry ? Now we have that /and/ another 30 years of code produced by a vastly larger industry. "Immense existing codebase" ... not so much. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] article for Metrologia
Warner Losh writes: > The problem is time_t can't encode a leap second uniquely, but leap seconds > had been a thing for ~20 years when the first POSIX standards came out. It > was more of a willful choice to disregard them entirely as a simplification > than lack of clairvoyance. I would say it is even worse: POSIX was simply an administrative exercise to rapidly rubber-stamp the AT manuals to define a common baseline "before UNIX fragmented". The "technical review" of POSIX amounted to "The seven dwarfs" comparing it to their own manuals, to ensure that their "me-too" UNIX could be made compliant with minimal effort. Even if it had been a very convincing proposal, any change as fundamental as time_t, be it leap-seconds or 64 bits, would have been instantly shot down, entirely on the grounds that "The seven dwarfs" didnt have the in-house UNIX-skill to implement the change. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] fb/meta join the leap second haters
Steve Allen writes: > On Tue 2022-07-26T23:33:15+0000 Poul-Henning Kamp hath writ: > > 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 did we not notice that earlier ? > > even better is the view from the Paris bureau at > https://hpiers.obspm.fr/eop-pc/index.php > which at the moment is showing a Vondrak filtering But only from 2000 forward, would be interesting to see it for the full data-set. > The rotation of the earth's crust started accelerating right when > the CCIR decided that we should start using leap seconds. Yes, it does indeed look like 1970-ish is a turning point, but it is always dangerous to declare such to close to the end of the data... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] fb/meta join the leap second haters
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 did we not notice that earlier ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Never mind DUT1, what happened to dX ?
Steve Allen writes: > On Mon 2022-03-07T06:33:31+0000 Poul-Henning Kamp hath writ: > > I looked at the Bulletin A plots this morning to see how DUT1 is > > developing, but then I noticed the 'dX' term plot: > > > > > > https://datacenter.iers.org/singlePlot.php?plotname=BulletinA_All-DX=6 > > > > What happened in late 2019 ? > > 2019 October is when USNO had to take their machines offline due to > new security requirements. But why would that affect only the dX plot ? > Those artifacts do not show at the ObsPM site > https://hpiers.obspm.fr/eop-pc/index.php?index=analysis=en I'm not talking about the two spikes, I'm talking about the oscillation disappearing, and that seems to be in all the data sources ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Never mind DUT1, what happened to dX ?
I looked at the Bulletin A plots this morning to see how DUT1 is developing, but then I noticed the 'dX' term plot: https://datacenter.iers.org/singlePlot.php?plotname=BulletinA_All-DX=6 What happened in late 2019 ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] "GRD effects"
This article on RealClimate about sea-level predictions: https://www.realclimate.org/index.php/archives/2021/05/why-is-future-sea-level-rise-still-so-uncertain/ almost casually mentions: * gravitational, rotational and deformational (GRD) effects and then proceeds to say very little more about it: Furthermore, one important factor in how WAIS will affect sea level is how fast the lithosphere will respond to changes in the ice loading (part of the GRD effects mentioned above). Googling tells me that the "GRD" concept was introduced in 2019 by this paper: https://www.researchgate.net/publication/332757282_Concepts_and_Terminology_for_Sea_Level_Mean_Variability_and_Change_Both_Local_and_Global I guess that's where the geophycics of "missing" or even negative leap-seconds live now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Where leap-seconds went ?
Polar Drift in the 1990s Explained by Terrestrial Water Storage Changes: https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2020GL092114 They dont actually mention leap-seconds though... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LOD reaches 0 s/d
> 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 seconds for quite a while. Unless of course we get close enough to a negative one, that people are *really* going to freak out. Hands in the air: Who here besides Warner and me has ever tried to test handling of negative leap-seconds ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 153, Issue 3
Ask Bjørn Hansen writes: > > But still eyeballing the LOD curve, I'd give it 50/50 before 2038. > > > Am I oversimplifying if I'm hoping that means we might not have > any leap seconds for ~18 years? > > If that's the case - no leap seconds for two decades and > then the first one will be the kind we haven't tried before? That would be fun, wouldn't it ? :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 153, Issue 3
Demetrios Matsakis writes: > rise, and the Earth gets rounder. But the same people who do that math > say today's warming, dramatic as it may be for our biosphere, is > too little for this particular effect. People have gotten that stuff > wrong since George Darwin, though. I think the basic redistribution of water will be a wash, pun intended, for instance the water in the Greenland icecape gets lowered some kilometers, but a lot of that water will end up in the central pacific, right on the Equator, due to the local gravitation. If we get a negative leap, it will be because of "noise", both from whatever is going on under our feet, but possibly also from climate change transient phenomena, the crust under Greenland bouncing up under lighter load, ocean current modulations or, more unlikely reconfigurations. But still eyeballing the LOD curve, I'd give it 50/50 before 2038. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 153, Issue 3
> I haven't re-run the statistics. I'd still bet that the > average LOD stays constant at its latest several-year average value for > the next ten years, meaning no negative leap second. But I'd > lower the ante :) If we keep leap-seconds, I would bet even dollars (ie: a 50/50 probability) on at least one (and probably only one) negative leap-second before the 2K38 time_t roll over. This is an unscientific hunch, but based on scientific data: I see far more co-trending in DUT1 and climate model result than I am comfortable with. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C number 60
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 > > https://datacenter.iers.org/singlePlot.php?plotname=FinalsAllIAU2000A-LOD-BULA=9 Is it time for a LEAPSECS betting pool on when the first negative leap second is deleted ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug
In message <7bca6012-4303-68e7-bd57-85bf881fd...@burnicki.net>, Martin Burnicki writes: >UTC correction parameters: > t0t: 2057|405504.000, A0: -9.31323e-10 A1: -2.66454e-15 > WNlsf: 2185, DN: 7, offs: 18/18 >Last leap second eventually at UTC midnight at the end of Sat, 2021-11-27 That is similar to what my old Oncore UT reports: Leap second info: 2021-11-28 00:00:00 NONE 77714184 seconds (899 days) from now -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC
In message <20190116085619.ga23...@ucolick.org>, Steve Allen writes: >On Wed 2019-01-16T08:31:19+0000 Poul-Henning Kamp hath writ: >> In message <20190115205243.gb25...@ucolick.org>, Steve Allen writes: >> >That evokes a challenge for all time nuts that I can make based on >> >reading Bulletin Horaire. >> > >> >What is the epoch that was used for TAI? >> >> Isn't that the same one Loran-C used ? 1958-01-01 00:00:00 GMT ? > >Nope. > >The epoch of TAI, and LORAN, and GPS is 1961-01-01T20:00:00 UT2. >Or maybe 1961-01-00 UT2. > >That is when the atomic time scale was set to a specified value. But the specific value they set was not zero in 1961-01-01T20:00:00 UT2, they set it so it would have been zero at 1958-01-01 00:00:00 GMT -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC
In message <20190115205243.gb25...@ucolick.org>, Steve Allen writes: >On Tue 2019-01-15T12:34:11-0800 Gary E. Miller hath writ: >> Yes, and no. time_t is just seconds since an epoch. Which epoch >> is not well defined. The epoch may well be anything. See "man difftime". > >That evokes a challenge for all time nuts that I can make based on >reading Bulletin Horaire. > >What is the epoch that was used for TAI? Isn't that the same one Loran-C used ? 1958-01-01 00:00:00 GMT ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC
In message <20190115123411.44a0c...@spidey.rellim.com>, "Gary E. Miller" writes : >> But the underlying time_t cannot represent leap seconds, can it? > >Yes, and no. time_t is just seconds since an epoch. Which epoch >is not well defined. The epoch may well be anything. See "man difftime". I was lucky enough to share breakfast with Dennis Richie at the USENIX ATC in New Orleans in 1998, and we talked a lot about the history and future of /dev and timekeeping. Originally time_t, which wasn't called that yet, was only 16 bits, and the epoch was whenever you booted the system and because the machines lacked memory management hardware, "rollover was usually not a problem". >time_t dates to the first edition of "Unix Programmer's Manual, November >3, 1971". No timezone or other basis is given for time_t. They just >said "system time". The first leap second was in 1972! time_t never >caught up. >In 1973, just after the third edition, time_t was pegged to GMT. > >According to wikipedia, GMT is mean solar time, not UTC. The seconds >are not the same length, and no leap seconds: Wrong. At the time GMT was what people had always called UTC, and there were no difference between them. >Some long time after that the doc changed from GMT to UTC, but the code >did not. time() returns a time_t which pretends to be UTC, but ignores >leap seconds. From a current "man time": And that was simply how AT telephone network decided to handle leapseconds: There were far too many time keeping devices installed throughout the network for anybody to contemplate implementing leap seconds on them. Most of them didn't keep time that well anyway. I have not yet been able to pinpoint the first UNIX computer which had hardware good enough to tell if leap-seconds were mishandled, my best candidate right now is the Cray Y/MP. The first networking of UNIX computers were over serial lines inside individual labs, and the applications couldn't care less about what time it was anyway. Nobody even dreamed about using computers as authoritative clock for a long time. As far as anybody has been able to make out, the first precision time synchronization over computer networks, where leap seconds could even be relevant, is Dave Mills work on FuzzBall and NTP, in the first half of the 1980-ies on NSFnet - and the FuzzBalls didn't run UNIX and only moved packets. Even in 1988 when the UNIX API was rubberstamped into POSIX by IEEE, nobody but Dave Mills really cared about leap-seconds, and even he didn't care much about it. See for instance his last paragraph of RFC958 from 1985. When leap seconds finally appear on the radar, a freak geophysical happenstance means there are no leap seconds for the precise six years where most stuff is connected the internet. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] no more listening to leap seconds?
In message , "Tom Van Baak" writes: So is it possible to divine if this targets the HF or VLF or both ? I would imagine that shutting VLF would leave a lot of consumer electronics stranded. On the other hand, I'm not sure I see much point in the HF service... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] IEC 61850 raises the stakes
In message <20171121152434.gd...@ucolick.org>, Steve Allen writes: >On Tue 2017-11-21T11:40:22+0000 Poul-Henning Kamp hath writ: >> Uhm, yes ? Hasn't that been the situation for more than ten years now ? > >Yes, but seeing a wikipedia talk page that describes a meeting with >one of the nazgul is unprecedented. Not really. But seing somebody take a wikipedia talk page seriously is at the very least surprising... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] IEC 61850 raises the stakes
In message <20171121032424.ga17...@ucolick.org>, Steve Allen writes: >This is some of the clearest confirmation that parties intend to make >a change to UTC in closed sessions, and that the United States is a >leader among those parties. Uhm, yes ? Hasn't that been the situation for more than ten years now ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] new delta-T data point
In message <20171103173224.ga10...@ucolick.org>, Steve Allen writes: >I'm a bit disturbed by the plotted path of that eclipse because it is >very wide and includes the entire Nile delta as well as modern >Palestine, Israel, Jordan, and Baghdad at sunset. Unless weather >prevented it, somebody else should have made a record of that eclipse. And they probably did, but it didn't survive or we havnt torn down the city built on top of it later. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap second roundup 2017
In message <20171025054835.ga18...@ucolick.org>, Steve Allen writes: >On Tue 2017-10-24T19:32:31+0000 Poul-Henning Kamp hath writ: >> The parallel is not as convincing as you may think. Back then, the people >> who worked with stuff where it made a difference knew what they were doing, >> being generally people with "phd." after their name. > >Alas, the history says that way too many of the PhDs did not. There >are lots of astronomers who wrote down their concept of origin and >meaning of the new second but turned out not to understand what the >new value of the second actually represented. Sadler is nearly alone on >record expressing the opinion that the leap second was a bad idea, >everybody else thought it was the perfect solution. A perfectly good argument why we should not listen to the astronomers this time around :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap second roundup 2017
In message <alpine.deb.2.11.1710241530180.22...@grey.csi.cam.ac.uk>, Tony Finch writes: >Poul-Henning Kamp <p...@phk.freebsd.dk> 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 polysemy is a world-ending disaster. The parallel is not as convincing as you may think. Back then, the people who worked with stuff where it made a difference knew what they were doing, being generally people with "phd." after their name. If you tried to 'fix' things by adding a timescale now, 99.9% of the people who needed to react are not clued. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap second roundup 2017
In message <59ee28f3.60...@edlmax.com>, Brooks Harris writes: > To me, the frustrating thing about the discussion at ITU and elsewhere > is the apparent outright refusal to consider a "second timescale". It is > considered and then dismissed out of hand in: The reason is very simple: UTC is mandated by laws, treaties, UN body regulations, international standards, national standards and regulatory rulemaking so many places that people don't even know where to start counting. And that's just the paperwork! Next level of hurt would be all the software which might mention "UTC", for instance in aviation. 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... The only feasible way to introduce a new timescale in this space, would be to make it a limited-audience scientific timescale, for instance for astronomers to point their telescopes with. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap second roundup 2017
> 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 transitions, [...] That is balderdash, and you know it: We know exactly when leap-days happen, and UTC doesn't have DST. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Go API for monotonitc elapsed time measurements
In message <alpine.deb.2.11.1702031510300.23...@grey.csi.cam.ac.uk>, Tony Finch writes: >This is an interesting proposal for fixing the Cloudflare leap second bug, >so that time interval calculations do sensible things even when the clock >is reset, without making an incompatible change to the existing APIs. > >https://github.com/golang/proposal/blob/master/design/12914-monotonic.md We have talked about something similar inside Varnish, for the same reasons. Problem is that many of the POSIX apis are stupid about time (but we knew that already), in our case most importantly pthread_cond_timedwait(). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
In message <d7881cf5-7107-41db-9ec1-e716c79e9...@lpl.arizona.edu>, Rob Seaman w rites: >Leap seconds are a means to an end. It isn't just astronomers >who care about Earth orientation. Systems for navigation at sea, on >land, in the air, and in space are dependent on the current definition >of Coordinated Universal Time as exactly that, In the venacular of today, this claim is an "alternative fact". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The Fuzzball
In message <cahzk5we+bof94kej8gyfo-79ygtjbg8exl9dqk1hjtucrww...@mail.gmail.com> , Sanjeev Gupta writes: >Parting Shot (quoted from the Paper): >The ideal next-generation Fuzzball would be programmed in C, support the >Unix run-time environment, TCP/IP and ISO protocol suites and contain no >licensed code. Yeah, it's called "FreeBSD" :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The POSIX Time Rationale - in the Working Group's own words
In message <20161230204404.ga4...@ucolick.org>, Steve Allen writes: >On Fri 2016-12-30T20:20:57 +0000, Poul-Henning Kamp hath writ: >> >It may prove useful to know why the POSIX Working Group (WG) excluded >> >leap seconds, in their own words. >> >> POSIX didn't "exclude leap seconds", they chose not to "add leap seconds". > >In the 1988 standard it is clear that they chose not to add the >century leap-year rule. They preferred simplicity for now rather than >correctness over an interval longer than time_t could then encode. The story I heard was that the issue of copyright/license to the UNIX man-pages were still not fully resolved. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] private smear goes public
In message <b400409c-0655-4c51-83b1-5cf3b19d6...@develooper.com>, =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= writes: >> It does not have any copyright claims on it I can identify. Not >> do the other related files, like >> https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. >> >> Seems to me any copyright claim would defeat the IERS purposes. >> Seems to me if there were such it would have to be stated in Bulletin >> C itself. > >You don't need to "claim copyright" to have it. You need to license to allow >others to use your work. While that is true, there are a lot of fine print. First, licensing can and often is implied. This is generally the case if you distribute your own work widely with no indication of intention to enforce your copyright later on. If you want to assert and defend your "mercantile rights", you need to state that up front, with a big fat copyright notice, from day 1. Second, there are exceptions for fair use, which almost certainly applies here, since leap seconds have legal force in most countries. The only relevant situation where copyright matters for Bulletin-C, is if somebody replaces IERS name with something else. That would be an attack on IERS's (directors) "ideal right" to be associated with the work as its creator. The ideal rights does not require marking, because nobody who violates them can possible be in doubt that they didn't create the work themselves [1]. So as long as you reproduce Bulletin C verbatim, there can not and will not be any copyright issues[2]. Poul-Henning [1] This is where the trouble starts with music: There are only so many guitar-riffs, and parallel creation is bound to happen. Ask Led Zeppelin for details. [2] I wonder if anybody bothered to actually ask IERS director, or if this is just the usual navel-gazing and circle-jerking from militant FOSS license-separatists ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] private smear goes public
In message <20161202095852.d2017406...@ip-64-139-1-69.sjc.megapath.net>, Hal Murray writes: > >> That's another problem with leap seconds: they are irregular and there's no >> standard way to get the leap second info reliably (though there are sources >> of data on the internet that are changing that if you are connected. > >There is a plan to distribute a leap second file as part of the time zone >data base. Even though people have gotten much more aggressive about updating systems, the fundamental problem is the less than 6-months notice we get. 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*. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bloomberg announced its smear
In message <5538148C9CFA4B1FACC82994D3371084@pc52>, "Tom Van Baak" writes: >Get down to the details about PC clock frequency instability and >OS measurement jitter and I suspect you'll find that cosine vs. >triangle is a red herring. Actually, cosine with a much higher frequency might be the way to beat the median filter. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] A standard for leap second smearing
In message <calvmchlqrgr0-j6w-8u11g-o94ouk7eamdys2x2079+nhkh...@mail.gmail.com>, Michael Shield s via LEAPSECS writes: >> 3) Speed of smearing? >> The existing approaches have two broad groups - fast (under an hour - >> Bloomberg/UTC-SLS) and slow (20 hours or more - Google/Amazon) with >> QTnet an outlier towards the fast end. > >I expect a smear of 2000 s or less would be challenging for NTP >clients, because of the 500 ppm max slew rate, which would be entirely >consumed by tracking the smear. Clients that have backed off to 1024 >s polling would also have trouble noticing that a smear was happening >when the smear is only 1000 s or 2000 s long. It is much worse than that: You need to account for the delay in the median filter, which on straight slopes is typically 4 poll intervals. For a well-running client, that means it won't even start to pay attention to the smear from the server until after 4096 seconds, at which time it will start to look at a 1024 or 2048 second old sample. Once fully on the slope of the smear, the median filter will run 4096 seconds "behind" and once the smear is over, it will overshoot in similar fashion. >Besides being easier for NTP clients to track, a slow smear has the >advantage [...] Ohh, and don't forget: DCF77 only announces the smear one hour in advance. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bloomberg announced its smear
In message <1474862124.16870.7.ca...@systemeyescomputerstore.com>, John Sauter writes: >Google says in the blog that they did the smearing to avoid the need to >review all of their time-sensitive code. Those of us who love leap >seconds need to spend the next 10 years doing that code review, and the >necessary testing and bug fixing to get everything working in the >presence of leap seconds. > >We also need to fix operating systems and subroutine libraries so that >when application programmers, who don't care about leap seconds, write >their code it will "just work". Let us know when you are done: http://bgr.com/2015/09/18/size-of-google-source-code-lines/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bloomberg announced its smear
In message <canczdfpmoz25rvtg1prnrtm+vwmj4cjadwaq4p9amenquvu...@mail.gmail.com>, Warner Losh writes: >I tend to view smearing as a repudiation of the concept of leap >seconds. Agreed. Rubber-seconds and smearing is quite literally ways to sweep leapseconds under the rug where hopefully nobody will notice them. It is just about as far from an endorsement of leapseconds as one can possibly be. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bloomberg announced its smear
In message <57e575f7.1010...@edlmax.com>, Brooks Harris writes: >So, now there are at least 3 different smears in use by major providers [...] Clearly leapseconds are such a good idea that everybody wants in on the game :-/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Ice melt and LOD
I'm _almost_ willing to pay $40 to read this, but not quite: http://www.sciencedirect.com/science/article/pii/S0012821X16302370 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] The mystery of the missing leapseconds
This is a very interesting piece of research:
http://advances.sciencemag.org/content/2/4/e1501693.abstract
His primary claim is that melting ice has caused the earths
axis to change, which is major news indeed.
His secondary claim, which is where it gets on topic for us, is
that most of, possibly all, the decadal variability in Earth
Orientation is due to water transport, for instance the major shifts
of water which El Nino causes.
I asked him the obvious question (on twitter):
"Any chance this also explains "the missing leap seconds" ('98-'05) ?"
to which he replied:
"I am not sure about that!"
Which sounds like there could be another article in his data.
If we are _really_ lucky, there is a way to improve prediction of
future leap-seconds in that.
It will be interesting to see if this El Nino also causes a pause.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] WRC-15 press release
Don't give up you day job. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] WRC-15 press release
In message <f2f57420-f2d5-46d0-8651-b6ffe9d98...@batten.eu.org>, Ian Batten via LEAPSECS writes: You're reading wy to much in this. In ITU "For futher study" means "Forget it". If you don't belive me you can google itu "for further study" and you'll get 62K hits -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] WRC-15 press release
Really ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] WRC Final Acts
In message <56645275.3090...@yahoo.com>, "Michael.Deckers. via LEAPSECS" writes: >On 2015-12-06 12:26, Poul-Henning Kamp wrote about computer science >organizations: > >> There is nothing notable about that: There are no such ITU-compatible >> organizations they could work with. > >Isn't IFIP sufficiently international? It's not a question about being "sufficiently international" its a question of being an organization composed of official government representatives. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] WRC Final Acts
In message <20151205212640.ga25...@ucolick.org>, Steve Allen writes: >In the mean time there should be more studies involving >the alphabet soup of agencies IMO, ICAO, CGPM, CIPM, BIPM, IERS, IUGG, >URSI, ISO, WMO and IAU. > >That list of agencies is notable in that none of those are involved in >defining standards for computing systems. There is nothing notable about that: There are no such ITU-compatible organizations they could work with. ITU being a UN treaty organization, it is a organization focused on governmental interests, and it has always had extreme reluctance, bordering on open hostility, to working with non treaty-based and non-governmental organizations. Most people forget that the OSI protocols originally started in ITU (Then: CCITT) as "The Intelligent Network". ITU's inability and unwillingness to talk to anybody but UN member governments and their "tele-administrations" made IT vendors grab a copy, stuff it into ISO, and take it from there. ITU pretended that didn't happen until their "legitimate participants", in this case the NATO governments, took a copy of the ISO work and stuffed it back into ITU, in order to synchronize the text of the standards. They barely finished before it all became utterly irellevant for ever. Other notable skirmishes was the X2/V.Last/V.90/V.92 charade, where again ITU pretended nothing happened above V.34 spees, until governments finally had enough and dragged PCM based modems there. The existence of the Internet, based on the RFC standards, have only caused very minor concessions from ITU: They're willing to reference RFC's as normative, but there is no coorporation or colaboration of any kind between ITU and IETF. It's not like the ITU memberstates could not change this if they wanted to, the control the charter, but to my knowledge, nothing of that sort has ever had a smidgen of support. The closest you can find which could bridge the gap from the computer industry to ITU would be ISO, which *could* become a UN treaty organization if they wanted to, but which have repeatedly refused to do so, because they no less pompous asses than ITU. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Fwd: IERS Message No. 282: Coordinated Universal Time (UTC) to retain "leap second"
In message <d278bf58.fc5b%kevin.bi...@qc.cuny.edu>, Kevin Birth writes: >Am I reading this correctly that studies will be conducted by the usual >suspects in hopes that after all these years of their studying and discussing >leap seconds a different result will be produced by 2023? No, you are not reading it correctly. "For further study" is an ITU term of art for things they have dropped. Random example: https://www.itu.int/rec/dologin_pub.asp?lang=e=T-REC-I.241.6-198811-I!!PDF-E=items (TELEX over ISDN D-channel) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] "bulletin C via DNS" service
Now that we're stuck with leap-seconds for another decade or more, I have launched my "bulletin C via DNS" service. This page contains all the details and the portable C-source of my reference client implementation: http://phk.freebsd.dk/time/20151122.html Poul-Henning PS: I'm very interested in reports if anybody get something different than the IPv4 number "244.34.36.97" back when they lookup the FQDN 'leapsecond.utcd.org' -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What happened in the late 1990s to slow the rate of leap seconds?
In message <canczdfrmzxoomfj9dbx2fas1t3ynryjx-gpc+djkfbmw2gv...@mail.gmail.com> , Warner Losh writes: >what about the effects of glacial melt? Can LOD changes be tied to that? I did some math on that long time ago, and got a negative. *) The ice is quite close to the axis of rotation *) The melt water gets distributed over much bigger surface area than the ice. *) The change in altitude is very moderate compared to earth radius *) The mass is very small relative to earth mass. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What happened in the late 1990s to slow the rate of leap seconds?
>> We don't know, but the period had other pecularities, for instance >>almost statistically significant level of vulcanism. >“Almost statistically significant” is like “a little bit not pregnant” ;-) Indeed. That's why I stressed the uncertainty. The original paper is here: http://www.nature.com/ngeo/journal/v7/n3/full/ngeo2098.html Their angle is climatic, but I couldn't help notice that the period they study remarkably coincident with the leap-second "hiatus". I havn't seen anything even remotely close to a geophysical hypothesis about the leap-second "hiatus", and this one isn't much of one either. The major earth-quakes you cite mainly affect LOD via angular momentum. If volcanism can affect the "lubrication" between core and mantle, that in turn can give rise to much larger LOD effects. That is not physically impossible inside our current (lack of) knowledge - and that is about all we can say. So it's not a particular strong hypothesis, most likely just a coincidence, but if we keep an eye on it in the future, we may be able to either rule it out or refine it. The interesting footnote is that *if* the core/mantle interface is that sensitive, melting most of the ice on Greenland is likely to impact on both earthquake patterns and LOD significantly. But the important part in my original answer is what comes before the comma: "We don't know." -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What happened in the late 1990s to slow the rate of leap seconds?
In message <20151109025137.a95a8406...@ip-64-139-1-69.sjc.megapath.net>, Hal Murray write s: >There is a nice graph here: > http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html > >Was there a geological incident that explains things? We don't know, but the period had other pecularities, for instance almost statistically significant level of vulcanism. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Cisco testing leapseconds now ?
Looks like cisco may actually have started testing leapseconds now: https://tools.cisco.com/quickview/bug/CSCut43397 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Did John Oliver just save the leap-second ?
It was quite interesting to watch Twitter during the leap-second, it is pretty obvious that John Olivers attention to the leap-second vastly increased the awareness. Given that awareness has always been the major deficiency about leap-seconds he may just have saved them, by showing that awareness is possible. That being said, it's appalling how much of the news coverage has not been able to get even basic facts right, leaving a lot of people with really weird ideas, from leapsecond happening at local midnight to all days henceforth being one second longer. It's pretty obvious from this: https://twitter.com/theckman/status/616039183648337920/photo/1 That the leap-second was anything but flawlessly executed, but we don't know how much of that is bugs in monitoring and how much is bugs in production. I'm not quite sure about the consequence of this one: https://github.com/systemd/systemd/issues/437 But it seems possible that large fraction of Linux systems have been following Googles leap-smear without knowing it because of systemd. It will be some days before news from Serious IT™ filters out through the press-officers to the world at large, most of them will try to sweep any troubles under the rug as usual. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Did John Oliver just save the leap-second ?
In message cac09a83b67da26cac45f2dffc1ba...@lumieresimaginaire.com, m...@lumieresimaginaire.com writes: Sure, this is what happened with routers a long time ago. Tell me about it, I was the one who had to yell at D-Link to get them to pay for the damage they caused. Nearly cost me $20K for running my pro-bono NTP server :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap second festivities?
In message 20150701104812.GE16965@localhost, Miroslav Lichvar writes: On Tue, Jun 30, 2015 at 09:42:50PM +0100, Rob Seaman wrote: Any thoughts on watching Google’s (or anybody else’s) smear in action? Kind of like watching paint dry, but still… It seems the Google leap smear has finished. Here is a plot of offsets of some Google servers I included in my leap second monitoring. https://mlichvar.fedorapeople.org/leap2015/google_smear.png It was apparently a linear smear which is difficult to follow for NTP clients. It's the other way around. They dropped the raised-cosine thing, because the change of frequency was bad for the NTP clients PLL's. The linear smear is just a slightly different frequency for a fixed period of time, that's a lot easier for the PLL to track. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Did John Oliver just save the leap-second ?
In message acae89d1f40a4725fe18581573f06...@lumieresimaginaire.com, m...@lumieresimaginaire.com writes: This example makes that all the more important if people like google are exposing non UTC compliant data outside their firewall. There are very valuable NTP servers serving up special timescales (including TAI), so that would be a totally insane thing to try. They shouldn't be letting them into the public net. Could this be called temporal terrorism? https://github.com/systemd/systemd/issues/437 [1] It seems to me that the problem here is that the Systemd people picked default NTP serves without asking the owner/admins of those servers if that was 1) allowed and 2) a good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap second festivities?
In message 37d91ca5-9bb1-45b5-aecf-5bfc08f28...@noao.edu, Rob Seaman writes: What are people's plans for the day? I'm setting up as much of my usual data collection as I can get to work, in order to have and provide test-data for tests of leap-second handling. It doesn't look like I'll get my VLF sampler running though. Previous leapsecond data: http://phk.freebsd.dk/Leap/20081231/ http://phk.freebsd.dk/Leap/20051231_HBG/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] hyperbole
In message 137d178d-0b73-48a2-ace1-cc281bc8b...@noao.edu, Rob Seaman writes: Universes could be created during Tuesday's leap second' [...] Can we get that written into the POSIX specification? If somebody still has an old Pyramid computer running, it is certainly possible that the universe(1) command would get executed during the leapsecond... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] EBML: yet another date format?
In message 20150629061957.aafc4406...@ip-64-139-1-69.sjc.megapath.net, Hal Mu rray writes: Looks to me they mean 128 bits? How did you get that? supported by a signed 8-octet integer in nanoseconds centered on 8*8 is 64. I didn't see anything about using two of them. POSIX uses 32 bits of seconds and 32 bits of nanoseconds. That will wrap in 2038. Using all nanoseconds gets a few more bits so the overall range will be a bit bigger. (Whether it's enough bigger is another matter.) You overlook that they moved the epoch 30 years. Not enough, but enough to make not a problem in my lifetime. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] EBML: yet another date format?
In message 558ecbd0.26744.17a64...@dan.tobias.name, Daniel R. Tobias writes
:
The way dates are defined there is:
signed 8 octets integer in nanoseconds with 0
indicating the precise beginning of the
millennium (at 2001-01-01T00:00:00.0 UTC)
The bit which confuses me here, as with timespec and timeval is
why the f**k people seem to love mixed radixes for time ?
Numeric timeformats for binary computers should be fixed point
binary and have units of seconds.
That way you can have multiple different formats for different needs
(32.32, 48.16, 64.32, 64.64 ...) and still painlessly convert between
them.
But more importantly: you can do arithmetic on them at machine
speed, instead of having to use horrors such as:
#define timespeccmp(tvp, uvp, cmp)
(((tvp)-tv_sec == (uvp)-tv_sec) ?
((tvp)-tv_nsec cmp (uvp)-tv_nsec) :
((tvp)-tv_sec cmp (uvp)-tv_sec))
#define timespecadd(vvp, uvp)
do {
(vvp)-tv_sec += (uvp)-tv_sec;
(vvp)-tv_nsec += (uvp)-tv_nsec; if
((vvp)-tv_nsec = 10) {
(vvp)-tv_sec++;
(vvp)-tv_nsec -= 10; }
} while (0)
#define timespecsub(vvp, uvp)
do {
(vvp)-tv_sec -= (uvp)-tv_sec;
(vvp)-tv_nsec -= (uvp)-tv_nsec; if
((vvp)-tv_nsec 0) {
(vvp)-tv_sec--;
(vvp)-tv_nsec += 10; }
And that's why the above is bogus, even before we discuss their choice
of epoch or handling of leapseconds...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message 556f0c92.4020...@edlmax.com, Brooks Harris writes: You're saying this to the bloke who implemented a prototype adaptive optics solution for the ESO ELT on a plain, unmodified FreeBSD kernel ? I didn't know that, very impressive. Is there information anywhere how it was done? I did a presentation at a workshop at ESO in december 2012, the slides seems to be here: https://www.eso.org/sci/meetings/2012/RTCWorkshop/proceedings.html I'm not sure what the legal status is for deeper info. You'd have to ask them for access. The person to talk to is Nick Kornweibel. I bring the RT aspect [...] The first point here is that commodity *NIX, be it LINUX, FreeBSD or something else is often used to pull time into systems, even if they themselves don't do the RT part. The other thing to notice is that even if it is not RT in the strict classical sense, commodity *NIX does things which matter on microsecond resolution timescales. (As for instance the ESO thing). The time on Microsoft Azure will be Different by a second, everywhere http://www.theregister.co.uk/2015/05/29/windows_azure_second_out_of_sync/ As I said earlier - A) Where did they get this information? B) Is it true? C) Is that how Windows is behaving? A) Ask them. (M$ probably notified their customers ?) B) I have no reason to doubt it. The Reg is usually very good on truth. C) Probably only in Azure. Other Windows will probably do the usual Windows thing: Step a second some time later. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Actual versus legal duration makes programming hard
In message 20150602065310.ga11...@ucolick.org, Steve Allen writes: On Tue 2015-06-02T06:38:46 +, Poul-Henning Kamp hath writ: UTC is very much a technical standard, written to solve the problem of what time did it happen in international (and thus political) relations. That degrades the work of IETF and every other organization that requires two interoperable implementations before they approve a standard. That is not even wrong. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message 556d8c59.9040...@edlmax.com, Brooks Harris writes: A lot of Windows machines are doing things where you would expect people to care about leap-seconds: Nuclear power plants control systems, Air Traffic Control computers, Surgery robots, Patient Monitors, Power grid disturbance detectors etc. etc. etc. In many of those uses the PC is not doing the mission critical timing. No event-driven multitasking OS can do precise timing [...] You're saying this to the bloke who implemented a prototype adaptive optics solution for the ESO ELT on a plain, unmodified FreeBSD kernel ? Anyway, the PC doesn't need to do the RT parts directly in order to mess them up with wrong timestamps. But this is not something they are happy about doing, much less proud of doing, but weighing the risks of heterogeneous leap-second handling and the risk of being up to half a second wrong about time for most of a day, they picked the second risk. The failures folks are frightened of are bugs evoked by the Leap Second. At least some of which are just stupid bugs, like threading races when outputting the Leap Second event to the system log, not basic timekeeping calculation errors. If all parts of the system did POSIX and NTP correctly the timekeeping would not reflect UTC correctly because neither POSIX or NTP do that anyway, but the systems wouldn't hang or crash. As it is they have to smear to minimize the problems. Which is like saying that if only 50% of all programmers weren't below the skill-median, we wouldn't have the problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message 556bfd47.4050...@edlmax.com, Brooks Harris writes: Multiply this by 250 million [1] PC's still happily running XP and you can better understand why Microsoft hasn't been that interested in leap seconds, NTP, or participating in the hh:59:60 timestamp nightmare. Yes, they've got a very large number of badly administrated systems in the field. In more tightly administrated systems it can be done better. But its all good enough for current purposes. That's not as obvious as you seem to think. A lot of Windows machines are doing things where you would expect people to care about leap-seconds: Nuclear power plants control systems, Air Traffic Control computers, Surgery robots, Patient Monitors, Power grid disturbance detectors etc. etc. etc. Fact is that most of the people involved in these systems have no idea what a leap-second is, and more crucially: Once they learn that, they have no idea what the system they designed will do when one happens. It would make sense, like Google and Amazon, that their in-house data centers would want to more precisely and deterministically handle leap seconds. But note all three companies have decided to jump or smear time instead of creating a true leap second. As I understand it its not that they are interested in precise or accurate time - they are interested in smoothing over the Leap Second to avoid problems potentially caused by the Leap Second jump in the many OSs running in the data centers. They are very much interested in both *precise* and *accurate* time, that's why they have to do something in the first place. If they were not interested in good timekeeping, they could just let the computers free-run their clocks and pretend this is the 1980ies. And yes, the smoothing and ramping and steps are all attempts to win predictability at the expense of accuracy, when faced with at huge amount of software written by the kind of people mentioned above. But this is not something they are happy about doing, much less proud of doing, but weighing the risks of heterogeneous leap-second handling and the risk of being up to half a second wrong about time for most of a day, they picked the second risk. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Actual versus legal duration makes programming hard
In message 20150601172537.gc14...@ucolick.org, Steve Allen writes: We need a resolution of the issue so that the out-of-the-box defaults can just work without any choices. I'm happy that you have finally realized why some parties are pushing for the only resolution on the table[1] which makes that possible: Stop inserting leap-seconds into UTC. [1] The not-on-the-table resolution which would also make that possible is announcing leap seconds with at least 10-20 years advance notice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message 556b6735.20784.5a32d...@dan.tobias.name, Daniel R. Tobias writes : On 31 May 2015 at 19:33, Poul-Henning Kamp wrote: Most likely, at some random time after the leapsecond, your clock steps a second. ...which is basically how most computers deal with time synchronization, excepting the minority that actually attempt continuous high precision and accuracy; the computer's clock, not all that accurate a timepiece, drifts off from external standards within the period (hours, days, weeks) between synchronizations, and has to step a few seconds one way or the other to catch up (possibly smoothed out to prevent discontinuities that harm processes in progress); the leap second, if any, is lost in the noise. I have no idea what kind of computers you are talking about here, but your description has very little to do with the computer where leap-seconds matter. You may be right for the typical kids game-computer and the computer in your set-top-box, and for such purposes I doubt leap seconds are going to wreck havoc[1]. I'm talking about work computers (and so is Microsoft Azure) and here timekeeping matters, because otherwise emails are after the replies to them, databases don't agree about stock, medicine does not live up to FDA rules etc. etc. etc. In this world, NTP rules, PTP is the up and coming kids where it really matters, and leap-seconds are not at all lost in the noise. The big problem here, is that we have lost a generation of good IT-people to the dot-com period[2], and they think, like you seem to think, that What Me Worry?. [1] Although, if all Playstations and X-Boxes suddenly go into a full CPU-spin at the same time, that might tilt certain weaker electrical grids. [2] The IT profession grew by a factor of about 1000 during the dot-com years. Everybody who could sit still in front of a keyboard and read an O'Really? book was suddenly a web-programmer. It is probably historys greatest dumbing down of any trade - ever - and we're still spending a lot of our energy educating these people. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message 556b5d76.6000...@edlmax.com, Brooks Harris writes: Most Windows boxes don't run NTP. I don't think that's true. As far as I know, Windows, either personal or Server versions, synchronize using NTP, and did so with SNTP until Win 2000, then NTPV3, then NTPV4. I glean this from accumulated knowledge - its difficult to find authoritative information from Microsoft about it. So that depends what you mean by NTP. If you mean that your packets look like NTP packets, then yes, it does run NTP. But I mean use the NTP clock model. On my personal laptop running Win 7, I don't have Active Directory, and the W32Time service is *not* started. But it will synchronize via the usual desktop Internet Time mechanisms. It uses either time.nist.gov, time.windows.com, etc. These are NTP servers. But what happens when the leap-second hits ? Most likely, at some random time after the leapsecond, your clock steps a second. Windows of any version is fundamentally following NTP. Not even close. That's why Meinberg still maintains their NTPD client. You should find Martins presentation from FOSDEM about this. But that doesn't answer the first question about how the Leap Second is applied to local time by Azure and/or Windows. Because that is the only sane thing for them to do, given the (broken) timekeeping in the software they run. The fundamental question about leapseconds is not about where Rob can find the sun at noon, but about teaching an awful lot of rather crap programmers how to cope with a infrequent and intractable complexity on short notice. It seems like Daniels scheduling on this one may show us which is more important. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message 556b74ee.2040...@edlmax.com, Brooks Harris writes: Because that is the only sane thing for them to do, given the (broken) timekeeping in the software they run. Well, broken in what way for what purpose? An awful lot of people use it.. Yeah, and more insects eat shit every minute than there ever will be humans on the planet. Quality is not a mater of majority. The fundamental question about leapseconds is not about where Rob can find the sun at noon, but about teaching an awful lot of rather crap programmers how to cope with a infrequent and intractable complexity on short notice. I don't think its fair to insult all the programmers. That's why I wrote an awful lot rather than all. It seems like Daniels scheduling on this one may show us which is more important. Sorry, lost track of what that comment refers to.. As far as I can tell, Daniel Gambis would have had no trouble justifying scheduling this leapsecond at either the preceeding or succeesding new years eve, but he decided to stick not to blunt the impact and scheduled it Tue/Wed July 1st. I'm glad he did, it's the only way to end the prophetizing: What ever happens or don't happen on july 1st will be valuable *factual* input to the ITU decicion making process. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message 20150531145859.ga10...@ucolick.org, Steve Allen writes: UCO/Lick knows that, even with the best available version of NTP, the sloppy (or even lack of) hardware clock on some motherboards [...] This is *UTTER* bull-shit. There is usable clock-hardware on all PC boards all the way back to the original IBM PC, and Microsoft has never claimed that lack of hw was the reason for this. The main reason why good timekeeping support has never been a priority for Microsoft is that it would allow people to measure how ridiculous shitty their so-called Operating Systems are at all sorts of low-level activities. Recent versions of Windows have grown various hack-ish API's, mostly because there was no to play video without it. Most of these API's are not good for anything else. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message 556a6bd2.50...@edlmax.com, Brooks Harris writes: I can't find any authoritative announcement or statement to this effect from Microsoft, [...] Please note that this is *only* about Microsofts Azure cloud service, (which according to rumours are mostly used to run Exchange servers). This is *NOT* how your private/work Windows machine will behave, for that no new information is available and the most recent guidance was that somewhere between a second and an hour later the clock will step a second. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message 556abecf.2050...@edlmax.com, Brooks Harris writes: My question is, if Azure is doing this, what is Windows itself doing? No. for that no new information is available and the most recent guidance was that somewhere between a second and an hour later the clock will step a second. most recent guidance from whom? As I understand it, the clock would step a second when it syncs with NTP, but note there are apparently different capability NTP clients in various Windows versions. But what happens in different timezones? Most Windows boxes don't run NTP. Some of them run some oddball M$ time-sync protocol where they ask their domain-controllers -- if they have one. Where domain-controllers get their time is anyones guess. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Google, Amazon, now Microsoft
In message b6b86593-04ad-47d8-a95a-e1c50cdb9...@noao.edu, Rob Seaman writes: 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. As far as I know, it is not like Microsoft has any choice, local midnight is the only time their software makes it possible for them to make sure that all servers jump at the same time. Perhaps one should point out that local midnight is pretty much the worst possible time for astronomers to accommodate such a change? Rob, 1. Unfathomable! Call them! I say, Call them Right Now, and make them see the errors of their ways! How dare they Ignore the Needs of the True Masters Of The Universe ?! 2. Do any astronomers even use Microsofts Azure cloud thingie ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look before you don't leap
In message d29f7d8a-de6b-446d-a194-9c7be4f8b...@noao.edu, Rob Seaman writes: Tell it to the folks who think they can hide the Sun in the cracks between the timezones. You mean all the chinese people living up several hours away from mean solar time, because all of China is a single time-zone ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News
In message 20150521134322.gg10...@ucolick.org, Steve Allen writes: POSIX does not want to know geophysics, nor astrometry, nor politics. POSIX does not care what is meant by day. POSIX wants someone else to decide what day means, and for all those other details to be handled outside the kernel in the libraries and applications. POSIX is not just a kernel API, it *also* defines the functions for deciding what day means and all that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look before you don't leap
I'm absolutely certain that POSIX will survive much longer than the current definition of UTC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News
In message 05704fac-8087-42ca-bb03-51c4b21c6...@tcs.wap.org, Jonathan E. Har dis writes: I stand by my original statement. The label on the box is a mass specificati= on, not a force specification. See the reference provided. I didn't say the label didn't describe a mass, I said that your blanket statement: That box of Wheaties that is labelled 'Net Weight 10 oz' would correctly weigh 10 oz everywhere on Earth, on the Moon, and on the ISS. ...is not correct, because the mass is only applicable in the local environment at the shipping factory. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News
In message dce2e991-a54d-42af-98f8-2d5087fbf...@leapsecond.com, Tom Van Baak writes: https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ So already here the trouble starts: Google uses a smooth curve for their clock-smearing and Amazon uses a piecewise linear curve. I can see reasons for both choices, but I'd probably go with Googles to avoid the sharp corners. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look before you don't leap
In message 05e65caf-d064-4d4e-aa16-195fe7d15...@noao.edu, Rob Seaman writes: On the other hand, the one thing we can be sure about POSIX is that it will ultimately have a finite lifespan. But a day on Earth (and on Mars and Pluto) will always be a synodic (mean solar) day, whatever decision is made at WRC-15. You are wrong in both claims. The fundamental problem in POSIX is the value of the integer 'time_t' not in how it is represented in human form. POSIX is therefore perfectly capable of handling any calendarial form of time you care for, *including* UTC with leap-seconds, (with the footnote that a few seconds suffer from an ambiguity of the same kind as the repeat-hour during DST switchback). On much of the planet, a day is not a synodic (mean solar) day twice a year, when DST is started/stopped, and for any person travelling from one timezone to another, the concept day has nothing at all to do with the mean solar day. So always ? not even close... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News
In message 32c69001-db69-46c4-905f-d994b017b...@tcs.wap.org, Jonathan E. Hardis writes: That box of Wheaties that is labelled 'Net Weight 10 oz' would correctly weigh 10 oz everywhere on Earth, on the Moon, and on the ISS. It does not. For several reasons, but mainly because the enclosed air changes means that the bouyancy depends on air-pressure and thus altitude. That goes for anything which isn't enclosed by a rigid container with neglible elasticity in the range of relevant air-pressures. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look Before You Leap ? The Coming Leap Second and AWS | Hacker News
In message 20150519181135.cacbe406...@ip-64-139-1-69.sjc.megapath.net, Hal Murray writes: I think the problem is conflicting standards. POSIX doesn't agree with UTC. Not so much doesn't agree as ignores. Are there any examples of buggy standards with a huge installed base getting fixed? Yes, plenty. Building codes. Electrical codes. Traffic codes. The deciding factor is always number of people killed and maimed. ... Or the rich loosing money, that always gets political action. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News
In message 0e448a0c-f75a-43a0-9fb6-7d715ef92...@bsdimp.com, Warner Losh writes: Surely the existence of these 'smeared' timescales points to a fundamental flaw in the method we've chosen to keep atomic and solar time in sync? Speaking of flawed... Reported to me from the hall-way-track at the last WP7A meeting: The main drive to ditch leap-seconds comes from the only country ever to flunk Metric-101 rimshot/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] LOD and gravity connected ?
http://iopscience.iop.org/0295-5075/110/1/10002/article -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Vive la différence! (was Re: financial markets)
In message cajqu6xp-3knbo6cs7zp2uaucmsaxpgq0deqqnrknhpfqfsn...@mail.gmail.com , Peter Vince writes: However, I would actually hope that any new leap-less time-system would be given a new name, and with the increasing difference from GMT, the public would eventually get to know that new name instead. I'm pretty damn sure that the brits will remove leaps from GMT as well, so there still won't be any difference, and people will in all likelyhood still confuse them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
I didn't think that NTP or POSIX or PTP is what we'd call a timescale. NTP is a UTC synchronization algorithm. If we give the subword scale its usual meaning, then NTP is a (also) a timescale: It carefully defines the scale on which it is going to synchronize computer clocks, in particular it defines the measurement unit on this scale to be 2^-32 SI second and the handling of epoch roll-overs (every 2^32 SI seconds). But more importantly, when we get to the point were we are arguing over the meaning of common well known words we might as well stop it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Letters Blogatory
In message 5500731c.3080...@edlmax.com, Brooks Harris writes: Overall he seems to make a good philosophical argument why solar time is good for humans. But his conclusion seems confused. We have a saying in danish Skoma'r bliv ved din læst which translates to Cobbler stay at your workbench. The fact that he is a lawyer seems to have nothing, if anything to do with his personal opinion on leap seconds. In other words: Yeah, he's entitled to his opinion, just like everybody else, but he doesn't have any special standing for his opinion, which as others have pointed out, interfaces badly with reality. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] final report of the UK leap seconds dialog
In message 20150206023406.ga10...@ucolick.org, Steve Allen writes: doesn't address the elephant in the room - local time. It is all too common to find situations where it is difficult to ascertain who has authority, over what geographic region, and what exactly they are trying to say. [...] But contrary to the leap-second, which is imposed by a bunch of scientists with no democratic or other mandate, those who muck about with local time are responsible, through whatever goes for democracy in that locale, to the people affected. This is a very good argument for the positioin notion that unelected and unrepresentative scientists should not get to decide where and when the Sun is supposed to be in the sky above. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] final report of the UK leap seconds dialog
I think the dialog shows one thing clearly: The UK's historical zero offset from UTC has made it very hard for them to generalize that this is not a law of nature. It is certainly clear that very few involved realized that UK could run on a non-zero UTC offset, without any more harm to society than the rest of the world suffers, and that way, by national political choice choose any relationship between sun-height and civil day they might prefer. I wonder how different the outcome of the dialog would have been, if they had been told that leap seconds would happen at 8 or 9am on any day of the week, ie: during the busiest hour of traffic, on roads, rails and in the air ? That's what a similar dialog would warn about, if it were conducted in China or Japan. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Spot the leapsecond
http://xkcd.com/1481/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] All of this has happened before
In message bdf1dd12-9e80-4516-91ba-76127dcb9...@noao.edu, Rob Seaman writes: On Jan 28, 2015, at 1:34 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: Derives from is not a physical reality, it's merely a social custom. So many replies to choose from [...] ... all of them unresponsive to my complaint. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
