GPS navigation uses GPS time, which doesn't have leap seconds. Leap seconds shouldn't have any effect on GPS navigation. One can also derive UTC from GPS, because both a pending leap second flag and a GPS-UTC offset are provided. The GP was apparently referring to systems which use GPS receivers to derive UTC time.
A day is one Earth revolution, relative to Sol. It varies slightly because of a number of factors, and is called UT1. UT2R is a smoothed version, and but variations due to unpredictable events are left. UTC is based on the atomic second. The value chosen for the atomic second is such that, on average, there have been slightly more than 86400 of them in a day. So, just as a year is more than 365 days (a day is slightly shorter than 1/365 year), so an occasional leap day needs to be added, so to an occasional leap second is needed.
Contrary to what the GP said, the solar day is not too fast. It is what it is, by definition. Rather, the second is a bit too short.
On average, since the leap second was introduced in 1972, one has been needed about every 18 months. Over the long term, that rate will increase as tidal acceleration slows the earth. 1 sec/18 months ~= 2e-8, so that's how much the second has been off on average since 1972. The atomic value for the second is 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom. So, a better value might have been 9,192,631,967, which would make us about even to date. (Although, since leap seconds aren't distributed evenly, they would still have occurred, both positive and negative, just not as many.) The original value was based on measurements made over less than 3 years, and has worked for some shorter periods (there were no leap seconds between 1999 and 2004, for example), but the value chosen has proven to be too short over the 40 years of leap seconds.
I didn't say an application would see:60. But, it exists in UTC. The problem is that generally, *nix can't handle the truth. So, kernels either step time backwards by a second, or stretch time around a positive leap second. Both cause problems if accurate timekeeping is important.
"That's because the Earth's average rate of rotation is just a little slower than one solar revolution per day."
You're confusing the need for leap seconds with sidereal time. But note, the Earth actually rotates faster than one solar revolution per day.
Leap seconds are needed because when we changed the definition of a second from 1/86400th of a day to one based on a characteristic of the Caesium atom, a poor value was chosen, and the Earth is slowing down over time, primarily due to tidal acceleration by the moon.
Leap second happens at midnight UTC, not at midnight local time. You posted about 8 minutes before the leap second occurred. I'm guessing you still missed it, though.
UTC is defined to be linked to Sol. It is used for things which depend on that characteristic (like astronomy and celestial navigation). If civil time doesn't need to be linked that closely, then it doesn't need to use UTC.
You mean the GP linked article, where it is said "This affects RHEL 6 and other distros running newer kernels (newer than approx 2.6.26)"? Or where is says that Debian Stable (Squeeze, kernel 2.6.32) is affected?
That would subtract a second. While that is possible, it's never happened. In any case, leap seconds, added or subtracted, are preferably at midnight on the last day of June or December, second preference last day of March or September. They are, however, allowed to happen on the last day of any month.
"A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September." -
ITU-R Recommendation TF.460-4
Poorly written software only expects seconds to go from 0-59. Positive leap seconds are counted 23:59:59 -> 23:59:60 -> 0:0:0. Leap seconds have been around since 1972, the same year Unix was rewritten in C. There's been plenty of time to get things right.
As if the computer did this on it's own. Might as well argue that you didn't hire that hit man, he just acted based on hearing the mechanical vibrations caused by electrons going over the phone line.
"Did you interact with someone if your telephone call to party A was carried on the same transatlantic phone cable as someone else's call to party B?"
Poor analogy. It would only work if the parties were is different swarms. If parties A and B are on the same conference call, along with others, are they interacting?
With an embedded firmware device, the end use has no need to agree to any "shrink wrap" license or ToS prior to use. Whatever firmware is provided is used, and "copied" into RAM, under Fair Use - that's a normal and expected part of operation, the purchase would be otherwise worthless. Perhaps, an agreement could be required when deliberately downloading an upgrade, but that is not the case here.
Therefore, the user might never have agreed to allow Cisco to take control of their purchased device, and change it's operating behavior. Cisco was negligent in making "automatic upgrades" a default. They should, at a minimum, have made the default to be "off," and popped up a warning/permission agreement if the user turned it on.
What they have essentially done is to ship a Trojan Horse, the result of which was criminal*.
It hasn't been determined if the terms of their new unilateral contract are reality with the new firmware - but if they capture browsing behavior, they're also in violation of the ECPA, since the automatic download of new firmware would have required no authorization from the user. If they ship new product with firmware which does that, they'll still be criminals, because the user cannot be required to provide authorization for that as a condition of using the product.
*"Whoever...knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer...the term âoedamageâ means any impairment to the integrity or availability of data, a program, a system, or information;..shall be punished..." - 18 USC 1030
No, the Obama administration argued before the Court that it was a tax. Specifically, Obama's Solicitor General briefed the Court that "THE MINIMUM COVERAGE PROVISION IS INDEPENDENTLY AUTHORIZED BY CONGRESS'S TAXING POWER." (emphasis in original)
??? The lender can't unilaterally change the contract, whether or not they sell it, so it's not clear what you mean by "the contract might not be what it was."
Clearly, the robot is deliberately waiting for the other side to deliver their signal before delivering its own. So, the headline, summary, and article are all false. But it's still impressive, because it actually loses every time.
RPS is meant to be a game of chance, not skill, although extended games may involve trying to identify a pattern in the opponents moves. The implied rule is that each person makes their choice before displaying it. Displaying simultaneously is done in an effort to prevent cheating that rule. This robot cheats by making it's choice based on first seeing the other sides choice.
No one was asking for your advice. The fact is, ordinary investors do place stop loss orders, and large fluctuations caused by HFT cause damage, where there otherwise would be none. And specific to the claim, the flash crash did cause damage to some ordinary investors.
The contract continues to exist, even if one party can't produce a copy. Why should the borrower be relieved of their debt because a piece of paper is lost or misplaced? There are perjury laws to handle the case of someone lying to the court.
"If that company cannot provide the note, then their claim should be dismissed with prejudice."
What's the difference? They can't make a further claim, even if they legitimately hold the paper, and come up with the proper paperwork.
I'd think an equitable solution would be for the court to say "OK, as of this date, we'll accept that X holds the paper. If they haven't accounted for provable payments (including those to a prior holder), or there's a disagreement over who currently holds it, they can duke it out - leave the borrower out of it."
Sometimes, one has to address the current reality, even if it's not perfect. (and I didn't say I was libertarian, so don't disingenuously claim that I did)
Slashdot Mirror
"No I'm not confusing anything. "
That only makes your incorrectness all the more embarrassing.
Ho hum.I should have known better than to try to explain it to an idiot.
GPS navigation uses GPS time, which doesn't have leap seconds. Leap seconds shouldn't have any effect on GPS navigation. One can also derive UTC from GPS, because both a pending leap second flag and a GPS-UTC offset are provided. The GP was apparently referring to systems which use GPS receivers to derive UTC time.
A day is one Earth revolution, relative to Sol. It varies slightly because of a number of factors, and is called UT1. UT2R is a smoothed version, and but variations due to unpredictable events are left. UTC is based on the atomic second. The value chosen for the atomic second is such that, on average, there have been slightly more than 86400 of them in a day. So, just as a year is more than 365 days (a day is slightly shorter than 1/365 year), so an occasional leap day needs to be added, so to an occasional leap second is needed.
Contrary to what the GP said, the solar day is not too fast. It is what it is, by definition. Rather, the second is a bit too short.
On average, since the leap second was introduced in 1972, one has been needed about every 18 months. Over the long term, that rate will increase as tidal acceleration slows the earth. 1 sec/18 months ~= 2e-8, so that's how much the second has been off on average since 1972. The atomic value for the second is 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom. So, a better value might have been 9,192,631,967, which would make us about even to date. (Although, since leap seconds aren't distributed evenly, they would still have occurred, both positive and negative, just not as many.) The original value was based on measurements made over less than 3 years, and has worked for some shorter periods (there were no leap seconds between 1999 and 2004, for example), but the value chosen has proven to be too short over the 40 years of leap seconds.
I didn't say an application would see :60. But, it exists in UTC. The problem is that generally, *nix can't handle the truth. So, kernels either step time backwards by a second, or stretch time around a positive leap second. Both cause problems if accurate timekeeping is important.
"That's because the Earth's average rate of rotation is just a little slower than one solar revolution per day."
You're confusing the need for leap seconds with sidereal time. But note, the Earth actually rotates faster than one solar revolution per day.
Leap seconds are needed because when we changed the definition of a second from 1/86400th of a day to one based on a characteristic of the Caesium atom, a poor value was chosen, and the Earth is slowing down over time, primarily due to tidal acceleration by the moon.
"Windows Azure is DOWN AS WE SPEAK"
What OS are you running, which thinks it's February 29, AS WE SPEAK?
Leap second happens at midnight UTC, not at midnight local time. You posted about 8 minutes before the leap second occurred. I'm guessing you still missed it, though.
UTC is defined to be linked to Sol. It is used for things which depend on that characteristic (like astronomy and celestial navigation). If civil time doesn't need to be linked that closely, then it doesn't need to use UTC.
You mean the GP linked article, where it is said "This affects RHEL 6 and other distros running newer kernels (newer than approx 2.6.26)"? Or where is says that Debian Stable (Squeeze, kernel 2.6.32) is affected?
That would subtract a second. While that is possible, it's never happened. In any case, leap seconds, added or subtracted, are preferably at midnight on the last day of June or December, second preference last day of March or September. They are, however, allowed to happen on the last day of any month.
"A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September." - ITU-R Recommendation TF.460-4
Poorly written software only expects seconds to go from 0-59. Positive leap seconds are counted 23:59:59 -> 23:59:60 -> 0:0:0. Leap seconds have been around since 1972, the same year Unix was rewritten in C. There's been plenty of time to get things right.
As if the computer did this on it's own. Might as well argue that you didn't hire that hit man, he just acted based on hearing the mechanical vibrations caused by electrons going over the phone line.
"Did you interact with someone if your telephone call to party A was carried on the same transatlantic phone cable as someone else's call to party B?"
Poor analogy. It would only work if the parties were is different swarms. If parties A and B are on the same conference call, along with others, are they interacting?
Cisco is a California corporation. Criminal Liability of a Corporate Officer or Agent
With an embedded firmware device, the end use has no need to agree to any "shrink wrap" license or ToS prior to use. Whatever firmware is provided is used, and "copied" into RAM, under Fair Use - that's a normal and expected part of operation, the purchase would be otherwise worthless. Perhaps, an agreement could be required when deliberately downloading an upgrade, but that is not the case here.
Therefore, the user might never have agreed to allow Cisco to take control of their purchased device, and change it's operating behavior. Cisco was negligent in making "automatic upgrades" a default. They should, at a minimum, have made the default to be "off," and popped up a warning/permission agreement if the user turned it on.
What they have essentially done is to ship a Trojan Horse, the result of which was criminal*.
It hasn't been determined if the terms of their new unilateral contract are reality with the new firmware - but if they capture browsing behavior, they're also in violation of the ECPA, since the automatic download of new firmware would have required no authorization from the user. If they ship new product with firmware which does that, they'll still be criminals, because the user cannot be required to provide authorization for that as a condition of using the product.
*"Whoever...knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer...the term âoedamageâ means any impairment to the integrity or availability of data, a program, a system, or information;..shall be punished..." - 18 USC 1030
"The SCOTUS labeled it a tax after the fact. "
No, the Obama administration argued before the Court that it was a tax. Specifically, Obama's Solicitor General briefed the Court that "THE MINIMUM COVERAGE PROVISION IS INDEPENDENTLY AUTHORIZED BY CONGRESS'S TAXING POWER." (emphasis in original)
??? The lender can't unilaterally change the contract, whether or not they sell it, so it's not clear what you mean by "the contract might not be what it was."
- THE WORLD RPS SOCIETY - OFFICIAL ABRIDGED RULES OF PLAY
Clearly, the robot is deliberately waiting for the other side to deliver their signal before delivering its own. So, the headline, summary, and article are all false. But it's still impressive, because it actually loses every time.
RPS is meant to be a game of chance, not skill, although extended games may involve trying to identify a pattern in the opponents moves. The implied rule is that each person makes their choice before displaying it. Displaying simultaneously is done in an effort to prevent cheating that rule. This robot cheats by making it's choice based on first seeing the other sides choice.
No one was asking for your advice. The fact is, ordinary investors do place stop loss orders, and large fluctuations caused by HFT cause damage, where there otherwise would be none. And specific to the claim, the flash crash did cause damage to some ordinary investors.
"Nothing happened to ordinary investors on March 6, 2010"
Wow. That's just laughably, ignorantly, wrong. Unless by "ordinary investor" you exclude anyone who might place a stop order.
Wow. Is English your native language? Because I said nothing to imply that 1 minute trades would be considered HFT.
The contract continues to exist, even if one party can't produce a copy. Why should the borrower be relieved of their debt because a piece of paper is lost or misplaced? There are perjury laws to handle the case of someone lying to the court.
"If that company cannot provide the note, then their claim should be dismissed with prejudice."
What's the difference? They can't make a further claim, even if they legitimately hold the paper, and come up with the proper paperwork.
I'd think an equitable solution would be for the court to say "OK, as of this date, we'll accept that X holds the paper. If they haven't accounted for provable payments (including those to a prior holder), or there's a disagreement over who currently holds it, they can duke it out - leave the borrower out of it."
Did you miss the "Having said that, if..." part?
Sometimes, one has to address the current reality, even if it's not perfect. (and I didn't say I was libertarian, so don't disingenuously claim that I did)