Re: Leap seconds BoF
In message <[EMAIL PROTECTED]>, Mark Calabretta writes: >If any of you will be in the vicinity of Madrid in the period Oct/03-05 >(the BoF is yet to be scheduled) and would like to give a five to ten >minute presentation then we would be delighted to receive it. The closest I'll get is Copenhagen Denmark :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Consensus rather than compromise
In message <[EMAIL PROTECTED]>, Mark Calabretta writes: >On Tue 2005/08/30 19:46:51 +0200, Poul-Henning Kamp wrote >in a message to: LEAPSECS@ROM.USNO.NAVY.MIL > >>keep "the clock" as people see it on their wrist [1] in sufficient >>sync with the light of day through minor acts of timezone adjustments. > >If such a system were to be adopted, then in future, in order to >determine a historical time, the full record of timezone changes would >be needed. How is this different than today ? How is it different from having to keep a total history of leapseconds ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Leap seconds BoF
Greetings, especially to those in favour of stopping leap seconds! A conference concerning astronomical software is coming up at the start of October and there will be a discussion forum (BoF) on the leap second proposals. The conference (www.adass.org) is mainly directed towards, and attended by astronomical software engineers, a number of whom have contributed to this list. Part of the discussion forum will be to explain the background and reasons for eliminating leap seconds. As a co-organizer it occurred to me that rather than have your views espoused by "astronomer-types", who you may imagine to be biassed, that you may wish to present a summary of the reasons why you believe leap seconds must be discontinued. If any of you will be in the vicinity of Madrid in the period Oct/03-05 (the BoF is yet to be scheduled) and would like to give a five to ten minute presentation then we would be delighted to receive it. If you can't attend, but could prepare a half-dozen or so slides (in whatever format you desire), or perhaps some plain text that can be read out, I will undertake to present it, verbatim, on your behalf. As the audience will be scientific/technical in nature, a few well chosen, specific examples that illustrate the technical aspects of your argument would be most effective. Mark Calabretta ATNF
Re: Consensus rather than compromise
On Tue 2005/08/30 19:46:51 +0200, Poul-Henning Kamp wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL >keep "the clock" as people see it on their wrist [1] in sufficient >sync with the light of day through minor acts of timezone adjustments. If such a system were to be adopted, then in future, in order to determine a historical time, the full record of timezone changes would be needed. For general purposes, a record would have to be maintained for every civil administration that sets its timezone (I'm thinking of /usr/share/zoneinfo). This would be a much bigger deal than the current daylight saving switches. Inevitably it also means that the world's timezones would fragment as adjacent civil administrations adopted disparate policies on timezone adjustment. And then, as the political map of the world changes, so the record would become ever more hopelessly complicated. Mark Calabretta ATNF
Re: Consensus rather than compromise
On Aug 30, 2005, at 10:46 AM, Poul-Henning Kamp wrote: We could replace UTC with TAI, or kill leapseconds in UTC and let it keep its offset from TAI or do a myriad of other things and still keep "the clock" as people see it on their wrist [1] in sufficient sync with the light of day through minor acts of timezone adjustments. I challenge the use of the word "myriad" here, implying that there are 10,000 options. The broader we allow the civil time debate to range, the greater number of options, but many of those options are quite distinct from any situation similar to our current vision of an international civil time standard. I believe we will find at the end of the day, that is, the end of an appropriate international discussion of civil time for the third millennium, that civil time will continue to require that the concept of the solar day be reconciled with the concept of the second as an equal length unit of SI time. Note that I'm not trying to drive the discussion back to our well worn pathways - for the purposes of this message, I will entertain the notion of a leap hour as well as the notion of a leap second. But, simply combining the notion of the "day" as the unit of civil time (a "day" of whatever constant length), with the notion of a constant interval clock (atomic or otherwise) results in significant constraints to the search space for a solution. This would be true even on a planet without a moon that is stealing angular momentum. This would be true on a Earth with no historical Babylon to produce sexigesimal notation. The constraint as you word it is to allow corrections to correspond to "minor acts of timezone adjustments". This is 100% equivalent to saying that a civil day must mimic a solar day to a very narrow tolerance. If you want to get me to agree with you on something resembling the statement you made, then it is this: Local Legal/Civilian time will probably always have the sun highest in the sky somewhere around 12:00 through political modification of timezone affiliation. It follows trivially from there that it doesn't matter a dingos fetid kidneys [2] to legal/civilian time what UTC does with relation to the Sun, as long as it is not something ridiculous as monthly leapseconds. Again, I challenge the use of the word "trivially". And it does matter what UTC does with relation to the Sun - even for the extremes of the positions entertained in the original M&K article in GPS World. Please try to move my messages out of the category of "raving leap second supporter". I ain't talking about any of the issues that we have previously beaten to death. Civil Time for the 21st century will continue to mimic Mean Solar Time. What we have been debating all this time is the meaning of the word "mimic". Rob Seaman National Optical Astronomy Observatory
Re: Consensus rather than compromise
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >Yes, I assert that we already agree on what I'm saying - or trying to >say here. Let's put aside six years of squabbling about details and >look at the larger picture. > >John Cowan and others on the "leap seconds suck" side of the >discussion have often said things that indicate that, whatever the >tolerance, there is some common sense connection between darkness and >the concept of midnight: > >>> "as long as the clock doesn't say noon when it's midnight" But apart from a select little crew of time-nuts and the geographically gifted, nobody has UTC on their clock: They have local time which is some number of minutes offset from UTC. We could replace UTC with TAI, or kill leapseconds in UTC and let it keep its offset from TAI or do a myriad of other things and still keep "the clock" as people see it on their wrist [1] in sufficient sync with the light of day through minor acts of timezone adjustments. If you want to get me to agree with you on something resembling the statement you made, then it is this: Local Legal/Civilian time will probably always have the sun highest in the sky somewhere around 12:00 through political modification of timezone affiliation. It follows trivially from there that it doesn't matter a dingos fetid kidneys [2] to legal/civilian time what UTC does with relation to the Sun, as long as it is not something ridiculous as monthly leapseconds. Poul-Henning [1] VCR's will probably still flash "12:00AM" though. [2] Yes, I just saw the movie :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Consensus rather than compromise
[B]ut we already agree on a common position that civil time needs to mimic solar time for most purposes. Kashi, Kashi, Kashi. My apologies - I appear not to be making my point clear (again). Communication is hard - email communication between individuals who have never met face-to-face, all the harder. I do question, however, the success of a rhetorical gambit of chanting the name of a breakfast cereal :-) It's interesting that no matter how much we keep telling him otherwise, Rob still claims that "we already agree" on the above statement. Yes, I assert that we already agree on what I'm saying - or trying to say here. Let's put aside six years of squabbling about details and look at the larger picture. John Cowan and others on the "leap seconds suck" side of the discussion have often said things that indicate that, whatever the tolerance, there is some common sense connection between darkness and the concept of midnight: "as long as the clock doesn't say noon when it's midnight" I merely assert that this is 100% equivalent to my statement. First, implicit in this statement is an assumption that civil time will be continue to be constructed around the concept of a "day". There is no a priori reason that civil time ought not be built around a simple incremental counter like Posix, or that civil time might not be judged to be equivalent to the calendar, or even to some Star Trek stardate gimmick - but I seriously question whether civil time could possibly be ready for such a massive philosophical change for hundreds of years. Second, any standard has to meet a minimum requirement for stability. In the case of civil time, that requirement rests somewhere between, say, a decade and a millennium. Politicians have a short memory, but it certainly stretches from one year to the next - a day or a month or a year is too short for visible effects to be acceptable to the world's power brokers. On the other hand, we have expended the last six years worrying about millennial scale issues. I ain't talking about those. So assume civil time can get by with a decade scale stability horizon. Over ten years an expression of civil time resembling our familiar ancient sexigesimal notation has to remain, ON AVERAGE, synchronized to daylight hours "as long as the clock doesn't say noon when it's midnight". I also ain't talking about the apparent Sun wandering back and forth across the sky due to Daylight Saving Time or the Equation of Time. What are we talking about for stability? Here is a plot of the length of the "actual apparent" solar day throughout the course of the year: daylength.pdf Description: Adobe PDF document That is, the length of the day is 86400 SI seconds +/- 30s (~15s RMS). This diagram is perhaps less familiar than its time integral, the Equation of Time: Note that daily excursions of tens of seconds accumulate as annual excursions of tens of minutes. But, as I've said over and over again, leap seconds are a secular effect, not a periodic effect as illustrated above. Even just a one second difference between the length of the civil day and the length of the mean solar day will accumulate to a one hour shift over the course of a decade - day-by- day, tiny monotonic epsilons add up. So, yes, I assert that a one hour slip of civil time versus solar time is far too large to tolerate over the course of a decade. That being the case, it follows, like night follows day, that civil time must mimic mean solar time to better (likely much better) than one second per day. That's all I was trying to say in the previous message. Rob Seaman National Optical Astronomy Observatory
Re: Consensus rather than compromise
In message: <[EMAIL PROTECTED]> "Poul-Henning Kamp" <[EMAIL PROTECTED]> writes: : In message <[EMAIL PROTECTED]>, Peter Bunclark writes: : : >I would have thought that part of the answer to the difficulty in : >implementation and testing would be to use an open-source library of tried : >and tested algorithms. I don't quite understand why software engineers : >seem to feel the need to write new leap-second handling code every time : >they invent a new gadget. : : The vast majority of software engineers do use standard code, they : use their operating systems libraries, this makes them seemingly : leap second compliant. : : "Seemingly" here covers that they are only compliant in all the : seconds that are not leapseconds or seconds right before leap : seconds. : : The POSIX definition makes it impossible to correctly handle leap : seconds with any complying implementation of the standard, and : therefore applications which needs to be *truly* leapsecond compliant, : cannot use the standard libraries. Not to mention devices that handle leap seconds almost, but not entirely, correctly. Much of the fancy footwork that I've had to do is because some devices are better than others at their pedantic compliance. If one relies on just one detail that's gotten wrong, then one's downstream data will be wrong. Knowing what one can trust and not trust, as well as building in the cross checks is also very device specific. This motorola receiver gets this datum wrong, but that datum right, while this other motorola receiver gets it the other way round. This other GPS receiver supplies data that sounds like it should be the same as the reliable motorola data, but in fact is something subtly different. The problems generally aren't in the leap second ticking code (which is in the kernel and has been proven correct through repeated testing). The problems are in getting experience with the actual details of how a specific device (and sometimes the specific firmware) operates. The problems are in what optimizations one can make to recover time faster from a cold start than waiting for the leap info to arrive at some random time in the next 1/2 hour. The problems are in what the power off behaviors of devices are. The problems can even be in how one tests the leap seconds in a simulator because some devices have a strong notion that time flows forward only and produce bad data for a while when that notion is violated. All these details are hard to enshrine in a write once, reuse forever open source (or even closed source) library. Warner
Re: Consensus rather than compromise
In message <[EMAIL PROTECTED]>, Peter Bunclark writes: >> The POSIX definition makes it impossible to correctly handle leap >> seconds with any complying implementation of the standard, and >> therefore applications which needs to be *truly* leapsecond compliant, >> cannot use the standard libraries. >> >So we need just one other, published, open, correctly implemented, and >tested library and all your problems go away. No, because all sorts of governments and companies mandate "POSIX compliance" so you couldn't sell the resulting product. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Consensus rather than compromise
On Tue, 30 Aug 2005, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Peter Bunclark writes: > > >I would have thought that part of the answer to the difficulty in > >implementation and testing would be to use an open-source library of tried > >and tested algorithms. I don't quite understand why software engineers > >seem to feel the need to write new leap-second handling code every time > >they invent a new gadget. > > The vast majority of software engineers do use standard code, they > use their operating systems libraries, this makes them seemingly > leap second compliant. > > "Seemingly" here covers that they are only compliant in all the > seconds that are not leapseconds or seconds right before leap > seconds. > > The POSIX definition makes it impossible to correctly handle leap > seconds with any complying implementation of the standard, and > therefore applications which needs to be *truly* leapsecond compliant, > cannot use the standard libraries. > So we need just one other, published, open, correctly implemented, and tested library and all your problems go away. Peter.
Re: Consensus rather than compromise
In message <[EMAIL PROTECTED]>, Peter Bunclark writes: >I would have thought that part of the answer to the difficulty in >implementation and testing would be to use an open-source library of tried >and tested algorithms. I don't quite understand why software engineers >seem to feel the need to write new leap-second handling code every time >they invent a new gadget. The vast majority of software engineers do use standard code, they use their operating systems libraries, this makes them seemingly leap second compliant. "Seemingly" here covers that they are only compliant in all the seconds that are not leapseconds or seconds right before leap seconds. The POSIX definition makes it impossible to correctly handle leap seconds with any complying implementation of the standard, and therefore applications which needs to be *truly* leapsecond compliant, cannot use the standard libraries. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Consensus rather than compromise
On Tue, 30 Aug 2005, M. Warner Losh wrote: > > Leap seconds cost actual companies lots of $$$. I know that I've > personally put in about 50 hours to leap second issues since July 1, > and others in my company have put in even more in testing, shipping > equiptment to the simulator facility, writing simulation software for > testing all our products that couldn't be shipped to the simulation > facility, etc. While it is the cost of doing business, implementing > and conforming to this standard is expensive. > > Warner > Part of the previous traffic in this interminable argument is that hard figures are lacking for both the implementation of leap seconds and for their demise. I would have thought that part of the answer to the difficulty in implementation and testing would be to use an open-source library of tried and tested algorithms. I don't quite understand why software engineers seem to feel the need to write new leap-second handling code every time they invent a new gadget. Peter.
Re: Consensus rather than compromise
In message: <[EMAIL PROTECTED]> "Poul-Henning Kamp" <[EMAIL PROTECTED]> writes: : In message <[EMAIL PROTECTED]>, "John.Cowan" writes: : >Rob Seaman scripsit: : : >> [B]ut we already agree on a common : >> position that civil time needs to mimic solar time for most purposes. : > : >Kashi, Kashi, Kashi. : : It's interesting that no matter how much we keep telling him : otherwise, Rob still claims that "we already agree" on the above : statement. The tolerance most people have is on the order of an hour or two, not sub-second measurements at some purely arbitrary meridian. Timezones are an artificial construct, but have created this tolerance in people. I think that any future time standard should recognize this reality and not be artificially constrained by astronomical measurements at some meridian. Leap seconds cost actual companies lots of $$$. I know that I've personally put in about 50 hours to leap second issues since July 1, and others in my company have put in even more in testing, shipping equiptment to the simulator facility, writing simulation software for testing all our products that couldn't be shipped to the simulation facility, etc. While it is the cost of doing business, implementing and conforming to this standard is expensive. Warner
Re: Consensus rather than compromise
In message <[EMAIL PROTECTED]>, "John.Cowan" writes: >Rob Seaman scripsit: >> [B]ut we already agree on a common >> position that civil time needs to mimic solar time for most purposes. > >Kashi, Kashi, Kashi. It's interesting that no matter how much we keep telling him otherwise, Rob still claims that "we already agree" on the above statement. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Consensus rather than compromise
Rob Seaman scripsit: > Folks keep mentioning Indiana as a special case. What makes Indiana a special case is that it has seven different sets of time-zone rules, and that's only true if you ignore variations prior to the Epoch (1970-01-01T00:00:00Z). 1) Gibson, Jasper, Lake, LaPorte, Newton, Porter, Posey, Spencer, Vandenburgh, and Warrick counties are in the Central Time Zone and observe DST accordingly. 2) Dearborn and Ohio counties are in the Eastern Time Zone and observe DST accordingly. 3) Clark, Floyd, and Harrison counties are in the Eastern Time Zone, except that they did not observe DST in 1974. 4) Part of Crawford county was in the Eastern Time Zone (except for not observing DST in 1974) until 1976; now it is in the Indiana Time Zone. 5) Starke county was in the Central Time Zone until 1991; it is now in the Indiana Time Zone. 6) Switzerland county was in the Eastern Time Zone until 1973; it is now in the Indiana Time Zone. 7) The remaining 74 counties are in the unofficial Indiana Time Zone; that is, they are in the Eastern Time Zone but do not observe DST. As of the next DST transition in April 2006, the entire state will be on DST; however, the exact details of which counties will be Eastern and which Central have not yet been worked out. > Again, this confuses secular effects with periodic effects. Even the > most extreme "nuke the leap second" position that has been expressed > has assumed that civil time corresponds to a high level of precision > with solar time. I have repeatedly expressed my position that LMT is a matter for specialists, and that as long as the clock doesn't say noon when it's midnight, most casual users of LCT will not care at all how large the discrepancy is (especially given that it's now 2h56m in Kashi). All this can be achieved easily and in accordance with subsidiarity, by fixing the world's time on TAI (or something with a constant offset) and leaving it to local jurisdictions to change their timezone offsets as needed to cope with uncomfortably large LMT - LCT. > [B]ut we already agree on a common > position that civil time needs to mimic solar time for most purposes. Kashi, Kashi, Kashi. -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" John Cowan <[EMAIL PROTECTED]>
