Re: [LEAPSECS] Longer horizon
Found a recording of the 7 pips on You Tube as witnessed at Bush House (now vacated): http://www.youtube.com/watch?v=FTnMLiOqNKk And other You Tube leap second videos: http://www.youtube.com/watch?v=1scvSm3Em3U http://www.youtube.com/watch?v=xfhHPaZb8MI http://www.youtube.com/watch?v=RyPZldmAAG8 (Interesting one.) -- Richard On 11-Jul-12, at 8:38 AM, Peter Vince wrote: Hi Richard, Yes, BBC Radio 4 Long Wave on 198 KHz certainly did. David Malone in Ireland grabbed the LF spectrum and sent a message to the list at 13:25 (British Summer Time) on the 1st of July - his spectrogram at http://www.maths.tcd.ie/~dwmalone/time/leap2012/spectrogram.png clearly shows the six short and seventh longer pips. Speaking to my colleague in Broadcasting House who used to be their Time Lord, they have a new system which is completely automatic, and designed to correctly handle leap-seconds - and it seems to have worked - yippee! Peter On 11 July 2012 12:27, Richard B. Langley l...@unb.ca wrote: Peter: Did any BBC radio station transmit the 7-pip Greenwich Time Signal for the leap second? I did check the iPlayer repeats from BBC Radios 1 through 5 but it appears that these stations, at least via iPlayer, didn't use it. Unlike for the 2008 leap second when Radio 5 made a big deal about it. -- Richard Langley ___ 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.fredericton.ca/ | - ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Longer horizon
On 11 July 2012 02:42, Michael Spacefalcon msoko...@ivan.harhan.org wrote: Of course. However, this issue would only exist if the external time input is an ASCII string or struct in HH:MM:SS format, and I have yet to see a system that uses such formats for time interchange. All systems that I'm familiar with use time-as-a-real-number formats instead: JD, MJD, time_t, NTP, etc. SF We use a twenty-year-old system that does just that - outputs an ASCII string once a second at 300 baud on a good old-fashioned serial line. Admittedly this was not designed for computer use, but for hardware that will then drive either physical clocks, or produce SMPTE/EBU time code (as used by radio and television broadcasting). Peter (BBC, London) ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Longer horizon
Peter: Did any BBC radio station transmit the 7-pip Greenwich Time Signal for the leap second? I did check the iPlayer repeats from BBC Radios 1 through 5 but it appears that these stations, at least via iPlayer, didn't use it. Unlike for the 2008 leap second when Radio 5 made a big deal about it. -- Richard Langley On 11-Jul-12, at 6:27 AM, Peter Vince wrote: On 11 July 2012 02:42, Michael Spacefalcon msoko...@ivan.harhan.org wrote: Of course. However, this issue would only exist if the external time input is an ASCII string or struct in HH:MM:SS format, and I have yet to see a system that uses such formats for time interchange. All systems that I'm familiar with use time-as-a-real-number formats instead: JD, MJD, time_t, NTP, etc. SF We use a twenty-year-old system that does just that - outputs an ASCII string once a second at 300 baud on a good old-fashioned serial line. Admittedly this was not designed for computer use, but for hardware that will then drive either physical clocks, or produce SMPTE/EBU time code (as used by radio and television broadcasting). Peter (BBC, London) ___ 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.fredericton.ca/ | - ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Longer horizon
On 9 Jul 2012 at 14:31, Warner Losh wrote: First, the current right database can't be updated in place: you have to restart. M$ Windows people are used to constantly having to restart their systems at the most trivial updates... *Nix folks are spoiled! -- == 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
Re: [LEAPSECS] Longer horizon
On Jul 10, 2012, at 7:09 AM, Warner Losh wrote: On Jul 10, 2012, at 7:12 AM, Daniel R. Tobias wrote: On 9 Jul 2012 at 14:31, Warner Losh wrote: First, the current right database can't be updated in place: you have to restart. M$ Windows people are used to constantly having to restart their systems at the most trivial updates... *Nix folks are spoiled! I think that you've got it backwards. M$ developers have been spoiled that the don't have to tackle the hard problem of not forcing a restart. Forced restarts kill your '9's of uptime. Really? Changing all the clocks on the planet is deemed easier than updating some software to be responsive to a HUP? We have a git seminar here tomorrow. Software has power build tools that are the envy of other engineering disciplines. The woman on the Clapham omnibus is not supposed to care whether it's dark outside during the daytime, but a bunch of programmers tossing around cute jargon like *Nix and M$ can't arrange to update a record in a database at runtime? Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Longer horizon
On Jul 10, 2012, at 8:26 AM, Rob Seaman wrote: On Jul 10, 2012, at 7:09 AM, Warner Losh wrote: On Jul 10, 2012, at 7:12 AM, Daniel R. Tobias wrote: On 9 Jul 2012 at 14:31, Warner Losh wrote: First, the current right database can't be updated in place: you have to restart. M$ Windows people are used to constantly having to restart their systems at the most trivial updates... *Nix folks are spoiled! I think that you've got it backwards. M$ developers have been spoiled that the don't have to tackle the hard problem of not forcing a restart. Forced restarts kill your '9's of uptime. Really? Changing all the clocks on the planet is deemed easier than updating some software to be responsive to a HUP? You really don't understand the depth of the leap second issue in software. If it were that easy, it would have actually been solved. People just don't care, and that's the problem. You care a whole lot, but aren't out there fixing bugs in code, or driving adaptation of new standards that cope with leap seconds rather than forcing people into picking which way to violate them is the least bad for them. Until people care enough to fix the standards and the attitude, leap seconds will continue to be broken in software. We have a git seminar here tomorrow. Software has power build tools that are the envy of other engineering disciplines. The woman on the Clapham omnibus is not supposed to care whether it's dark outside during the daytime, but a bunch of programmers tossing around cute jargon like *Nix and M$ can't arrange to update a record in a database at runtime? The problems run deeper than just that. There's the problem of distribution. There's the cold shelf problems. There's the problems of actually getting people to give a shit and fix their broken code when you report bugs on it. There's the problem of getting people to actually test that their locking doesn't cause deadlock on lead-second day. Really, I've been there done that and tried to effect change in this area. You haven't. So please, keep the snarky oh, it's just a SIGHUP comments to yourself, ok? Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Longer horizon
Warner, Your message seems snarkier (more cranky, irritable) than mine. You speculate on what I do or don't understand, and on what I am or am not doing. All of these are irrelevant. I'm a big fan of FreeBSD and PHK's MD5 password hashing, but still disagree with his position on leap seconds :-) There has been only one proposal on the table for thirteen years. The proposal is unacceptable. Its backers do not participate here, where we have discussed numerous alternatives. It isn't the astronomers (themselves mostly software professionals) who have been unwilling to consider the options. If this is a software issue it would help if software solutions were permitted to be discussed, and not be rejected out of hand. That said, the ITU proposal has precious little to do with software. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Longer horizon
On Jul 10, 2012, at 11:17 AM, Rob Seaman wrote: Your message seems snarkier (more cranky, irritable) than mine. You speculate on what I do or don't understand, and on what I am or am not doing. All of these are irrelevant. I'm a big fan of FreeBSD and PHK's MD5 password hashing, but still disagree with his position on leap seconds :-) Basically, the problems are deeper seeded than what a simple SIGHUP would fix. They are deeply engrained in the culture of the software world, and failing to acknowledge that fact, or being dismissive about how easy it is to implement doesn't help. That's the point I was trying to make. Sorry if I was too grumpy in making it. There has been only one proposal on the table for thirteen years. The proposal is unacceptable. Its backers do not participate here, where we have discussed numerous alternatives. It isn't the astronomers (themselves mostly software professionals) who have been unwilling to consider the options. If this is a software issue it would help if software solutions were permitted to be discussed, and not be rejected out of hand. That said, the ITU proposal has precious little to do with software. I've been trying to propose other things that would make things work better most of that time. That's where the 'tell the world about it sooner' thread has come from. The longer that you know in advance, the better things are all around. Leap seconds aren't just a time zone thing, they wind up impacting more things than you might naively thing had you not implemented a system that tried to get them right. It also helps you understand the consequences of missing knowledge at different parts in the system that you might think is always there, but turns out to not be in a number of interesting cases. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Longer horizon
On 10 Jul 2012 at 8:38, Warner Losh wrote: You really don't understand the depth of the leap second issue in software. If it were that easy, it would have actually been solved. People just don't care, and that's the problem. Actually, from what I've seen and heard about this year's crop of bugs, server crashes, etc., relating to the leap second, the big problems come when the developers know and care just enough to be dangerous. If you take the total dumbass approach to leap seconds, like you don't even know they exist, or pretend they don't exist even though you've heard of them, then in most cases your hardware and software will muddle through just fine. It might wind up a second off after the leap second happens, but that will just be an additional one-second delta added (or subtracted) on to whatever other delta might exist due to normal clock drift, which will eventually get corrected (either in an abrupt jump or smoothed out, depending on the system software) when the system next polls whatever external time source it periodically syncs to (if it does this at all). Or maybe the end user will just once in a while set the clock manually to the top of the hour when the theme song to his favorite sitcom comes on the boob tube. At any rate, it will eventually take the leap second into account, and nothing will crash and burn in the meantime. It's only when you actually attempt to get the system to account for the leap second immediately and precisely when it happens that you end up having to code in something convoluted that only runs every couple of years, with all the potential to screw it up and cause a major crash of some sort. Probably only less than 1/10 of 1 percent of systems actually need this degree of precision, so the other 99.9% are best off not even trying to do anything special for the leap second, though some defensive programming to keep from crashing if fed something like 23:59:60 from a remote site would be desirable. -- == 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
Re: [LEAPSECS] Longer horizon
Dan wrote: It's only when you actually attempt to get the system to account for the leap second immediately and precisely when it happens that you end up having to code in something convoluted that only runs every couple of years, with all the potential to screw it up and cause a major crash of some sort. Probably only less than 1/10 of 1 percent of systems actually need this degree of precision, so the other 99.9% are best off not even trying to do anything special for the leap second, though some defensive programming to keep from crashing if fed something like 23:59:60 from a remote site would be desirable. Leap seconds happen abou twice as often as leap year corrections. Think how long folks screwed up leap year calculations in code... It's not that difficult to properly handle leap seconds. There are a few local policy issues to think of (smear, just handle it at the right time, use a different timescale, ...) but it boils down to making an evaluation and a decision, then implementing and testing it. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Longer horizon
Daniel R. Tobias d...@tobias.name wrote: Actually, from what I've seen and heard about this year's crop of bugs, server crashes, etc., relating to the leap second, the big problems come when the developers know and care just enough to be dangerous. Yup. If you take the total dumbass approach to leap seconds, like you don't even know they exist, or pretend they don't exist even though you've heard of them, then in most cases your hardware and software will muddle through just fine. It might wind up a second off after the leap second happens, but that will just be an additional one-second delta added (or subtracted) on to whatever other delta might exist due to normal clock drift, which will eventually get corrected (either in an abrupt jump or smoothed out, depending on the system software) when the system next polls whatever external time source it periodically syncs to (if it does this at all). That's exactly what happens on my current systems. It's only when you actually attempt to get the system to account for the leap second immediately and precisely when it happens that you end up having to code in something convoluted that only runs every couple of years, with all the potential to screw it up and cause a major crash of some sort. Probably only less than 1/10 of 1 percent of systems actually need this degree of precision, so the other 99.9% are best off not even trying to do anything special for the leap second, Finally, a voice of reason - that's exactly how I feel. Nice to hear that there is at least one other person who agrees with me, at least in this regard. though some defensive programming to keep from crashing if fed something like 23:59:60 from a remote site would be desirable. Of course. However, this issue would only exist if the external time input is an ASCII string or struct in HH:MM:SS format, and I have yet to see a system that uses such formats for time interchange. All systems that I'm familiar with use time-as-a-real-number formats instead: JD, MJD, time_t, NTP, etc. SF ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Longer horizon
(1) Push for a longer time horizon for leap second announcements. For compute guys, the more lead time the better. 6 months is just too short to meet deployment realities. 5 years would cover most bases, with 10 years covering all but a vanishingly small number. Even 2-3 years would help for two reasons. (1) it would mean only one upgrade during a 5 year deployment rather than possibly 10. (2) It would allow management to plan and budget for extra resources needed to ensure leapseconds will work this time. I don't understand this area. How often do systems need to get updated to track time zone changes? Maybe tracking leap second announcements every 6 months would help scheduling updates. Has the US Congress stopped playing with DST rules? When was the last change in Indiana? How often do things change in the EU or the rest of the world? Or are we talking about systems that don't use time zones? If so, what sorts of things do they do? How big is the problem space at the intersection of time matters but updating a table is hard? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
