Re: [LEAPSECS] php breaks if UTC has no leap seconds?
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 Sheer p...@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
Re: [LEAPSECS] php breaks if UTC has no leap seconds?
On 12/09/2010 17:35, Rob Seaman wrote: On Dec 9, 2010, at 3:53 PM, Steve Allen wrote: This is the first example I've come across where a widely used API will break if UTC does not continue to have leap seconds. Has anyone even considered a Y2K style inventory? Absence of evidence is not...oh, what's the point? Keep in mind that while a code change would required to fetch DUT1 from the internet or other source, the API could continue to function, but with an increased uncertainty as the date is farther into the future. If this is an important number to know, I'm sure someone will publish a model that tries to approximate dUT1 and gives an uncertainty range that presumably expands the further into the future we go. You're correct about the question: How many of these interfaces are there, and what is the implication for increasing the error in the present calculation from 1s? For php, I doubt anybody would care for the cases likely to be in error... For other things, likely they care more. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
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
Re: [LEAPSECS] php breaks if UTC has no leap seconds?
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 example I've come across where a widely used API will break if UTC does not continue to have leap seconds. Has anyone even considered a Y2K style inventory? Absence of evidence is not...oh, what's the point? Keep in mind that while a code change would required to fetch DUT1 from the internet or other source, the API could continue to function, but with an increased uncertainty as the date is farther into the future. If this is an important number to know, I'm sure someone will publish a model that tries to approximate dUT1 and gives an uncertainty range that presumably expands the further into the future we go. You're correct about the question: How many of these interfaces are there, and what is the implication for increasing the error in the present calculation from 1s? For php, I doubt anybody would care for the cases likely to be in error... For other things, likely they care more. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs === Richard B. LangleyE-mail: l...@unb.ca Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ === ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] php breaks if UTC has no leap seconds?
It's very concerning if Y2K has been recast as a myth among technical professionals, [...] Concerning indeed: KCBI a Christian radio chanel recently proclaimed: The Y2K is an example of scientists predicting disaster when there was none. This is just like global warming. There have been numerous media articles that Y2K was an example of paranoia. If the government had spend the money to re-inforce the dykes in new orleans, people would have later said: What a waiste of tax payer money: Look - there went a Cat 5 hurrican and nothing happened. Go figure. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] php breaks if UTC has no leap seconds?
I'm getting emotional to prepare for Y2038 Please don't take offense -paul On Fri, 2010-12-10 at 16:21 +, p...@2038bug.com wrote: 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 ___ 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] php breaks if UTC has no leap seconds?
On Dec 10, 2010, at 9:18 AM, Richard B. Langley wrote: 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. This is another good example of the absence of due diligence related to the ITU proposal. Any even halfway competent engineering plan would discuss issues related to contingent infrastructure changes. If UTC is redefined to lack leap seconds, the logistics of predicting and announcing UT1-UTC (and similar quantities) will become much more critical. The details should be settled in advance. Systems engineering best practices are a way to avoid problems before they occur. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] New Horizons in Time Domain Astronomy
Timekeeping is a means to an end. We've often discussed logistical issues. There are more fundamental issues, many of which will be topics of IAU Symposium 285 at Oxford (UK), 19-23 Sep 2011: http://www.physics.ox.ac.uk/timedomainconf The Astronomer Royal, Martin Rees, will deliver a public lecture titled What time is it?. Pre-registration is open. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] php breaks if UTC has no leap seconds?
In message 4d024bb8.9060...@bsdimp.com, Warner Losh writes: On 12/09/2010 17:35, Rob Seaman wrote: Rob, First, a point of semantics: I don't think leap seconds can break php further than it already is. Second, there is no basis for claiming that php breaks when you are talking about some random library function. The language itself is unfortunately unharmed. Third, you have whined and complained about all the breakage for years now, this is the first piece of concrete code you have ever presented. Not exactly a bumper crop, but congratulations are presumably still in order. But I have to disappoint you, I don't think a random piece of PHP code will convince anybody anywhere... -- 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] 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
[LEAPSECS] Affect of Y2K on programmers' attitude toward time documents
One effect I recall from the Y2K prevention effort actually relates to 29 February 2000. There was considerable discussion among programmers as to whether that date existed or not, and there was enough disagreement among the computer language manuals and the like that programmers lost confidence in publications directed toward the software community, and sought primary sources such as Inter gravissimas and the British Calendar (New Style) Act 1750. I suspect this rude awakening to the need to inspect primary sources may be adding to the present discontent with the lack of transparency of the ITU, and the inability to obtain what public documents they have for free or for reasonable prices. Gerry Ashton ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] php breaks if UTC has no leap seconds?
On Dec 10, 2010, at 11:22 AM, Poul-Henning Kamp wrote: Third, you have whined and complained about all the breakage for years now, this is the first piece of concrete code you have ever presented. It wasn't my example. The responsibility for due diligence doesn't rest with those supporting the status quo. If you deem my emails unworthy of your time - don't read them. Rather, proponents of redefining UTC have asserted unsubstantiated risks. The experiment has been conducted a couple of dozen times of what happens to systems worldwide during a leap second. No such experiment is contemplated even in the laboratory of what will happen as DUT1 grows. No software systems inventory is planned. No professional curiosity has been demonstrated. Due diligence is laughably absent for this proposal. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Affect of Y2K on programmers' attitude toward time documents
On Fri 2010-12-10T14:03:08 -0500, Gerard Ashton hath writ: I suspect this rude awakening to the need to inspect primary sources may be adding to the present discontent with the lack of transparency of the ITU, and the inability to obtain what public documents they have for free or for reasonable prices. The proprietary and uncommunicative nature of the ITU-R does not help, but it is not the only problem. Even open processes with freely-available specifications are not a panacea. Just today the IESG closed the CALSIFY WG. This was created 5 years ago in order to update RFC 2445. One reason that we now have RFC 5545 is that despite the openly-published examples of how repeating calendar events should have been represented, many vendors chose to implement them using a different syntax. Even now with RFC 5545 the strategies for attaching media to calendar events differ from one implementation to another. Nothing works if people don't care to follow the standards. That is the current situation with UTC and leap seconds. That's why I think the ITU-R should abandon the name UTC if they abandon the leap seconds. The fact that things have changed needs to be patently obvious before there is hope of motivation. -- 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
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
