Re: [LEAPSECS] Leap Sec vs Y2K
In message 1292118117.24926.52.ca...@localhost, Paul Sheer writes: I choose the solution that makes my flight the cheepest. It is not a matter of flight being cheap or expensive. If you only synchronize computer on the order of minutes the modern airport ceases to function as such. During initial and terminal phases, a modern jetplane move 100m/s and many major airports have runway use in 30 second timeslots. You do the math. Radar stitching requires 3msec synchronization and timestamping, throughout the entire area being stitched, often a radius of up to 1000 km. You have just confirmed my suspicion that you have not a wisper of a clue about what you are pontificating about. -- 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] Leap Sec vs Y2K
In message 1292119375.24926.67.ca...@localhost, Paul Sheer writes: On Sun, 2010-12-12 at 01:20 +, Ian Batten wrote: indeed with these protocols, can I guess that, 1. syncronization is only required to within a couple of seconds 2. syncronization is only required between client and server within the local LAN. 3. syncronization does not need to absolutely represent real time. 4. leap seconds, or the absence thereof, make no difference You forgot: 5. Canibalism is a problem the Navy has mostly under control. -- 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] Leap Sec vs Y2K
On Dec 12, 2010, at 2:27 AM, Poul-Henning Kamp wrote: 5. Canibalism is a problem the Navy has mostly under control. It is well known that it is the RAF who now suffer the largest casualties in this area. I've eaten some airplane meals that might lead one to consider the possibility... ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
And is this 1000km radius precisely syncronized to all other 1000km radii around all airports in the world? No it need not be. I'm guessing that some may not even use NTP at all - or even be connected to the Internet to be able to use NTP. You are trying to paint an illusion that all clocks in the world tick over in unison. They don't - it's a cacophony with very few clocks beating in time. There is no point in discussing leap seconds with people that have a dillusional picture in their minds of all the words computers ticking over to a precise heartbeat that suddently starts to defibrillate when the leap second comes along in June or December. -paul On Sun, 2010-12-12 at 09:26 +, Poul-Henning Kamp wrote: In message 1292118117.24926.52.ca...@localhost, Paul Sheer writes: I choose the solution that makes my flight the cheepest. It is not a matter of flight being cheap or expensive. If you only synchronize computer on the order of minutes the modern airport ceases to function as such. During initial and terminal phases, a modern jetplane move 100m/s and many major airports have runway use in 30 second timeslots. You do the math. Radar stitching requires 3msec synchronization and timestamping, throughout the entire area being stitched, often a radius of up to 1000 km. You have just confirmed my suspicion that you have not a wisper of a clue about what you are pontificating about. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
In message 1292178523.24926.79.ca...@localhost, Paul Sheer writes: And is this 1000km radius precisely syncronized to all other 1000km radii around all airports in the world? No, I said: Radar stitching requires 3msec synchronization and timestamping, throughout the entire area being stitched, often a radius of up to 1000 km. Amongst your misrepresentations of my statement are: 1. 3msec becomes precisely syncronized 2. area being stitched becomes around all airports in the world You are trying to paint an illusion that all clocks in the world tick over in unison. No, I'm trying to point out that you are an ignoranmus in this context with your within some minutes is plenty blanket statements. -- 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] Leap Sec vs Y2K
On 12/12/2010 11:28, Paul Sheer wrote: And is this 1000km radius precisely syncronized to all other 1000km radii around all airports in the world? No it need not be. I'm guessing that some may not even use NTP at all - or even be connected to the Internet to be able to use NTP. All major airports are aligned to WGS84. You don't synchronize a position, after all. GPS can be used to synchronize time in the absence of NTP. NTP can be run on systems that aren't connected to the internet. Other time synchronization protocols exist. Some system not needing to conform to a standard is not an excuse for all systems to ignore that standard. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
No, I'm trying to point out that you are an ignoranmus in this context with your within some minutes is plenty blanket statements. If we misinterpret statements as axoims we will always be in a circle of discussing what the statement excluded. I am speaking for the 100's of millions of systems that still work fine when their clocks go a little skew, and also for the 99% of systems that still work fine when their clocks go a LOT skew. You are speaking for the handful of systems that break on a leap second. I have a strong suspician that if someone put a gun to your head and said Poul-Henning, we are not getting rid of leap seconds, but we are telling YOU to make sure those computers don't crash next December that you would find that Poul-Henning suddenly started asking all the right questions and having all sorts of brain waves. You are the most qualified to fix the problem. So go do that instead of trying to convince others that we should change our religious point of view. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
In message 1292189518.25675.85.ca...@localhost, Paul Sheer writes: I have a strong suspician that if someone put a gun to your head and said Poul-Henning, we are not getting rid of leap seconds, but we are telling YOU to make sure those computers don't crash next December that you would find that Poul-Henning suddenly started asking all the right questions and having all sorts of brain waves. I wish you would have read the list-archives before you launch such ridiculous straw-man arguments against me. You wouldn't need to use a gun, all you'd have to do is promise to pay the invoice I would send you. The argument against leap-seconds is only in terms of money and lives, wich money being the bigger of the two. Leap-Seconds are expensive, because the require manual intervention on operational short notice, and they will cost lives because humans makes mistakes. The question is: Are the minor inconvenience astronomers will suffer, by having to subscribe to a DUT distribution service, a bigger issue than the money and lives leap seconds will cost. Purist would say that until astronomers figure out how to kill people with DUT one, they will never win that argument. If Geophysicist announced leap seconds with at least 10 years firm notice, 90% of the problems they cause would be eliminated by the normal software update cycle. And now: Please shut your trap until you have taken time to find out what we are talking about here. 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 http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
A gentle reminder from your host -- please keep this discussion list somewhat technical. Every now and then it gets out of hand. /tvb http://www.LeapSecond.com ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On Dec 12, 2010, at 2:53 PM, Poul-Henning Kamp wrote: The question is: Are the minor inconvenience astronomers will suffer, by having to subscribe to a DUT distribution service, a bigger issue than the money and lives leap seconds will cost. I'd say a more basic question is that if the proponents of the ITU proposal actually believe in such economic and safety risks, why have they not circulated a single white paper making such a case? And if astronomers' concerns (albeit perhaps mosquitos to elephants) can be assuaged by a DUT distribution service, why go out of your way to strip the current such service out of the UTC standard without even speculating on its replacement? And if the real goal is to use UTC as a Trojan Horse (or maybe Nelson's Bridge) to decommission TAI, perhaps this might itself be a public talking point? If Geophysicist announced leap seconds with at least 10 years firm notice, 90% of the problems they cause would be eliminated by the normal software update cycle. As you say, there are more than one possible way to redefine UTC - and in fact, what you describe would be perfectly conforming to the current standard. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On 12/12/2010 18:11, Rob Seaman wrote: On Dec 12, 2010, at 2:53 PM, Poul-Henning Kamp wrote: If Geophysicist announced leap seconds with at least 10 years firm notice, 90% of the problems they cause would be eliminated by the normal software update cycle. As you say, there are more than one possible way to redefine UTC - and in fact, what you describe would be perfectly conforming to the current standard. Not quite. If leap seconds were announced 10 years in advance, DUT1 might exceed 1.0s if the prediction turns out to not be so good. Of course, that would be better aligned than a DUT of 6s or 7s if leap seconds were completely eliminated. It does seem like a reasonable compromise between different needs. It would preserve the low-precision users (like PHP) to be more or less as accurate as they are today without modification, while not affecting the high precision users over much since they need DUT1 today anyway (the biggest effect would be to change the format DUT1 is published in). DUT1 broadcasts might also be a problem as well, but it is unclear who use those in preference to the internet values Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On Dec 11, 2010, at 12:36 PM, Ian Batten wrote: Well, except for Active Directory, which sets an upper bound of five minutes on the maximum error. In practice, an AD deployment in which clocks were allowed to drift apart by minutes would behave very badly, so the typical target is less than that. Yes, in principle, an AD deployment could synch to an artificial time, or indeed to whatever time the AD masters drifted to (although, as they'd be drifting independently, there would be all sorts of problems with doing that, such as what happens to the clocks of clients when they switch from one slave server to another). In reality, it's much easier to synch to UTC or its local realisation than to some private timescale, especially in multi-site deployments. So I doubt there are many Windows networks of any scale that don't synch their clocks. Still, it's not as though either Windows or AD are widely used. N.B.: Windows computers bound to a domain synchronize to a domain controller, and ultimately to the primary domain controller. http://support.microsoft.com/kb/816042 - Jonathan ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
Then you must also pity 99.999% of the software users on the planet all of which are not affected by missing NTP configurations. Really? OSX ships with a functional NTP configuration, enabled by default, as do most Apple odds and ends (Airports, particularly). In order to have an OSX machine that is _not_ synch'd to UTC you'd need to take special action (and outbound firewalls that drop specific protocols are rare). Windows Time Service isn't as good by default, but it maintains resolution of a few seconds over a network (and has to, because otherwise AD/Kerberos) will hit trouble.Windows ships with the ability to synch the clock coarsely to the outside world (http://www.microsoft.com/windowsxp/using/setup/maintain/setclock.mspx) and it's usually turned on as part of group policy unless the AD server is acting as a clock reference. Even if home environments, it's routinely turned on. As a simple check, today it's very rare indeed to sort messages by the header Date: field and find that it yields an orders that scrambles a conversation, which imples that globally clocks are synch'd to at least the turnaround time in an email conversation, and that wasn't true in the past (yes, I realise the rise of WebMail services is a factor in this as well). There have been several incidents of consumer CPE automatically synching via NTP to unsuspecting public-access server including, oh, look, our very own Paul-Henning Kamp to whom you are responding (http://www.engadget.com/2006/04/09/danish-server-admin-exposes-d-links-ntp-vandalism/). Indeed, today, I'd be surprised if there were many homes that didn't have a stratum-three ntp server, such is its prevalence in CPE. I'm surprised by your claim that Telcos don't do NTP, because my first dealings with NTP twenty-odd years ago were related to a major European telco who insisted that all management systems by synchronised, partly because of the legal implications of getting billing time-periods wrong and partly because of the need to do log correlation for event handling, and every telco project I've been involved in since has had sub-1s resolution and precision timestamping in the specification. ian ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On Sat 2010-12-11T08:18:54 +, Poul-Henning Kamp hath writ: I have a script that dumps the timestamps of each of a number of servers where I work; this is a recent result: Those clocks span about 10 seconds. Why are you not running NTP properly ? That question is not fair without further investigation. If those are Windows boxes then even wikipedia says that's normal. http://en.wikipedia.org/wiki/Network_Time_Protocol#Microsoft_Windows (Note that this is not a deficiency of Windows per se, but rather an indication that Windows runs on almost anything, including some motherboards with piece-of-crap designs for the system clock.) I have a Windows XP box which drifts by about 3000 ppm, but only when the guide camera application is running. W32Time is utterly incapable of keeping this system on time, so I tried one of the implementations of the current NTP code. Given that the maximum drift allowed by NTP is 500 ppm it is also not capable of keeping the system clock any closer than a nasty sawtooth waveform with an amplitude of around a second. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +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] Leap Sec vs Y2K
I'm surprised by your claim that Telcos don't do NTP, [...] I'm sure many do. My point is that, if one's starting premise is that most systems in the world *require* second-accurate syncronization, this is simply untrue. In fact most work perfectly well even when they drift by minutes, and a significant portion of critical systems do drift by minutes in practice. This is orders of magnitude more error than any leap second. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
This is orders of magnitude more error than any leap second. One problem with the kinda works attitude is that is a barrier to entry for people whose systems need to work correctly to a much higher I agree: the kinda works attitude is indeed such a barrier. However the kinda works attitude is not like a bug in a piece of software that you can fix in the next version. Attitudes are entrenched into culture and changing culture is the MOST difficult thing to change. Premising ANY solution on a change in culture is really silly. Computer scientists everywhere need to accept that they are the elite, that everyone else is stupid, and that this is the way it is going to stay, FOREVER. Apply this principle as follows: ACCEPT that there are servers and desktops all over the world are MISCONFIGURED and do NOT have second-accurate syncronization, and are NEVER going to have second-accurate syncronization. Most of the software industry accepted this fact decades ago along with hundreds of other limitations that software everywhere is written to work around. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
In message 1292102703.24926.29.ca...@localhost, Paul Sheer writes: Apply this principle as follows: ACCEPT that there are servers and desktops all over the world are MISCONFIGURED and do NOT have second-accurate syncronization, and are NEVER going to have second-accurate syncronization. Ohh we do, we most certainly do. But that does not allow us to ignore the servers which are synchronized and which need to be synchronized to work. Poul-Henning PS: Your caps-lock seems to be flakey. -- 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] Leap Sec vs Y2K
On Dec 11, 2010, at 1:32 PM, Warner Losh wrote: So the magnitude of this kinda works degrades as the time synchronization between systems gets worse. Kinda works - you could be describing UTC redefined without leap seconds :-) Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
This is because by-and-large software is written for the lowest common denominator. I am reminded of Spinal Tap's We're cancelled in Boston, but don't worry, it's not a big college town. Examples of protocols that get distinctly tetchy in the face of poor clock synch are, as has already been mentioned without seeming to upset your certainty, NFS (the computing glue of the nineties) and Kerberos/AD (the computing glue of the noughties). The fomer needs clock synch except the documentation doesn't tell you (until you find make misbehaving because mtimes are being set by the client, not the server), and the latter documents it and drove the adoption of better time synch. How you can use phrase like by and large when you're having to ignore two of the most significant distributed protocols of the past twenty years is something of a mystery. ian ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On 12/11/2010 17:18, Poul-Henning Kamp wrote: In message1292109115.24926.42.ca...@localhost, Paul Sheer writes: On Sat, 2010-12-11 at 22:35 +, Poul-Henning Kamp wrote: But that does not allow us to ignore the servers which are synchronized and which need to be synchronized to work. I disagree. It very much allows us to ignore those servers from a standards point of view. Which bit of need don't you understand ? Are you happy with the ATC servers used to land your plane being within some minutes of each other ? Yes. We sometimes can ignore those machines that don't care. However, if those machines drive the time-keeping software on the machines we use, then we do care about them. Some machines can tolerate minutes of difference, but some machines cannot tolerate even millisecond skew. The former can't be used to justify it being impossible to build the latter. ATC systems being unsynchronized means that planes crash; clearly a situation we want to avoid. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
Which bit of need don't you understand ? Are you happy with the ATC servers used to land your plane being within some minutes of each other ? There are two choices: A. the software was written to be safe assuming precise time syncronization AND the time was reliably and precisely syncronized. B. the software was written to be safe regardless of poor time syncronization. I choose the solution that makes my flight the cheepest. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On Dec 11, 2010, at 6:36 PM, Warner Losh wrote: ATC systems being unsynchronized means that planes crash; clearly a situation we want to avoid. Presumably they do have layers on layers of error handling built in, as well as contingent procedures - perhaps even traditional sextant navigation relying on access to a timescale that approximates Greenwich Mean Time :-) It is possible for brittle system design as well as sloppy timekeeping to both be undesirable... Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On Sun, 2010-12-12 at 01:20 +, Ian Batten wrote: This is because by-and-large software is written for the lowest common denominator. NFS (the computing glue of the nineties) and Kerberos/AD (the computing glue of the noughties). [...] please understand that I am only trying to break up the illusion that all the worlds computer clocks tick over in unison. indeed with these protocols, can I guess that, 1. syncronization is only required to within a couple of seconds 2. syncronization is only required between client and server within the local LAN. 3. syncronization does not need to absolutely represent real time. 4. leap seconds, or the absence thereof, make no difference -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Leap Sec vs Y2K
Ken Seidelmann, John Seago, and I addressed this in our papers and in the recent editorial in Space News. The Y2K effort was necessary. Everyone knew that we could not just watch what might happen and catch up afterwards. In the case of leap seconds, no one knows what the real consequences might be if we changed, and change is not necessary as it was for years that stopped at 99. We can just let things be as they have been for nearly 40 years. Dave Finkleman Senior Scientist Center for Space Standards and Innovation Analytical Graphics, Inc. 7150 Campus Drive Colorado Springs, CO 80920 Phone: 719-510-8282 or 719-321-4780 Fax: 719-573-9079 Discover CSSI data downloads, technical webinars, publications, and outreach events at www.CenterForSpace.com. -Original Message- From: leapsecs-boun...@leapsecond.com [mailto:leapsecs-boun...@leapsecond.com] On Behalf Of leapsecs-requ...@leapsecond.com Sent: Friday, December 10, 2010 10:01 AM To: leapsecs@leapsecond.com Subject: LEAPSECS Digest, Vol 48, Issue 2 Send LEAPSECS mailing list submissions to leapsecs@leapsecond.com To subscribe or unsubscribe via the World Wide Web, visit http://six.pairlist.net/mailman/listinfo/leapsecs or, via email, send a message with subject or body 'help' to leapsecs-requ...@leapsecond.com You can reach the person managing the list at leapsecs-ow...@leapsecond.com When replying, please edit your Subject line so it is more specific than Re: Contents of LEAPSECS digest... Today's Topics: 1. Re: php breaks if UTC has no leap seconds? (p...@2038bug.com) 2. Re: php breaks if UTC has no leap seconds? (Richard B. Langley) 3. Re: php breaks if UTC has no leap seconds? (Paul Sheer) -- Message: 1 Date: Fri, 10 Dec 2010 16:21:43 + From: p...@2038bug.com Subject: Re: [LEAPSECS] php breaks if UTC has no leap seconds? To: Leap Second Discussion List leapsecs@leapsecond.com Message-ID: 1970411972-1291998043-cardhu_decombobulator_blackberry.rim.net-11035931 7...@bda950.bisx.prod.on.blackberry Content-Type: text/plain; charset=Windows-1252 WH-WH-Wht Contractors spent millions of hours wading through hundreds of millions of lines of code adding missing century digits. Thousands of Cobal programmers lost there jobs after Y2K. Every organisation that managed any kind of computer system had to do testing to verify that the systems would work through Y2K and replace them otherwise. My company managed such a system. Were you living under a rock then -paul Sent from my BlackBerry? by Boost Mobile -Original Message- From: Gerard Ashton ashto...@comcast.net Sender: leapsecs-boun...@leapsecond.com Date: Fri, 10 Dec 2010 11:03:10 To: Leap Second Discussion Listleapsecs@leapsecond.com Reply-To: Leap Second Discussion List leapsecs@leapsecond.com Subject: Re: [LEAPSECS] php breaks if UTC has no leap seconds? On 12/10/2010 10:15 AM, Peter Vince wrote: Hello Paul, I'd be interested if you have some examples of of Y2K bugs that were fixed before they became a problem. In my very limited experience, I wasn't affected by any, nor aware of them. Peter On 10 December 2010 01:55, Paul Sheerp...@2038bug.com wrote: Everybody said y2k was going to break everything. In the end, it was a non-event :) It was a non-event BECAUSE the industry spent enormous $$ to fix all the zillions of Y2K bugs in time. It was still a disaster from an expendature point of view. (Does anyone need to even explain this) -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs I worked for IBM at the time. Many older personal computers in use by staff were discarded because it would have been too difficult to teach all the staff the special tricks to keep them limping along when 2000 arrived. Gerry Ashton ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs -- Message: 2 Date: Fri, 10 Dec 2010 12:18:58 -0400 From: Richard B. Langley l...@unb.ca Subject: Re: [LEAPSECS] php breaks if UTC has no leap seconds? To: leapsecs@leapsecond.com Message-ID: 20101210121858.20027gdb2wlwb...@webmail.unb.ca Content-Type: text/plain; charset=ISO-8859-1; DelSp=Yes; format=flowed USNO predicts UT1-UTC. In Bulletin A http://maia.usno.navy.mil/ser7/ser7.dat, they predict daily values for a year in advance but only provide an error estimate up to 40 days in advance. Elsewhere http://maia.usno.navy.mil/ser7/deltat.preds, longer-term predictions are given; supposedly updated annually. -- Richard Langley Quoting Warner Losh i...@bsdimp.com: On 12/09/2010 17:35, Rob Seaman wrote: On Dec 9, 2010, at 3:53 PM, Steve Allen wrote: This is the first
Re: [LEAPSECS] Leap Sec vs Y2K
In message 3b33e89c51d2de44be2f0c757c656c8809cda...@mail02.stk.com, Finklema n, Dave writes: We can just let things be as they have been for nearly 40 years. Sure, no argument from here: Please shut down your Internet connection and any cell-phones you might have, and don't use them ever again :-) The crucial change in exactly the last 40 years, is that computers of all sizes are communicating and the applications we want them to run for us, very much need to know and agree what time it is. 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 http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
very much need to know and agree what time it is. Yes but mostly only to an accuracy of minutes. -paul Sent from my BlackBerry® by Boost Mobile -Original Message- From: Poul-Henning Kamp p...@phk.freebsd.dk Sender: leapsecs-boun...@leapsecond.com Date: Fri, 10 Dec 2010 18:42:42 To: Leap Second Discussion Listleapsecs@leapsecond.com Reply-To: Leap Second Discussion List leapsecs@leapsecond.com Subject: Re: [LEAPSECS] Leap Sec vs Y2K In message 3b33e89c51d2de44be2f0c757c656c8809cda...@mail02.stk.com, Finklema n, Dave writes: We can just let things be as they have been for nearly 40 years. Sure, no argument from here: Please shut down your Internet connection and any cell-phones you might have, and don't use them ever again :-) The crucial change in exactly the last 40 years, is that computers of all sizes are communicating and the applications we want them to run for us, very much need to know and agree what time it is. 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 http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
In message 211674-1292007095-cardhu_decombobulator_blackberry.rim.net-4042 478...@bda950.bisx.prod.on.blackberry, p...@2038bug.com writes: very much need to know and agree what time it is. Yes but mostly only to an accuracy of minutes. Pray tell what authority you have for this pronouncement ? -- 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] Leap Sec vs Y2K
On Dec 10, 2010, at 11:42 AM, Poul-Henning Kamp wrote: In message 3b33e89c51d2de44be2f0c757c656c8809cda...@mail02.stk.com, Finklema n, Dave writes: We can just let things be as they have been for nearly 40 years. Sure, no argument from here: Please shut down your Internet connection and any cell-phones you might have, and don't use them ever again :-) (Passing over the obvious response that the Internet and cell phones have been demonstrated to function with the current definition of UTC.) This was taken out of context: On Dec 10, 2010, at 11:22 AM, Finkleman, Dave wrote: The Y2K effort was necessary. Everyone knew that we could not just watch what might happen and catch up afterwards. In the case of leap seconds, no one knows what the real consequences might be if we changed, and change is not necessary as it was for years that stopped at 99. We can just let things be as they have been for nearly 40 years. Which is to say that the schedule for Y2K remediation was forced. We get to choose when to address a possible redefinition of civil timekeeping. It is clear that consensus does not yet exist. PHK continues: The crucial change in exactly the last 40 years, is that computers of all sizes are communicating and the applications we want them to run for us, very much need to know and agree what time it is. Not disputed. What is the concept of operations for the pertaining timescale(s)? What are the requirements? Innumerable clocks based on different types of interval timekeeping as well as on earth orientation exist. Pretending time doesn't come in different flavors is not going to work. System engineering provides tools to reach consensus on the problem before entertaining possible solutions. Why not use those tools? Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On 11 Dec 2010 at 0:40, Paul Sheer wrote: At the ISP I consult for there are about 20 servers serving 60,000 customers. Their clocks routinely go out of sync and it doesn't affect service. I have a script that dumps the timestamps of each of a number of servers where I work; this is a recent result: Fri Dec 10 23:07:12 EST 2010 Fri Dec 10 23:07:11 EST 2010 Fri Dec 10 23:07:06 EST 2010 Fri Dec 10 23:07:11 EST 2010 Fri Dec 10 23:07:12 EST 2010 Fri Dec 10 23:07:15 EST 2010 Fri Dec 10 23:07:16 EST 2010 Fri Dec 10 23:07:15 EST 2010 Fri Dec 10 23:07:15 EST 2010 Fri Dec 10 23:07:15 EST 2010 Fri Dec 10 23:07:12 EST 2010 Fri Dec 10 23:07:12 EST 2010 Fri Dec 10 23:07:13 EST 2010 Fri Dec 10 23:07:13 EST 2010 Fri Dec 10 23:07:12 EST 2010 Fri Dec 10 23:07:13 EST 2010 Fri Dec 10 23:07:13 EST 2010 They're more in sync than they were at various times in the past, due in part to my own nagging of the sysadmin to get automatic time syncing in place consistently (it sometimes takes a good deal of fighting to get them to do that, as they are always deathly afraid of it corrupting the database or something, due to the time being set backward while it's running; this has always proved unfounded, as the time syncing is now fully in place even on the database servers with no ill effect). Still, there's a good deal of drift in between auto- syncs, leading to a ten second gap between the most extreme outliers, though most servers are within a five second span. A leap second will be lost in the noise here, resulting merely in the next regular adjustment going one second more (or less) than it would have otherwise, with a different absolute magnitude on each server depending on its own drift. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/ ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
