Re: [LEAPSECS] Pedagogy & Greenwich
Gerard Ashton wrote: > At such time, any correct attempt to explain what GMT means, when used > as a synonym for UTC, should mention it has nothing to do with > Greenwich. It hasn't had anything to do with Greenwich since the Observatory moved to Herstmonceux. Nowadays GMT qua UK civil time has more to do with Teddington (NPL). Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
The problem with adding an hour is when and where it is added. If the hour was added at the midnight at the prime meridian, it would be disruptive to rush hour and work schedules for most of the world's population. A critical difference between the management of UTC and the management of time zones is that time zone decisions are national and DST shifts are locally scheduled, whereas adding a leap to UTC is globally scheduled at a time that ignores that the Earth is a rotating globe and at a location that is, quite frankly, a legacy of colonialism rather than wisdom. Best, Kevin Kevin K. Birth, Professor Department of Anthropology Queens College, City University of New York 65-30 Kissena Boulevard Flushing, NY 11367 telephone: 718/997-5518 "We may live longer but we may be subject to peculiar contagion and spiritual torpor or illiteracies of the imagination" --Wilson Harris "Tempus est mundi instabilis motus, rerumque labentium cursus." --Hrabanus Maurus On 2/10/14 6:49 PM, "Warner Losh" wrote: > >On Feb 10, 2014, at 4:24 PM, Rob Seaman wrote: > >> On Feb 10, 2014, at 9:57 AM, Warner Losh wrote: >> >>> On Feb 10, 2014, at 9:02 AM, Rob Seaman wrote: >>> Like I said, it is an attempt to confuse two different concepts. >>> >>> We disagree here then. Atomic time is adequate for civil needs. The >>>small divergence can be handled the same way we handle differences in >>>time between the sun and the UT time now: time zones. >> >> There hasn¹t been the slightest investment of systems engineering in >>evaluating this notion of hiding variations in length of day in the >>timezone system. We had a cat once that liked to hide squirrel parts >>under the doormat. This is like that. >> >> Note also that Tom Scott¹s rant is titled ³The Problem with Time & >>Timezones²: >> >> http://youtu.be/-5wpm-gesOY >> >> Leap seconds are just a relish added at the end. He clearly doesn¹t >>perceive timezones as a solution, but rather as part of the problem. > >The leap forward or back an hour due to increasing out-of-syncness with >the sun would be a drop in the bucket. > >>> These times zones would move on a scale of multiple decades or >>>centuries. >> >> It¹s almost as if the last decade-plus of discussions never happened. >>Just continue to make the same empty unsupported assertion that doesn¹t >>actually appear anywhere in the ITU proposal. Please see many previous >>messages on this topic. Here I¹ll just note that these local updates >>would be clustered into extended periods of great confusion. This isn¹t >>an issue of two dozen timezones, but rather of the thousands of local >>jurisdictions that would be choosing what timezone to adhere to. Some >>would toggle back-and-forth for decades during these transitional >>centuries as different political parties take power. > >Pure speculation on your part. And also irrelevant. These are sovereign >states. > >>> This would suffice to keep the clocks on the wall aligned to the sun >>>in the sky to the same error as we have today. >> >> This confuses the reporting of local time with the maintenance of the >>underlying global timescale. Future historians would curse our names >>for introducing vast uncertainty into future chronologies. Predictions >>of future events (say, solar eclipses) would be unable to engage with a >>local time that might differ +/- one hour rather than a few seconds. > >The same problem exists with leap seconds... > >> Equating this with daylight saving time is a particular red herring >>since only a small fraction of world participates in any of the >>variations of DST, but also since these changes wouldn¹t be matched by a >>seasonal readjustment half a year later. Each locality would be >>applying leverage to their particular timezone, but the timezone as a >>whole would have fuzzy edges, perhaps extending all the way through to >>the next era of confusion. > >I engaged in no such red herring. > >>> It moves the alignment from one part of the system to the other. It >>>doesn't confuse any concepts at all, but rather properly applies them >>>to an alternative solution. >> >> It certainly confuses the concepts that describe the actual physical >>situation. And instead of keeping track of a single monotonic list of >>leap seconds, all software would have to track vast numbers of worldwide >>lists of local timezone peccadillos. A single Olson tz database might >>no longer suffice since it would have to be normalized against >>individual tables for cities and counties, let alone countries and >>continents. And pray, what happens in such a situation to the concepts >>of the prime meridian and the international date line? I presume we¹re >>to assume they stay put? Why should they? > >It does not confuse anything. And you overstate the effects relative to >other timezone effects. The timezone decisions would be made on a >national level, just like they are today. Salt Lake City and Denver are >on the same time, even tho
Re: [LEAPSECS] happy anniversary pips
On Feb 10, 2014, at 5:49 PM, Greg Hennessy wrote: > On 02/10/2014 11:57 AM, Warner Losh wrote: > >> I get that people don't like this, and that there's some resistance >> to it on aesthetic grounds dressed up in the guise of technical >> arguments about universal not meaning what it has always meant, and >> that entrenched interests aren't unhappy enough with the status quo >> to risk changes... > > > So the horrors of having a variable number of seconds in a minute is so > bad we'll switch to having a variable number of hours in day. We have that today. This changes nothing in that regard. In Atomic Time, there's always 24 hours of 60 minutes of 60 seconds. In Civil Time, it is whatever the authorities want. Changing DST has been done several times in my short lifetime, and the hour shift is well understood... > I suspect the major advantage of the new scheme is that > it pushes the matter off till most people around are > dead. Perhaps, but leap seconds are a solution to the problem that must die in the fullness of time. With the quadratic acceleration there will come a time in a few thousand years when one leap second a month or day isn't enough and another solution will be necessary to keep things in sync. So in a way, leap seconds are putting a band-aide over the problem until everybody alive today is dead too... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Warner Losh wrote: > > Perhaps, but leap seconds are a solution to the problem that must die in > the fullness of time. With the quadratic acceleration there will come a > time in a few thousand years when one leap second a month or day isn't > enough and another solution will be necessary to keep things in sync. So > in a way, leap seconds are putting a band-aide over the problem until > everybody alive today is dead too... Yes. And time zone adjustments will be able to keep civil time in sync with earth rotation for a much longer time than leap seconds :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 11, 2014, at 9:46 AM, Rob Seaman wrote: > On Feb 11, 2014, at 9:31 AM, Tony Finch wrote: > >> Warner Losh wrote: >>> >>> Perhaps, but leap seconds are a solution to the problem that must die in >>> the fullness of time. With the quadratic acceleration there will come a >>> time in a few thousand years when one leap second a month or day isn't >>> enough and another solution will be necessary to keep things in sync. So >>> in a way, leap seconds are putting a band-aide over the problem until >>> everybody alive today is dead too... >> >> Yes. And time zone adjustments will be able to keep civil time in sync >> with earth rotation for a much longer time than leap seconds :-) > > Nonsense! However expressed the embargoed leap seconds accumulate at exactly > the same rate during any particular epoch, and the long term tidal trend will > present the same challenge. > > Also nonsense to suggest that there is any urgency whatsoever since the > current UTC standard is practical for many centuries even without expanding > beyond December and June. This is a manufactured crisis. The effects of those leap seconds are a clear and present danger. Otherwise, we wouldn't be talking about this. The question isn't "how long can we keep this up." but rather "why are we doing this at all?" > That said, the fact that we're all still here 15 years later suggests > significant community interest in working on civil timekeeping issues and > infrastructure in general. How much further along we would be if we hadn't > just spent those 15 years attempting to quash the naive and dangerous ITU > proposal being pushed by special interests. People have been working for the past 15 years to make leap seconds better, yet in the last leap second all Linux kernels crashed due to a subtle bug that is only triggered when there was a leap second. This bug, in turn, took down many servers, reducing the capacity at many service providers significantly until human intervention could reboot the systems with a new kernel. Doesn't sound like we've made much progress on making this robust in the past 15 years... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 11, 2014, at 9:31 AM, Tony Finch wrote: > Warner Losh wrote: >> >> Perhaps, but leap seconds are a solution to the problem that must die in >> the fullness of time. With the quadratic acceleration there will come a >> time in a few thousand years when one leap second a month or day isn't >> enough and another solution will be necessary to keep things in sync. So >> in a way, leap seconds are putting a band-aide over the problem until >> everybody alive today is dead too... > > Yes. And time zone adjustments will be able to keep civil time in sync > with earth rotation for a much longer time than leap seconds :-) Nonsense! However expressed the embargoed leap seconds accumulate at exactly the same rate during any particular epoch, and the long term tidal trend will present the same challenge. Also nonsense to suggest that there is any urgency whatsoever since the current UTC standard is practical for many centuries even without expanding beyond December and June. This is a manufactured crisis. That said, the fact that we're all still here 15 years later suggests significant community interest in working on civil timekeeping issues and infrastructure in general. How much further along we would be if we hadn't just spent those 15 years attempting to quash the naive and dangerous ITU proposal being pushed by special interests. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Rob Seaman wrote: > On Feb 11, 2014, at 9:31 AM, Tony Finch wrote: > > > > Yes. And time zone adjustments will be able to keep civil time in sync > > with earth rotation for a much longer time than leap seconds :-) > > Nonsense! Leap seconds can deal with a rate difference of at most 12s per year. Time zone changes can cope with rate differences of 3600 seconds per year. (Though it is an odd time zone that always falls back and never springs forward...) Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Your definition of the word “cope” is different than mine. It would be a trivial change to permit leap seconds more frequently than monthly. Such won’t be needed for many centuries. Leap hours are an impractical rhetorical gimmick to dump the whole question (except the significant costs to many) on future generations. For any new members of the list these issues have been discussed repeatedly in the past. The list archives are at: http://six.pairlist.net/mailman/listinfo/leapsecs (since 2007) http://www.ucolick.org/~sla/navyls/ (before 2007) Rob — On Feb 11, 2014, at 10:04 AM, Tony Finch wrote: > Rob Seaman wrote: >> On Feb 11, 2014, at 9:31 AM, Tony Finch wrote: >>> >>> Yes. And time zone adjustments will be able to keep civil time in sync >>> with earth rotation for a much longer time than leap seconds :-) >> >> Nonsense! > > Leap seconds can deal with a rate difference of at most 12s per year. > Time zone changes can cope with rate differences of 3600 seconds per year. > (Though it is an odd time zone that always falls back and never springs > forward...) > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, > occasionally poor at first. > ___ > LEAPSECS mailing list > LEAPSECS@leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
> People have been working for the past 15 years to make leap seconds > better, yet in the last leap second all Linux kernels crashed due > to a subtle bug that is only triggered when there was a leap second. My understanding wasn't that all Linux kernels crashed. I though some fraction of the kernels with the bug crashed, because the bug wasn't deterministic and depended on locks being held elsewhere in the kernel. David. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
In message <20140211171627.ga73...@walton.maths.tcd.ie>, David Malone writes: >> People have been working for the past 15 years to make leap seconds >> better, yet in the last leap second all Linux kernels crashed due >> to a subtle bug that is only triggered when there was a leap second. > >My understanding wasn't that all Linux kernels crashed. Only the ones which cared enough about time-keeping to run NTPD. -- 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 http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 11, 2014, at 10:27 AM, Poul-Henning Kamp wrote: > In message <20140211171627.ga73...@walton.maths.tcd.ie>, David Malone writes: >>> People have been working for the past 15 years to make leap seconds >>> better, yet in the last leap second all Linux kernels crashed due >>> to a subtle bug that is only triggered when there was a leap second. >> >> My understanding wasn't that all Linux kernels crashed. > > Only the ones which cared enough about time-keeping to run NTPD. Does this distinction actually make a difference to the point I was making? Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 11, 2014, at 10:12 AM, Rob Seaman wrote: > Your definition of the word “cope” is different than mine. It would be a > trivial change to permit leap seconds more frequently than monthly. Such > won’t be needed for many centuries. Leap hours are an impractical rhetorical > gimmick to dump the whole question (except the significant costs to many) on > future generations. Leap hours in the time scale yes. Changes to the offset to Atomic Time, not so much since that changes all the time now when we're using Universal Time. But that's not what's being talked about. Atomic Time has no leap anything ever. Warner > For any new members of the list these issues have been discussed repeatedly > in the past. The list archives are at: > > http://six.pairlist.net/mailman/listinfo/leapsecs (since 2007) > http://www.ucolick.org/~sla/navyls/ (before 2007) > > Rob > — > > On Feb 11, 2014, at 10:04 AM, Tony Finch wrote: > >> Rob Seaman wrote: >>> On Feb 11, 2014, at 9:31 AM, Tony Finch wrote: Yes. And time zone adjustments will be able to keep civil time in sync with earth rotation for a much longer time than leap seconds :-) >>> >>> Nonsense! >> >> Leap seconds can deal with a rate difference of at most 12s per year. >> Time zone changes can cope with rate differences of 3600 seconds per year. >> (Though it is an odd time zone that always falls back and never springs >> forward...) >> >> Tony. >> -- >> f.anthony.n.finchhttp://dotat.at/ >> Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. >> Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, >> occasionally poor at first. >> ___ >> LEAPSECS mailing list >> LEAPSECS@leapsecond.com >> http://six.pairlist.net/mailman/listinfo/leapsecs > > ___ > LEAPSECS mailing list > LEAPSECS@leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
> >> People have been working for the past 15 years to make leap seconds > >> better, yet in the last leap second all Linux kernels crashed due > >> to a subtle bug that is only triggered when there was a leap second. > > > >My understanding wasn't that all Linux kernels crashed. > > Only the ones which cared enough about time-keeping to run NTPD. ... and that were running a particular old-but-not-too-old version of the Linux kernel. And it didn't happen everywhere. And it didn't crash machines, just got them very busy looping blocked by in-kernel locks (which is perhaps worse than a crash, depending on what matters). The patch to fix the bug was published in main-line Linux more than three months before the leap second occured: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d but the patch didn't get deployed everywhere it needed to be deployed, and the wedge up of some web site server farms made news: http://www.wired.com/wiredenterprise/2012/07/leap-second-glitch-explained/all/ -Tim Shepard s...@alum.mit.edu ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 11, 2014, at 11:22 AM, Tim Shepard wrote: > > People have been working for the past 15 years to make leap seconds better, yet in the last leap second all Linux kernels crashed due to a subtle bug that is only triggered when there was a leap second. >>> >>> My understanding wasn't that all Linux kernels crashed. >> >> Only the ones which cared enough about time-keeping to run NTPD. > > ... and that were running a particular old-but-not-too-old version of > the Linux kernel. And it didn't happen everywhere. And it didn't > crash machines, just got them very busy looping blocked by in-kernel > locks (which is perhaps worse than a crash, depending on what > matters). > > The patch to fix the bug was published in main-line Linux more than > three months before the leap second occured: > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d > > but the patch didn't get deployed everywhere it needed to be deployed, > and the wedge up of some web site server farms made news: > > > http://www.wired.com/wiredenterprise/2012/07/leap-second-glitch-explained/all/ Right, but none of that detracts from my original point... Leap seconds caused a problem in a widely deployed, presumably widely tested kernel when they should have been well enough known and tested to not to. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
> >> People have been working for the past 15 years to make leap seconds > >> better, yet in the last leap second all Linux kernels crashed due > >> to a subtle bug that is only triggered when there was a leap second. > >My understanding wasn't that all Linux kernels crashed. > Only the ones which cared enough about time-keeping to run NTPD. Not all of those either, if I understand correctly. Though, as Warner points out, it may not make much difference to the point he was making. David. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
The effects of those leap seconds are a clear and present danger. Some people claim this. Others disagree. People have been working for the past 15 years to make leap seconds better, yet in the last leap second all Linux kernels crashed due to a subtle bug that is only triggered when there was a leap second. Um, that is false. All linux kernels did not crash, in fact NONE of mine did. Did *some* multiprocessing kernels go into a spin lock when they issued a printk? Yes. I admit to wanting to know why the cry isn't "Symmetric multiprocessing is hard" rather than "leap seconds are hard". ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] time2posix on github
Developer elkablo on github has a POSIX timestamps compatibility library for glibc/linux system which uses "right time" visible at https://github.com/elkablo/time2posix and is looking for feedback for the development. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 11, 2014, at 5:34 PM, Greg Hennessy wrote: >> People have been working for the past 15 years to make leap seconds >> better, yet in the last leap second all Linux kernels crashed due to >> a subtle bug that is only triggered when there was a leap second. > > Um, that is false. All linux kernels did not crash, in fact NONE > of mine did. "all" here was an overstatement, but the impact of the leap second should never be "your kernel crashes" even if your personal kernels didn't. It is a consequence that's much larger than the extra second... > Did *some* multiprocessing kernels go into a spin lock > when they issued a printk? Yes. I admit to wanting to know > why the cry isn't "Symmetric multiprocessing is hard" > rather than "leap seconds are hard". MP is hard, sure, but that's not the root cause of this issue. Most of the changes that get into the base linux base are well tested because they are easy to test. Bugs that are this easy to trigger are quite rare. Part of what made this bug last as long as it did in the baseline was (a) the rarity of leap seconds and (b) the difficulty in testing them. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
