Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 03:53 PM, Richard Clark wrote: Back in the 1974 oil crisis the US made an 'emergency' change to its DST schedual. I don't recall the legal mechanism used. It was likely an executive order from the President. Is was an act of Congress - the Emergency Daylight Saving Time Energy Conservation Act of 1973 http://www.presidency.ucsb.edu/ws/?pid=4073 It was signed December 15, 1973, to go into effect January 6, 1974. The recent one in 2007, as part of the Energy Policy Act of 2005 http://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005 Passed July 29, 2005, Daylight in effect March 11, 2007 -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 01:46 PM, Warner Losh wrote: Other systems are less open, and sweep this data under the rug is also a valid conclusion. There's no mystery how Windows handles Leap Seconds - it doesn't. Its off by the Leap Second until it re-syncs to NTP. How the Windows Time service treats a leap second http://support.microsoft.com/kb/909614 Its timezone information is dynamic, held in the Registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones For example - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Eastern Standard Time Display (UTC-05:00) Eastern Time (US Canada) Dlt Eastern Daylight Time MUI_Display @tzres.dll,-110 MUI_Dlt @tzres.dll,-111 MUI_Std @tzres.dll,-112 Std Eastern Standard Time TZI BINARY And most entries include a Dynamic DST key - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Eastern Standard Time\Dynamic DST 2006 BINARY 2007 BINARY FirstEntry 2006 LastEntry 2007 These can be updated - (and probably are updated with a Windows Update, I've not verified that.) August 2013 cumulative time zone update for Windows operating systems http://support.microsoft.com/kb/2863058 And can be individually maintained - How to configure the daylight saving time start date and end date for Guatemala in Windows http://support.microsoft.com/kb/918645 This policy of behavior makes Windows a little safer from Leap Seconds and DST changes but its time is almost certainly wrong around changes until it re-syncs. -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote: 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. You should refrain from making inaccurate claims, it damages your credibility. It still doesn't detract from my point: leap seconds caused aberrant behavior in the linux kernel that everybody wants to nit-pick me on, but the nit-picks don't detract from the point. The point is the aberrant behavior, rather than the slight mischaracterizations of that. Geeze, no wonder no progress can be made, people are arguing over the wrong things. The fact that the most recent leap second error didn't cause kernel crashes but caused extra cpu cycles to be spent again lowers your credibility. I'm sorry, but a live lock is a crash. Claiming otherwise lowers your credibility. The Linux bug was a classic live-lock problem where no progress could be made depriving other users of CPU cycles. This is a crash, and has been considered a crash for the past 30 years or so. I've personally fixed a number of such crashes where the bug description was crash when more properly it was described as a deadlock or live lock.. MP is hard, sure, but that's not the root cause of this issue. The root cause of this issue was an error when stepping a clock backwards? Why was the clock stepped backwards? To comply with a POSIX requirement that does not match reality? The root cause happened in 1972 when time was changed from an fixed radix to a variable radix. I submit that the proper fix is to update the spec to match the fact that we now have days that are 86401 seconds long, now to eliminate leap seconds. Actually it isn't reality. Days don't have 86401 seconds, and won't for a few millennia. Days have 86400.001 SI seconds (give or take). UTC isn't reality, but a standard for keeping the variations in that 0.001 in sync with fixed-length seconds by choosing a convention to label seconds so that is accomplished. POSIX is a standard for keeping time in a computer. These two standards are in conflict. That's the real root cause here. Claiming that POSIX doesn't match reality lowers your credibility. POSIX and UTC don't describe the same thing. One must change to resolve the conflict. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 04:36 AM, Greg Hennessy wrote: 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. You should refrain from making inaccurate claims, it damages your credibility. The fact that the most recent leap second error didn't cause kernel crashes but caused extra cpu cycles to be spent again lowers your credibility. MP is hard, sure, but that's not the root cause of this issue. The root cause of this issue was an error when stepping a clock backwards? Why was the clock stepped backwards? To comply with a POSIX requirement that does not match reality? I submit that the proper fix is to update the spec to match the fact that we now have days that are 86401 seconds long, now to eliminate leap seconds. There is nothing fundamentally wrong with UTC and Leap Seconds - the theory is sound, and the IERS does a fantastic job of keeping track of it. But there are difficulties with implementations for several reasons - A) The specifications and procedures regarding UTC are scattered over many documents and several standards bodies. B) There is no standardized, centralized, and *automated* way to obtain the UTC metadata (Leap Seconds table, announce signals, etc) C) There are well know inadequacies with c and POSIX specs with regard to Leap Seconds which have percolated through the computer industry. D) Timezones are a horrendous mess, if somewhat mitigated now by IANA's administration of tz database. Eliminating Leap Seconds doesn't begin to address the implementation difficulties. By itself it would likely make things (much) worse. Instead, all this passion could be directed at - A) Cleaning up and consolidating the UTC specs B) Designing a good and modern date and time metadata server C) Cleaning up the c and POSIX specs D) Clarifying timezone guidelines, including standardizing international date line, UTC offset, and methods of Daylight instantiation It took centurys for the Gregorian calendar to be accepted. Hopefully it won't take as long for society to start using UTC correctly. -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Warner Losh writes: On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote: 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. You should refrain from making inaccurate claims, it damages your credibility. It still doesn't detract from my point: leap seconds caused aberrant behavior in the linux kernel that everybody wants to nit-pick me on, but the nit-pick s don't detract from the point. The point is the aberrant behavior, rather th an the slight mischaracterizations of that. Geeze, no wonder no progress can be made, people are arguing over the wrong things. Bad handling and inadequate testing of leap seconds in those kernels (and was some of it libc?) caused the aberrant behavior. H ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 7:53 AM, Harlan Stenn wrote: Warner Losh writes: On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote: 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. You should refrain from making inaccurate claims, it damages your credibility. It still doesn't detract from my point: leap seconds caused aberrant behavior in the linux kernel that everybody wants to nit-pick me on, but the nit-pick s don't detract from the point. The point is the aberrant behavior, rather th an the slight mischaracterizations of that. Geeze, no wonder no progress can be made, people are arguing over the wrong things. Bad handling and inadequate testing of leap seconds in those kernels (and was some of it libc?) caused the aberrant behavior. The linux kernel has been touted by some of its proponents as the most tested and verified kernel around. Some may quibble with this characterization, but if not the most, certainly one of the most. And even so, this problem with leap seconds managed to escape into released kernels. If that happened, here, what hope is there for other, less well tested systems. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 8:47 AM, Warner Losh i...@bsdimp.com wrote: The linux kernel has been touted by some of its proponents as the most tested and verified kernel around. Some may quibble with this characterization, but if not the most, certainly one of the most. And even so, this problem with leap seconds managed to escape into released kernels. If that happened, here, what hope is there for other, less well tested systems. There are many much more complex computer science challenges. In fact, the entire purpose of these things called computers is to deal efficiently with hellaciously complicated problems. This problem ain't that intractable. Meanwhile, whatever discussions occur on this list should flow from documented case studies: http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf Not untethered speculation. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote: On Feb 12, 2014, at 8:47 AM, Warner Losh i...@bsdimp.com wrote: The linux kernel has been touted by some of its proponents as the most tested and verified kernel around. Some may quibble with this characterization, but if not the most, certainly one of the most. And even so, this problem with leap seconds managed to escape into released kernels. If that happened, here, what hope is there for other, less well tested systems. There are many much more complex computer science challenges. In fact, the entire purpose of these things called computers is to deal efficiently with hellaciously complicated problems. This problem ain't that intractable. Meanwhile, whatever discussions occur on this list should flow from documented case studies: http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf Not untethered speculation. Untethered speculation? Sweet! I've never had my direct, personal experiences in a topic be called that before. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 07:47 AM, Warner Losh wrote: The linux kernel has been touted by some of its proponents as the most tested and verified kernel around. Some may quibble with this characterization, but if not the most, certainly one of the most. And even so, this problem with leap seconds managed to escape into released kernels. If that happened, here, what hope is there for other, less well tested systems. In my industry we have a timing protocol casually referred to as timecode, the latest specification is called ST 12. There's a reasonably good explanation of it at Wikipedia - http://en.wikipedia.org/wiki/SMPTE_timecode. The original designs of this predate the c and POSIX specs, tracing their heritage to IRIG timecode http://en.wikipedia.org/wiki/IRIG_timecode. In the early years of industry deployment it was pretty unreliable. It took years for venders, both hardware and software, to learn how to do it interoperablly. As things progressed, SMPTE revised and refined the specification and eventually everybody was on the same page. It was really 10 years before it all settled down, or matured. The implementation of UTC in computers spans many standards bodies across many disciplines so its way more difficult in that respect. Its going to take a while. I think the kill Leap Seconds call as an unfortunate diversion from concentrating efforts to clarify usage. In my experience in standards bodies the conversation and resources are driven by venders who in turn are presumably responding to their customer's requests but too often the user's opinions get lost in translation. The LEAP_SECS list seems populated mostly by computer users (sophisticated users), rather than manufacturers or venders. As a group you all could probably have some influence. -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 08:03 AM, Warner Losh wrote: On Feb 12, 2014, at 8:03 AM, Brooks Harris wrote: On 2014-02-12 04:36 AM, Greg Hennessy wrote: 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. You should refrain from making inaccurate claims, it damages your credibility. The fact that the most recent leap second error didn't cause kernel crashes but caused extra cpu cycles to be spent again lowers your credibility. MP is hard, sure, but that's not the root cause of this issue. The root cause of this issue was an error when stepping a clock backwards? Why was the clock stepped backwards? To comply with a POSIX requirement that does not match reality? I submit that the proper fix is to update the spec to match the fact that we now have days that are 86401 seconds long, now to eliminate leap seconds. There is nothing fundamentally wrong with UTC and Leap Seconds - the theory is sound, and the IERS does a fantastic job of keeping track of it. But there are difficulties with implementations for several reasons - A) The specifications and procedures regarding UTC are scattered over many documents and several standards bodies. B) There is no standardized, centralized, and *automated* way to obtain the UTC metadata (Leap Seconds table, announce signals, etc) i'd add 'verified' or 'secure' (since many of the ways involve http:// urls) to this list. Sure. All the related issues. You'd like to see many API's (XML, Binary XML, Soap, etc ) over many channels (Internet, private network, satellite, etc). If a core data set were designed that would be a start. C) There are well know inadequacies with c and POSIX specs with regard to Leap Seconds which have percolated through the computer industry. D) Timezones are a horrendous mess, if somewhat mitigated now by IANA's administration of tz database. E) Leap seconds are tied to observations of the earth's spin, rather than predicted years in advance. With only 6 months warning for leap seconds, this produces operational difficulties for many environments that have burdensome change control policies. Long term, we have the ability to predict out decades what the proper rate of leap seconds should be to keep things in sync over the long haul. One of the nice things about the Gregorian calendar is that it accepts errors of up to like 3 days (worst case) to keep the over all system simple (every 4 except 100 except 400) and on track for millennia. Leap seconds, as currently implemented, require too much phone home to keep things on track. The IERS's ability to adjust UTC to +-0.9s of TAI is an incredible achievement. Its unpredictable, but that's fundamentally the nature of the beast. Lets deal with it. Its not hard to imagine some standardized way of stating how far in the future predictions are accurate and how far off they might likely be beyond that. Eliminating Leap Seconds doesn't begin to address the implementation difficulties. By itself it would likely make things (much) worse. Instead, all this passion could be directed at - A) Cleaning up and consolidating the UTC specs and improving the spec. Currently, it works great for astronomers and other folks that need a cheap distribution of time within a second of UT who are fairly technical, Yes. but works less well for less technically situations (witness the number of places that get leap seconds wrong and don't care to fix it) and for less well connected environments. But its hard to fix in the absence of clear specification, so they really can't. A better analogy to the Gregorian calendar would be to have a leap second every 18 months for the next 100 years, with the next schedule to be published after 50 years for the hundred years after that. The problems with the Gregorian calendar on on the scale of thousands of years. Sure, but UTC handling, if flawed, is now embedded in the culture, like Gregorian calendar. Maybe the flaws can be fixed. B) Designing a good and modern date and time metadata server Assuming internet connectivity may be problematic for some applications. ensuring that other distribution of time channels are augmented to include better leap data (GPS has current leap info, but no historical leap info, for example). Yes. The metadata needs to be distributed over many APIs and channels. C) Cleaning up the c and POSIX specs The time guys were kicked out of the posix committee, so good luck on that one. :( And it isn't so much cleaning up the standard, which could be solved with some diplomacy, tact, etc. It is cleaning up all the code that's extant that assumes all days always have 86400 seconds, or that the formulas in the POSIX standard for converting broken up time into time_t are now invalid. Yes, but it all needs to be reengaged. Certainly many
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 9:54 AM, Brooks Harris wrote: On 2014-02-12 08:09 AM, Rob Seaman wrote: There are many much more complex computer science challenges. In fact, the entire purpose of these things called computers is to deal efficiently with hellaciously complicated problems. This problem ain't that intractable. Yes. I've never been able to understand why facing the guts of this problem has been evaded. Its a great computer-science project - it should be fun! The problem stems not because one person can't climb the complexity hill to get it right: several have. The problem comes more from the large numbers of people in my industry that have failed to climb the complexity hill due to apathy, incompetence or both. Coupled with the 'it is only a second' attitude that prevails, these problems make it extremely difficult to build a system based on any third party components that gets things right, especially with the standards stacked against you... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Hi Warner, You’ll note that this particular email is addressed to you. Most contributions to this mailing list are not personally addressed. In those cases one might reasonably infer that other messages were intended as general contributions to a common forum. On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote: Meanwhile, whatever discussions occur on this list should flow from documented case studies: http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf Not untethered speculation. Untethered speculation? Sweet! I've never had my direct, personal experiences in a topic be called that before. As are many of those reading this, I’m fitting time for the forum into a packed schedule of other activities. Since the list has been busy lately it is hard to keep up with all the talking points. Some of these correspond to things with which I disagree, but have no time to address. On more than one occasion lately I have therefore chosen to reference the many previous discussions on this list or its precursor, as well as the proceedings of the two meetings we organized in 2011 and 2013 precisely to discuss these topics. Assertions on a mailing list, not just yours alone, may be called untethered if they don’t reference prior work, here and elsewhere. In particular, Steve Allen’s paper is the most complete exploration of the topic in question, and itself references a variety of resources well worth reviewing. Many talking points here have indeed been speculative. Those who believe in hiding the signature of the synodic day within a shell game of ever shifting timezones could certainly arrange for prudent research to either demonstrate or demolish such a scheme. Absent such studies the notion is speculation. It is not speculation, however, to point out that this notion forms no part of the actual ITU proposal, which is focused on redefining UTC to no longer serve as Universal Time, not on the remedies for such action. Those who need access to interval timescales already have such access. What the proposal does, rather, is deny access to the current solar timescale, an issue not directly related to the timezone system. One might therefore infer that the entire discussion of timezones is a ploy to achieve a short term political end, but that would be speculation. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-12 09:46 AM, Warner Losh wrote: On Feb 12, 2014, at 9:54 AM, Brooks Harris wrote: On 2014-02-12 08:09 AM, Rob Seaman wrote: There are many much more complex computer science challenges. In fact, the entire purpose of these things called computers is to deal efficiently with hellaciously complicated problems. This problem ain't that intractable. Yes. I've never been able to understand why facing the guts of this problem has been evaded. Its a great computer-science project - it should be fun! The problem stems not because one person can't climb the complexity hill to get it right: several have. The problem comes more from the large numbers of people in my industry that have failed to climb the complexity hill due to apathy, incompetence or both. Sure, but its hard in the absence of standards as you say, so apathy might be avoidance. Its not hard to be incompetent here either - you really have to study carefully to get all the pieces straight, and then you're still left with loose ends. Its frustrating. Coupled with the 'it is only a second' attitude that prevails, Yeah, thats the one I don't get. You'd think engineers would strive for accuracy. But if it looks like a death march they are likely to make excuses to avoid it, I'd guess. these problems make it extremely difficult to build a system based on any third party components that gets things right, especially with the standards stacked against you... Its the lack of clarity in the standards together with the long legacy of flawed implementations for many reasons that makes the political landscape so daunting. But the problem has such broad consequences I can't believe people don't want to solve it. I think the ITU needs more than why Leap Seconds should be retained. They need something like here's a better way to explain it and a better way to disseminate it. And the computer industry needs champions of the approach to lead refinements of API specs, etc. With that it might take hold and the implementations would mature. -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 11:22 AM, Rob Seaman wrote: Hi Warner, You’ll note that this particular email is addressed to you. Most contributions to this mailing list are not personally addressed. In those cases one might reasonably infer that other messages were intended as general contributions to a common forum. Yea. On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote: Meanwhile, whatever discussions occur on this list should flow from documented case studies: http://www.cacr.caltech.edu/futureofutc/preprints/files/2_AAS%2013-502_Allen.pdf Not untethered speculation. Untethered speculation? Sweet! I've never had my direct, personal experiences in a topic be called that before. As are many of those reading this, I’m fitting time for the forum into a packed schedule of other activities. Since the list has been busy lately it is hard to keep up with all the talking points. Some of these correspond to things with which I disagree, but have no time to address. On more than one occasion lately I have therefore chosen to reference the many previous discussions on this list or its precursor, as well as the proceedings of the two meetings we organized in 2011 and 2013 precisely to discuss these topics. Yea, I'd hoped to attend those, but they were held in locations the advance notice of the meeting precluded my attendance. Assertions on a mailing list, not just yours alone, may be called untethered if they don’t reference prior work, here and elsewhere. In particular, Steve Allen’s paper is the most complete exploration of the topic in question, and itself references a variety of resources well worth reviewing. I wasn't aware that we had to foot-note all the assertions made before they'd be held up to ridicule. they are unreferenced, not untethered. Untethered is rude and implies I'm full of some solid brown substance that typically doesn't smell good if a third party produced it Ask for references instead of being insulting. Geeze. Many talking points here have indeed been speculative. Those who believe in hiding the signature of the synodic day within a shell game of ever shifting timezones could certainly arrange for prudent research to either demonstrate or demolish such a scheme. Absent such studies the notion is speculation. It is more than just speculation. One can demonstrate that the error between local time and timezone time remains within the same error bars that we have today, as well as demonstrate the frequency of the shift needed. Perhaps that should be something i write up... It is not speculation, however, to point out that this notion forms no part of the actual ITU proposal, which is focused on redefining UTC to no longer serve as Universal Time, not on the remedies for such action. Those who need access to interval timescales already have such access. What the proposal does, rather, is deny access to the current solar timescale, an issue not directly related to the timezone system. One might therefore infer that the entire discussion of timezones is a ploy to achieve a short term political end, but that would be speculation. The old proposal I thought was totally dead. The notion there was to have a leap-hour in UTC, which we both agree is a crazy idea... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
E) Leap seconds are tied to observations of the earth's spin, rather than predicted years in advance. With only 6 months warning for leap seconds, this produces operational difficulties for many environments that have burdensome change control policies. What do those organizations do when Congress changes the DST rules? Do they work on UTC/GMT so they can ignore DST? They must have to interact with the rest of the world occasionally. How much notice did people get the last time Congress changed the DST rules? I don't pay attention to summer time in Europe. How often do things change over there and/or how much notice do people get when the rules are changed? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Warner Losh writes: On Feb 12, 2014, at 7:53 AM, Harlan Stenn wrote: Warner Losh writes: On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote: 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. You should refrain from making inaccurate claims, it damages your credibility. It still doesn't detract from my point: leap seconds caused aberrant behavior in the linux kernel that everybody wants to nit-pick me on, but the nit-picks don't detract from the point. The point is the aberrant behavior, rather than the slight mischaracterizations of that. Geeze, no wonder no progress can be made, people are arguing over the wrong things. Bad handling and inadequate testing of leap seconds in those kernels (and was some of it libc?) caused the aberrant behavior. The linux kernel has been touted by some of its proponents as the most tested and verified kernel around. Some may quibble with this characterization, but if not the most, certainly one of the most. And even so, this problem with l eap seconds managed to escape into released kernels. If that happened, here, what hope is there for other, less well tested systems. The conclusions I draw from the utter lack of any similar reports from non-linux systems are: - either those kernels/libraries did not do leap-second processing, or - they did and their code worked Do you have different conclusions? H ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote: The conclusions I draw from the utter lack of any similar reports from non-linux systems are: - either those kernels/libraries did not do leap-second processing, or - they did and their code worked Do you have different conclusions? Yes. Linux is more popular and examined than other systems. Linux is more open than Windows, so bugs there won't be as well publicized. Linux is more popular than FreeBSD, which also handles leap seconds in the kernel. There have been about half a dozen bugs in FreeBSD's leap second handling that I've fixed over the years. The code mostly works, but I'm sure if it were studied in detail some aspect of leap seconds wouldn't be handled pedantically correctly (absolute timeouts for condvars in posix will, for sure, take a second longer to timeout across a leap second boundary). Linux is also has a higher rate of change and rewrite than FreeBSD, which is another reason it gets tripped up by these issues more often. The number of extant linux kernel versions is quite large compared to most other systems as well. With this much change, there's sure to be something overlooked, and quite often it is the edge cases, like leap seconds. Other systems are less open, and sweep this data under the rug is also a valid conclusion. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Warner Losh said: Yes. I've never been able to understand why facing the guts of this problem has been evaded. Its a great computer-science project - it should be fun! The problem stems not because one person can't climb the complexity hill to get it right: several have. The problem comes more from the large numbers of people in my industry that have failed to climb the complexity hill due to apathy, incompetence or both. Or they (or their bosses) have done a cost-benefit analysis and concluded it's not worth fixing. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Hal Murray said: I don't pay attention to summer time in Europe. How often do things change over there and/or how much notice do people get when the rules are changed? The EU has standard rules defined in a Directive. The present Directive is 2000/84/EC and was published in the Official Journal on 2001-02-02. It took effect from March 2002. That Directive didn't actually change the rules; the last one that did was 97/44/EC, which changed the autumn rule from fourth Sunday in October to last Sunday in October. This appeared in the OJ on 1997-08-01 and gave the rules for 1998 to 2001 inclusive. So we're talking a year or so lead time. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Brooks Harris said: D) Clarifying timezone guidelines, including standardizing international date line, UTC offset, and methods of Daylight instantiation Um, timezones are a political matter pure and simple. Who do you think is going to listen to you? -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Back in the 1974 oil crisis the US made an 'emergency' change to its DST schedual. I don't recall the legal mechanism used. It was likely an executive order from the President. But it most definitely was with less than 6 months notice so the legal precedent is exists in the US. I also have noticed that 'critical security patches', to which linux is less prone than some operating systems, often require action in less than 6 months from the time issued. Richard Clark rcl...@noao.edu On Wed, 12 Feb 2014, Hal Murray wrote: E) Leap seconds are tied to observations of the earth's spin, rather than predicted years in advance. With only 6 months warning for leap seconds, this produces operational difficulties for many environments that have burdensome change control policies. What do those organizations do when Congress changes the DST rules? Do they work on UTC/GMT so they can ignore DST? They must have to interact with the rest of the world occasionally. How much notice did people get the last time Congress changed the DST rules? ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
Warner Losh writes: On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote: The conclusions I draw from the utter lack of any similar reports from non-linux systems are: - either those kernels/libraries did not do leap-second processing, or - they did and their code worked Do you have different conclusions? Yes. Linux is more popular and examined than other systems. Linux is more open than Windows, so bugs there won't be as well publicized. Linux is more popular than FreeBSD, which also handles leap seconds in the kernel. There have been about half a dozen bugs in FreeBSD's leap second handling that I've fixed over the years. The code mostly works, but I'm sure if it were studied in detail some aspect of leap seconds wouldn't be handled pedantically correctly (absolute timeouts for condvars in posix will, for sure, take a second longer to timeout across a leap second boundary). Doesn't pass my smell test. I know lots of folks who run Windows, nobody reported seeing this problem there. I run FreeBSD on *lots* of boxes, many different versions. None of them saw this. We're not talking about pedantically correct, we're talking about locking up the box. Linux is also has a higher rate of change and rewrite than FreeBSD, which is another reason it gets tripped up by these issues more often. The number of extant linux kernel versions is quite large compared to most other systems as well. With this much change, there's sure to be something overlooked, and quite often it is the edge cases, like leap seconds. So you are saying that Linux is a paragon of quality and design and development, and as proof of this you offer a painful screwup as the exception that proves the rule? Other systems are less open, and sweep this data under the rug is also a valid conclusion. That implies their customers didn't write about it or complain to anybody. I think I don't have anything more to add to this discussion. H ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
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
On Feb 11, 2014, at 9:46 AM, Rob Seaman wrote: On Feb 11, 2014, at 9:31 AM, Tony Finch d...@dotat.at wrote: Warner Losh i...@bsdimp.com 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 d...@dotat.at wrote: Warner Losh i...@bsdimp.com 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 sea...@noao.edu wrote: On Feb 11, 2014, at 9:31 AM, Tony Finch d...@dotat.at 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.finch d...@dotat.at http://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 d...@dotat.at wrote: Rob Seaman sea...@noao.edu wrote: On Feb 11, 2014, at 9:31 AM, Tony Finch d...@dotat.at 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.finch d...@dotat.at http://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
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 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
On Feb 9, 2014, at 11:20 AM, Warner Losh i...@bsdimp.com wrote: On Feb 9, 2014, at 11:13 AM, Rob Seaman wrote: If anything has prevented leap seconds from death it is the weakness of the proposal itself. And the real-world distinction between Universal Time and Atomic Time; Death to leap seconds! is the rallying cry of somebody who wants to pretend that two distinct concepts are the same thing. It is more of a 'Atomic Time is a completely adequate basis for civil time' by rejecting the notion that exact alignment to snyodic day is a requirement. Apart from some naming sophistry, that's the root of all the discussions and disagreements here. There’s a lot that could be said in response, but I’ll just point to the proceedings of the Charlottesville and Exton meetings: http://www.cacr.caltech.edu/futureofutc/preprints/ http://www.cacr.caltech.edu/futureofutc/2011/preprints/ and to various links including the archives of this and the original leapsecs mailing lists: http://futureofutc.org/links.html There is also a link to the ISO position on terminology. And, of course, it isn't exact alignment that would be sacrificed, but any alignment at all. Like I said, it is an attempt to confuse two different concepts. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 10, 2014, at 9:02 AM, Rob Seaman wrote: On Feb 9, 2014, at 11:20 AM, Warner Losh i...@bsdimp.com wrote: On Feb 9, 2014, at 11:13 AM, Rob Seaman wrote: If anything has prevented leap seconds from death it is the weakness of the proposal itself. And the real-world distinction between Universal Time and Atomic Time; Death to leap seconds! is the rallying cry of somebody who wants to pretend that two distinct concepts are the same thing. It is more of a 'Atomic Time is a completely adequate basis for civil time' by rejecting the notion that exact alignment to snyodic day is a requirement. Apart from some naming sophistry, that's the root of all the discussions and disagreements here. There’s a lot that could be said in response, but I’ll just point to the proceedings of the Charlottesville and Exton meetings: http://www.cacr.caltech.edu/futureofutc/preprints/ http://www.cacr.caltech.edu/futureofutc/2011/preprints/ and to various links including the archives of this and the original leapsecs mailing lists: http://futureofutc.org/links.html There is also a link to the ISO position on terminology. And, of course, it isn't exact alignment that would be sacrificed, but any alignment at all. 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. These times zones would move on a scale of multiple decades or centuries. 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. 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. 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... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 10, 2014, at 9:57 AM, Warner Losh i...@bsdimp.com 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. 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. 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. 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. 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? And for that matter I’m skeptical that it doesn’t confuse those few concepts you appear to care about. You’d be requiring a complex tz schema (much more complex than currently) be added to many classes of software that simply get by with ambient UTC now. 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... Oh, if only I could lay claim to being an entrenched aesthete :-) You don’t like arguments about Universal Time needing to continue to denote the same term of art it always has? ISO disagreed with you enough to send a technical committee chair from Hong Kong to Washington, DC: http://www.cacr.caltech.edu/futureofutc/aas223/presentations/2-1-ISOterminologyAAS.pdf Before it is used as implicit justification for redefining time policies worldwide, the ITU really ought to back it up with something more than “Hey, that sounds plausible! Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 8, 2014, at 5:11 PM, Brooks Harris bro...@edlmax.com wrote: On 2014-02-07 04:12 AM, Poul-Henning Kamp wrote: In message 20140206151947.ga25...@ucolick.org, Steve Allen writes: Taken at face value Google's Site Reliability Team would seem to be arguing for the return to the bad old days of the rubber second. Yeah, they're totally opposed to having equal-length seconds, and they really showing the world with this demonstration, aren't they ? I have heard a fair bit in private communications about why and how google did implement the leap-smear, and let me assure you that they have a special place in Googles hell reserved for those who prevented leapseconds from having a quick and swift death back when that was first proposed. I probably missed discussion of this survey a couple years ago. Not as much as there should have been. Thanks for reintroducing it into the mix. I note two individuals at Google replied. One answered I am not satisfied and prefer UTC redefined without leap of second, and one I am satisfied with the current definition of UTC which includes leap second. Maybe there's not really a consensus within Google either? INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) EARTH ORIENTATION CENTER ANSWERS OF THE QUESTIONNARY CONCERNING A POSSIBLE REDEFINITION OF UTC http://hpiers.obspm.fr/eop-pc/questionnaire/reponse_questionnaire.html Regarding Google Hell, this has a particular meaning: http://www.forbes.com/2007/04/29/sanar-google-skyfacet-tech-cx_ag_0430googhell.html None of our factions has ever been particularly concerned about query placement, and in general the various resources are easy enough to find. One might, however, point out that the Google Blog itself doesn't show up until the third page of results ;-) If anything has prevented leap seconds from death it is the weakness of the proposal itself. And the real-world distinction between Universal Time and Atomic Time; Death to leap seconds! is the rallying cry of somebody who wants to pretend that two distinct concepts are the same thing. Regarding private communications, the most obvious thing about this mailing list is the dearth of participation from supporters of the death penalty. Rather than anecdotes in private email, such individuals are encouraged to participate here. Or perhaps as the EOC questionnaire shows, there are simply many more supporters of the status quo: http://www.cacr.caltech.edu/futureofutc/2011/preprints/17_AAS_11-668_Gambis.pdf The plural of anecdote is not data. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Feb 9, 2014, at 11:13 AM, Rob Seaman wrote: If anything has prevented leap seconds from death it is the weakness of the proposal itself. And the real-world distinction between Universal Time and Atomic Time; Death to leap seconds! is the rallying cry of somebody who wants to pretend that two distinct concepts are the same thing. It is more of a 'Atomic Time is a completely adequate basis for civil time' by rejecting the notion that exact alignment to snyodic day is a requirement. Apart from some naming sophistry, that's the root of all the discussions and disagreements here. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On 2014-02-07 04:12 AM, Poul-Henning Kamp wrote: In message 20140206151947.ga25...@ucolick.org, Steve Allen writes: Taken at face value Google's Site Reliability Team would seem to be arguing for the return to the bad old days of the rubber second. Yeah, they're totally opposed to having equal-length seconds, and they really showing the world with this demonstration, aren't they ? I have heard a fair bit in private communications about why and how google did implement the leap-smear, and let me assure you that they have a special place in Googles hell reserved for those who prevented leapseconds from having a quick and swift death back when that was first proposed. I probably missed discussion of this survey a couple years ago. I note two individuals at Google replied. One answered I am not satisfied and prefer UTC redefined without leap of second, and one I am satisfied with the current definition of UTC which includes leap second. Maybe there's not really a consensus within Google either? INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) EARTH ORIENTATION CENTER ANSWERS OF THE QUESTIONNARY CONCERNING A POSSIBLE REDEFINITION OF UTC http://hpiers.obspm.fr/eop-pc/questionnaire/reponse_questionnaire.html -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
In message 20140206151947.ga25...@ucolick.org, Steve Allen writes: Taken at face value Google's Site Reliability Team would seem to be arguing for the return to the bad old days of the rubber second. Yeah, they're totally opposed to having equal-length seconds, and they really showing the world with this demonstration, aren't they ? I have heard a fair bit in private communications about why and how google did implement the leap-smear, and let me assure you that they have a special place in Googles hell reserved for those who prevented leapseconds from having a quick and swift death back when that was first proposed. -- 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 5 Feb 2014, at 23:50, Richard Clark rcl...@noao.edu wrote: I'm surprised that someone on the list hasn't already pointed this out. Today February 5 2014 (already yesterday in much of the world) marks the 90th anniversary of the BBC's time pips as we know them. All the coverage again points out that the Greenwich time signal is in fact a melange of UTC(GPS), UTC(NPL) and the BBC's own atomic clocks, rather than GMT (ie UT1). Another indicator that although UK legal time is UT1, in practice not only does everyone use UTC, but sources of UT1 with better than 100ms resolution are difficult to access in real time (MSF only carries DUT1 to 100ms). ian ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
On Thu 2014-02-06T11:32:09 +, Ian Batten hath writ: All the coverage again points out that the Greenwich time signal is in fact a melange of UTC(GPS), UTC(NPL) and the BBC's own atomic clocks, rather than GMT (ie UT1). Another indicator that although UK legal time is UT1, in practice not only does everyone use UTC, but sources of UT1 with better than 100ms resolution are difficult to access in real time (MSF only carries DUT1 to 100ms). I still have those PDF scans of the 1984 letter from Martine Feissel of the BIH which show the slow demise of the entire ensemble of instruments which had once played the earth rotation game along with Greenwich. I need to extract the plots as jpeg files for easier embedding into web pages as examples when discussing this issue.t By the time those plots showed no more data input from optical transits there wasn't any tie left to the original GMT. On the subject of leap seconds in the UTC time scale I think there has been only one publicly identifiable commercial voice (someone correct me if I've missed others): Google and the leap smear. Taken at face value Google's Site Reliability Team would seem to be arguing for the return to the bad old days of the rubber second. It's hard to believe that Google's Android and driverless car divisions hold the same position, but they haven't spoken. Many ITU-R actions are in response to draft proposals which have been sent through the process by commercial entities. Their voices reflect their business needs. The process of coming through the working parties sometimes obfuscates who wants the new draft, but the small number of players in the telecom fields makes that hard. In this case it's as if there are no commercial voices at all who wish to be seen as contributing to the revision of TF.460. That is strange and unusual. This nebulous lack of clear technical voice is the atmosphere in which the RA was asked to vote 2 years ago, and it's little wonder that they decided not to decide. -- Steve Allen s...@ucolick.orgWGS-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
Ian Batten i...@batten.eu.org wrote: All the coverage again points out that the Greenwich time signal is in fact a melange of UTC(GPS), UTC(NPL) and the BBC's own atomic clocks, rather than GMT (ie UT1). Another indicator that although UK legal time is UT1, in practice not only does everyone use UTC, but sources of UT1 with better than 100ms resolution are difficult to access in real time (MSF only carries DUT1 to 100ms). See also section 5.5.6.1 of http://www.lib.cam.ac.uk/deptserv/manuscripts/RGO_history/rgo_home_ch5.html Tony. -- f.anthony.n.finch d...@dotat.at http://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
Steve Allen s...@ucolick.org wrote: Taken at face value Google's Site Reliability Team would seem to be arguing for the return to the bad old days of the rubber second. It's hard to believe that Google's Android and driverless car divisions hold the same position, but they haven't spoken. Why can't that driverless car maintain two separate and independent kinds of time, one physical, the other civil? VLR, SF ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] happy anniversary pips
I could have sworn that was Nye v Ham, not the State of the Union… On Feb 5, 2014, at 4:50 PM, Richard Clark rcl...@noao.edu wrote: I'm surprised that someone on the list hasn't already pointed this out. Today February 5 2014 (already yesterday in much of the world) marks the 90th anniversary of the BBC's time pips as we know them. I had been thinking about broadcast time signals recently. Here in the USA we just experienced another State of the Union address. The most interesting part of this event is the opportunity to compare the same programming stream going out simultaneously on numerous tv channels and radio stations. I found variation in lag between various sources of 10 seconds or more. The 'earliest' source seemed to be a local NPR station, although I did not include the off-the-air signals from local tv stations. I got those from Direct TV. Digital buffering and decoding delays seem to be more randum than the distribution of leap seconds. Richard Clark rcl...@noao.edu ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
