Re: [LEAPSECS] All of this has happened before
Oh dear, my ears are burning. The leap second debate is all about social custom. It is about definitions (which are social customs) used by people (which is social) and decided by international bodies of experts (which involve social relationships and social processes) that will determine policies (social rules). Long, long ago Aristotle pointed out the confusion caused when we conflate the measure of time (a human convention and technique) with time. The leap second debate is about the measure of time, not time itself. It is about which customs of timekeeping should be the global standard. Atomic timekeeping is a custom that has an edge because it is more precise in measuring duration than other systems of timekeeping, and by custom, we privilege duration in how we currently think about time (not all cultures do this). If we privileged kairos (points in time, or determining the right time) like some cultures (e.g., Jewish time traditions), then we'd see atomic timekeeping as a complementary technology not a dominant one in thinking about time. What we are contending with is some very impressive metrological science mixed with a decision to be made in which there will be winners and losers. Because there will be winner and losers, this is a political process as well as a technical one.Because it is political, the decision will be made by an international body because our current custom values democratic processes over tyrannical decrees. The problem is that democratic processes do not always reflect sound science or even rationality. That, too, seems to be a social custom. My impression is that the technical arguments about the leap second are very well rehearsed, whereas the collision of social customs and international politics in the ITU-R process is the big unknown. Will the UK continue to protest because, as one of its former ministers put it, getting rid of the leap second will move the prime meridian for timekeeping toward the US? What he didn't say was that it will actually reach UK's parliament first! Such an argument grounded in nationalism (hence custom) not science. It is easy to denigrate mere social custom and claim that science should triumph. Tell that to all the NSF staff that are battling Congress destroying the peer review process in favor of politicians approving what scientific research gets done. Sometimes custom and politics trump all scientific arguments. Cheers, Kevin From: LEAPSECS [leapsecs-boun...@leapsecond.com] on behalf of Rob Seaman [sea...@noao.edu] Sent: Thursday, January 29, 2015 7:44 AM To: Leap Second Discussion List Subject: Re: [LEAPSECS] All of this has happened before On Jan 29, 2015, at 1:05 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message bdf1dd12-9e80-4516-91ba-76127dcb9...@noao.edu, Rob Seaman writes: On Jan 28, 2015, at 1:34 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: Derives from is not a physical reality, it's merely a social custom. So many replies to choose from [...] ... all of them unresponsive to my complaint. Well, no. You denigrated social custom by prepending the word mere, so in lieu of my composing an essay to refute this by referencing a thousand-and-one things starting with Kevin Birth's work I went looking for a pithy quote to suggest the great importance that custom has. I found many quotes and deemed that simple numbers would emphasize the point. Your dismissive usage was similar to the numerous times that an attempt to diminish important issues has been made by referring to them as non-technical. On the contrary, social constructs are highly pertinent to technical discussions. I then followed that by explicitly rejecting your unstated premise that somehow LOD of day is not fixed by the synodic motions of the Earth. And then a brief restatement of the theme that proper systems engineering will provide the quickest and surest path to a resolution acceptable to all. I'll include these here in case you didn't read that far down in the message: Try adjusting the knob for LOD even one-hundredth of one percent away from mean solar time in either direction. Day will turn to night in a dozen years. You don't like physical reality? How about engineering requirement so obvious it remains unstated? Requirements are inputs to the systems engineering process. They clarify the nature of the problem space. Multiple solutions can, however, be entertained to a single problem. The ITU has rather only ever been presented with one option - an option that cannot satisfy the engineering requirements. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo
Re: [LEAPSECS] All of this has happened before
In message bdf1dd12-9e80-4516-91ba-76127dcb9...@noao.edu, Rob Seaman writes: On Jan 28, 2015, at 1:34 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: Derives from is not a physical reality, it's merely a social custom. So many replies to choose from [...] ... all of them unresponsive to my complaint. -- 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 https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] All of this has happened before
On Jan 29, 2015, at 1:05 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message bdf1dd12-9e80-4516-91ba-76127dcb9...@noao.edu, Rob Seaman writes: On Jan 28, 2015, at 1:34 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: Derives from is not a physical reality, it's merely a social custom. So many replies to choose from [...] ... all of them unresponsive to my complaint. Well, no. You denigrated social custom by prepending the word mere, so in lieu of my composing an essay to refute this by referencing a thousand-and-one things starting with Kevin Birth's work I went looking for a pithy quote to suggest the great importance that custom has. I found many quotes and deemed that simple numbers would emphasize the point. Your dismissive usage was similar to the numerous times that an attempt to diminish important issues has been made by referring to them as non-technical. On the contrary, social constructs are highly pertinent to technical discussions. I then followed that by explicitly rejecting your unstated premise that somehow LOD of day is not fixed by the synodic motions of the Earth. And then a brief restatement of the theme that proper systems engineering will provide the quickest and surest path to a resolution acceptable to all. I'll include these here in case you didn't read that far down in the message: Try adjusting the knob for LOD even one-hundredth of one percent away from mean solar time in either direction. Day will turn to night in a dozen years. You don't like physical reality? How about engineering requirement so obvious it remains unstated? Requirements are inputs to the systems engineering process. They clarify the nature of the problem space. Multiple solutions can, however, be entertained to a single problem. The ITU has rather only ever been presented with one option - an option that cannot satisfy the engineering requirements. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] All of this has happened before
We each wear multiple hats. Two of mine are 1) to point out that physical reality trumps standards and software, [...] And one of my hats is to point out that you have no monopoly on defining physical reality and have a great tendency to define it to support your opinions. Likewise, as for your personal physical reality isn't trumping anything, unless you're also the one paying the piper. -- 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 https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] All of this has happened before
On Jan 28, 2015, at 10:02 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: We each wear multiple hats. Two of mine are 1) to point out that physical reality trumps standards and software, [...] And one of my hats is to point out that you have no monopoly on defining physical reality and have a great tendency to define it to support your opinions. Physical reality defines itself :-) Is either assertion in my previous email incorrect? The residuals on the y-axis of these plots from the IERS attest in great detail that Mean Solar Time differs from Atomic Time: http://www.iers.org/IERS/EN/Science/EarthRotation/LODplot.html And length of day most assuredly derives from the synodic day, i.e., mean solar time. Is there not one fewer day in the year than sidereal rotations? Likewise, as for your personal physical reality isn't trumping anything, unless you're also the one paying the piper. We have leap seconds (or would have some other accommodation) due to the accumulation of the residuals in the IERS plots. But those residuals are as small and manageable as they are precisely because the duration of the SI-second was chosen to closely mimic the fraction 1/86,400 of a solar day. Over the history of UTC the residuals have stayed below 4ms. That is within 1.0004629 of the (varying) length of a solar day. This is not coincidence. And LOD is not a free parameter. I think, rather, that it is my statements about systems engineering that you wish to redefine. Leap seconds are a means to an end; one could consider other means. However, attempting to ignore engineering requirements outright is a recipe for trouble. I infer bigger trouble than you are willing to admit. But the people who are not paying the piper are the ITU. It would have been significantly less expensive / more effective to have spent the past 15 years performing coherent systems engineering than in single-minded pursuit of a pretense that two different things are the same. I am delighted at the recent small engineering project surrounding DNS as a conveyance for Bulletins C D. It seems likely to lead to something at least modestly useful. The tzdist group is making great progress with a larger project as Steve has described. Is there anything else this group can do along these lines, for instance to verify and encourage uptake of the fixes to the issues encountered during the 2012 leap second? Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] All of this has happened before
On Jan 28, 2015, at 1:34 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: Derives from is not a physical reality, it's merely a social custom. So many replies to choose from - and so many that have been posted in the past - let's go with some (unvetted) quotes on custom: - Truth always originates in a minority of one, and every custom begins as a broken precedent. - Will Durant - Custom adapts itself to expediency. - Tacitus - The despotism of custom is everywhere the standing hindrance to human advancement. - John Stuart Mill - Nothing is more powerful than custom or habit - Ovid - Take the course opposite to custom and you will almost always do well. - Jean-Jacques Rousseau - Custom is our nature. What are our natural principles but principles of custom? - Blaise Pascal - The way of the world is to make laws, but follow custom. - Michel de Montaigne - It is not reason which is the guide of life, but custom. - David Hume - People usually think according to their inclinations, speak according to their learning and ingrained opinions, but generally act according to custom. - Francis Bacon - Custom reconciles us to everything. - Edmund Burke Try adjusting the knob for LOD even one-hundredth of one percent away from mean solar time in either direction. Day will turn to night in a dozen years. You don't like physical reality? How about engineering requirement so obvious it remains unstated? Requirements are inputs to the systems engineering process. They clarify the nature of the problem space. Multiple solutions can, however, be entertained to a single problem. The ITU has rather only ever been presented with one option - an option that cannot satisfy the engineering requirements. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
