A problem for sysadmins is that the status quo of the standards requires that we choose which standard we want to violate. We can violate the specification of UTC by not counting 23:59:60 or we can violate POSIX by counting it or we can violate POSIX and the SI second by not actually keeping the system clock on UTC using smeared seconds that are not suitable for tracking projectiles and other real-time applications. This problem is old, 50 years old, as seen in the 3 plots on this web page.
A recent draft of the set of options which will be presented when the World Radio Conference votes this fall is visible at
http://acma.gov.au/Industry/Sp...
This draft has options A, B, and C, but it is likely to be wordsmithed a lot before it is finished.
Yes "right" is "agree with everyone else", but in the existing documents by which various international agencies approved the use of UTC all of them did so along with an assertion that everyone was agreeing with "mean solar time"; i.e., that days are counted by measuring the rotation of the earth. Those engineers who are free to ignore regulations and statutes can choose to use something like GPS time, but many projects and systems are constrained to conform to existing regulations and do not have that liberty. Any project or system which is constrained to use both UTC and POSIX is SOL every time a leap second happens. This international regulatory process has repeatedly failed to engage all the stakeholders in an open discussion of what everyone expects and needs. The result of that has been "failure of imagination" when one agency embarks on a course that differs from the existing agreements.
Look deeper at one of the underlying problems in this issue -- see blockquote in the "UTC in 1982" entry here. That paragraph was written by one of the folks who actually worked in the field of timekeeping, and those are the folks who produced the documents that get approved by the votes. (All the votes by those agencies that make the official documents are done by delegates who know next to nothing about the subject matter.) See how that 1982 paragraph crows about the way that UTC with leap seconds has solved all problems and become accepted by everyone.
They were oblivious to the problems that would crop up. The process of making the decisions and producing these international recommendations has not changed much in the subsequent 30 years.
Not a lie, just missing another essential component: What I want to see is another layer of graph that shows which browsers (have) trust(ed) which CAs, and (if only!) how many dollars flowed along each of those edges.
I remember the first vendor demo workstation arriving with X running on it. I remember GraphOn X terminals, and NCD X terminals. I remember rewriting the Keck CCD image display program not to send each image 3 times and getting live readouts over 28k modem to my living room.
except that BIPM, the providers of TAI, have published this http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf wherein the CCTF "stresses that TAI is the uniform time scale underlying UTC, and that it should not be considered as an alternative time reference." This appears to indicate that the CCTF and BIPM are not comfortable with the notion that operational systems might be employing TAI as their time scale. At the end of that paper they also discuss the possibility that TAI could cease to exist.
The ITU doesn't insert anything, they just emit documents to which everyone is expected to conform, but the ITU-R process does not require consensus, interoperability testing, nor even a description of implementation details. All of that are Somebody Else's Problems.
'laws and sausages' is attributed to von Bismarck. Is it not the case that every RFC is basically an international trade agreement? The process of making them is very different than ACTA. Which produces the more effective result?
It is obvious that questions about this topic should be asked twice every year for the indefinite future in order that we can ponder the need for such.
Slashdot Mirror
A problem for sysadmins is that the status quo of the standards requires that we choose which standard we want to violate. We can violate the specification of UTC by not counting 23:59:60 or we can violate POSIX by counting it or we can violate POSIX and the SI second by not actually keeping the system clock on UTC using smeared seconds that are not suitable for tracking projectiles and other real-time applications. This problem is old, 50 years old, as seen in the 3 plots on this web page.
A recent draft of the set of options which will be presented when the World Radio Conference votes this fall is visible at http://acma.gov.au/Industry/Sp... This draft has options A, B, and C, but it is likely to be wordsmithed a lot before it is finished.
Yes, my inner physicist is hurting badly that neither author nor editor seems to grasp the subject enough to notice the inconsistency.
Yes "right" is "agree with everyone else", but in the existing documents by which various international agencies approved the use of UTC all of them did so along with an assertion that everyone was agreeing with "mean solar time"; i.e., that days are counted by measuring the rotation of the earth. Those engineers who are free to ignore regulations and statutes can choose to use something like GPS time, but many projects and systems are constrained to conform to existing regulations and do not have that liberty. Any project or system which is constrained to use both UTC and POSIX is SOL every time a leap second happens.
This international regulatory process has repeatedly failed to engage all the stakeholders in an open discussion of what everyone expects and needs. The result of that has been "failure of imagination" when one agency embarks on a course that differs from the existing agreements.
Look deeper at one of the underlying problems in this issue -- see blockquote in the "UTC in 1982" entry here. That paragraph was written by one of the folks who actually worked in the field of timekeeping, and those are the folks who produced the documents that get approved by the votes. (All the votes by those agencies that make the official documents are done by delegates who know next to nothing about the subject matter.) See how that 1982 paragraph crows about the way that UTC with leap seconds has solved all problems and become accepted by everyone. They were oblivious to the problems that would crop up. The process of making the decisions and producing these international recommendations has not changed much in the subsequent 30 years.
The ITU has also put up an issue of ITU News with in depth articles.
If they tried being more accurate they'd have to explain what time scale they were broadcasting way back then.
JMS had this figured out years ago with his keeper.
For over 50 years rocket launch countdowns have not run in a linear fashion, sometimes even being set backwards.
Not a lie, just missing another essential component: What I want to see is another layer of graph that shows which browsers (have) trust(ed) which CAs, and (if only!) how many dollars flowed along each of those edges.
This scenario evokes International Rescue. Obviously that says I'm old.
I remember the first vendor demo workstation arriving with X running on it. I remember GraphOn X terminals, and NCD X terminals. I remember rewriting the Keck CCD image display program not to send each image 3 times and getting live readouts over 28k modem to my living room.
except that Stanford's policy makes it clear in advance that is, basically, a tuition requirement for a degree
except that BIPM, the providers of TAI, have published this http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf wherein the CCTF "stresses that TAI is the uniform time scale underlying UTC, and that it should not be considered as an alternative time reference." This appears to indicate that the CCTF and BIPM are not comfortable with the notion that operational systems might be employing TAI as their time scale. At the end of that paper they also discuss the possibility that TAI could cease to exist.
anything that runs its kernel on GPS time can give correct UTC time by following this prescription http://www.ucolick.org/~sla/leapsecs/right+gps.html
The ITU doesn't insert anything, they just emit documents to which everyone is expected to conform, but the ITU-R process does not require consensus, interoperability testing, nor even a description of implementation details. All of that are Somebody Else's Problems.
Perchance something like this example worked with existing deployed and tested code? http://www.ucolick.org/~sla/leapsecs/right+gps.html
Watch the excitement unfold as recent kernel patches unravel http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today
The time service bureaus used to insert leap milliseconds at almost any time. See the bottom plot at http://www.ucolick.org/~sla/leapsecs/amsci.html where there were 29 leaps in 3 years.
Knowing of previous incidents, I suspect that itwbennett may have an interesting time when next dealing with Australian customs.
'laws and sausages' is attributed to von Bismarck. Is it not the case that every RFC is basically an international trade agreement? The process of making them is very different than ACTA. Which produces the more effective result?
There was also the Army Corps of Engineers model of the entire Mississippi/Missouri/Ohio/Arkansas/Red river basins. It was built by POW labor near Clinton, MS. See what's left of it here. http://maps.google.com/maps?ll=32.30606,-90.316173&spn=0.003922,0.006335&sll=36.977452,-121.987122&sspn=0.118622,0.202732
I'm posting at 08:08 UTC
It is obvious that questions about this topic should be asked twice every year for the indefinite future in order that we can ponder the need for such.
Look at the amount that the pole moves and the length of day changes annually. The normal variations are 1000 times greater than anything the earthquake has caused. See the IERS saying "hardly discernible" because a large snowstorm can cause a greater change.