[LEAPSECS] (no subject)
In addition to what John Cowan said, I'd also point out that planning is the one of the biggest issues with leap seconds. In terms of planning for the future, if an application cares about local time, not knowing whether a leap second is going to happen outside a six month window can be a much larger problem than handling sliding time zones that would happen much less frequently and, one would think, with considerably more advance notice. For those that are in favor of the current system of leap seconds, it might be more effective to pretend that people don't have to plan for the future than to remind them in the opening sentence. Please identify the operations which need one second predictability over a time span of six months. They can't be scheduling a meeting, for a time zone change might be decreed. They can't be launching shuttle to rendezvous with ISS, for the solar activity will drag the atmosphere by more than that much. What are these applications? For these operations please explain why the timing demands of the system did not already recognize that they needed to design a GPS time receiver into the applications. (As we've just read, the geodecists recognized that the technical aspects of using GPS outweighed any bureaucratic mandate to use a time scale with an international recommendation behind it.) And to the more general audience than John Hein... Please explain why using the name UTC for something with different characteristics and applications is more important than the history and art embodied in Dennis di Cicco's analemma http://www.twanight.org/newTWAN/photos.asp?ID=3001422 Please explain why changing the name of the broadcast time scale to TI and putting UTC and the leap seconds into zoneinfo does not satisfy all requirements of the need for uniform time scale. Please explain why the recommendations of the assembly of world time experts at Torino in 2003 are not valid even after it has been pointed out that zoneinfo provides a mechanism for implementing them. If the objections are about presumptions of computer code with respect to scheduling something for the same civil time tomorrow please identify code systems which correctly implement the sorts of things seen here http://www.webexhibits.org/daylightsaving/g.html and discuss the relative number of systems which already get it wrong. I want to know why I should give up the notion of civil time being based on mean solar time, for myself and for posterity. -- Steve Allen WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
In message <006d7a34-31d9-4492-9014-667c7b926...@ucolick.org>, Steve Allen writ es: >Please identify the operations which need one second predictability >over a time span of six months. Wrong question. Try: Please identify computer communications where it is not guaranteed that all involved computers will have their software updated every six months. -- 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 http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
In message: <006d7a34-31d9-4492-9014-667c7b926...@ucolick.org> Steve Allen writes: : I want to know why I should give up the notion of civil time being : based on mean solar time, for myself and for posterity. Leap-seconds, as implement, are unworkable. You can see long messages from me in the past enumerating the reasons relating to systems, especially systems disconnected from the internet... Leap-seconds, the concept, have a limited shelf life. Maybe only a few thousands years. So there's nothing really to preserve. One day they must be abandoned. As soon as we fixed the length of a second based on atomic behavior rather than as 1/86400th of a mean solar day, we really abandoned time based on mean solar time. Leap seconds are at best a hack to paper over this fundamental decision. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
M. Warner Losh wrote: Leap-seconds, as implement, are unworkable. If so, there are worlds of possibilities short of the vain attempt to eradicate them entirely. You can see long messages from me in the past enumerating the reasons relating to systems, especially systems disconnected from the internet... Systems (still unenumerated) that require real-time access to actual "UT" (a flavor of GMT), will have this same exact issue, but the ITU proposal does nothing to plan for a replacement. Rather, it demands that the current DUT1 mechanism be abandoned. As other long messages point out, it is simply not true that most or many or more than a very small fraction of systems need real-time leap second updates. Ultimately, even non-realtime systems will suffer as vast numbers of embargoed leap seconds pile up. These will have to be released eventually. What is the plan for doing so? Include that plan in any proposal to change the status quo. Leap-seconds, the concept, have a limited shelf life. Maybe only a few thousands years. So there's nothing really to preserve. One day they must be abandoned. The current standard is workable for at least hundreds of years. What is the hurry to vote on this issue without reaching consensus first? Could it be that the proponents don't believe the current proposal is coherent enough to win over converts outside of their own special interests? Whatever action might be taken, plan the evolving standard fully before taking it. As soon as we fixed the length of a second based on atomic behavior rather than as 1/86400th of a mean solar day, we really abandoned time based on mean solar time. Civil time is and will remain a flavor of mean solar time. If you believe otherwise, muster arguments for how this assertion fails to be true. It is a basic requirement of any replacement that the clock not drift willy-nilly, but rather be accommodated by some well thought out plan. It isn't the astronomers on this list who have been unwilling to consider alternative proposals. Leap seconds are at best a hack to paper over this fundamental decision. No - inappropriate attempts to apply interval timescales to civil timekeeping are the real kludge. The issue remains the conflation of the two distinct concepts of the SI second with the civil second (1/86400 of a day). This is a naive attempt at redefining the fundamental concept of the day. Even if we evolve into mole-people living underground and losing the power of sight, an intelligent species will never abandon civil timekeeping based on mean solar time. Diurnal rhythms abound throughout our society and its infrastructure. All the confusion about zero point shifts is a red herring. The issue is that the mean solar rate has to be maintained. It is a strange position for precision timekeepers to take that a residual rate of milliseconds per day should be regarded as negligible. We can cheat the sun for a while - but only for a while. There are two kinds of time, interval and earth orientation. Whatever the ITU rules at some future meeting these must be kept straight - and civil timekeeping depends much more on earth orientation than on interval timing. If there are problems with interval timekeeping, then civil time is not the right place to address them. Separate the two sets of issues and the proper solution(s) will become easier to design and deploy. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
In message: <490a82a4-a8b3-485e-8ded-f9c8adc89...@noao.edu> Rob Seaman writes: : M. Warner Losh wrote: : : > Leap-seconds, as implement, are unworkable. : : If so, there are worlds of possibilities short of the vain attempt to : eradicate them entirely. Dude, stop misrepresenting my position. Either we kill them entirely, since they are going away eventually anyway, or we put them on a regular schedule like leap years. The current system sucks too bad to be allowed to continue. Like this silly discussion, leap seconds take a hugely disproportionate amount of time and money in the implementation of timing systems that I've been involved in. All the rest is polemics.. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
Dude, I'm not representing your position at all. Assertions are made. I respond. The "current system" for instance, is simply the mechanics of the solar system. It will remain the underlying system whatever the ITU decides. What is your position on the solar system? I don't know. (Personally, I'm all for it.) On the other hand, you've spent the last few messages taking offense at insults I've never uttered and misrepresenting PHK's jocular comment as my own. Leap seconds principally take time and money because people have selected UTC for some purpose requiring an interval timescale. The advice seems pretty obvious - don't use UTC. There is no "one size fits all" timescale. Attempts to create one will fail. If you think it is a silly discussion, why keep returning to it? On the other hand, my observatory has just undergone a round of downsizing due to the poor economy. If the ITU succeeds in their (far more silly) exercise of removing leap seconds from UTC, it will cost the astronomical community millions of dollars worldwide - perhaps many millions of dollars. (When you mention remote untended systems, few are more so than space-based telescopes.) Those millions of dollars will inevitably result in many more layoffs since not once has any suggestion been made of compensating astronomers for the cost of such a change to the standard. Thus I continue my part in what seems rather more a threatening, than a silly, discussion. Rob --- On Dec 20, 2008, at 11:55 AM, M. Warner Losh wrote: In message: <490a82a4-a8b3-485e-8ded-f9c8adc89...@noao.edu> Rob Seaman writes: : M. Warner Losh wrote: : : > Leap-seconds, as implement, are unworkable. : : If so, there are worlds of possibilities short of the vain attempt to : eradicate them entirely. Dude, stop misrepresenting my position. Either we kill them entirely, since they are going away eventually anyway, or we put them on a regular schedule like leap years. The current system sucks too bad to be allowed to continue. Like this silly discussion, leap seconds take a hugely disproportionate amount of time and money in the implementation of timing systems that I've been involved in. All the rest is polemics.. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
On Sat, 2008-12-20 at 08:03 -0800, Steve Allen wrote: > I want to know why I should give up the notion of civil time being > based on mean solar time, for myself and for posterity. I believe the answer being argued is "the aerospace and nuclear industries would save money". -- Ashley Yakeley ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
On 2008 Dec 20, at 10:55, M. Warner Losh wrote: Either we kill them entirely, since they are going away eventually anyway, or we put them on a regular schedule like leap years. The current system sucks too bad to be allowed to continue. Pardon me, but I'm missing something in this about the annoyance of leap seconds. I thought the trouble was that they interrupt the broadcast time scale (which I distinguish from UTC). If the ITU-R decides to bless a new time scale like TI, then POSIX can take note and say as of then time_t is to be interpreted as the internationally-blessed broadcast time scale named TI. Bureacracy that happens to have specified UTC can be reinterpreted on a case by case basis to decide whether it wants TI or UTC, but in the interim all the operational systems keep on working. If leap seconds go into zoneinfo, then they are only as much nuisance as when the political princes of the world decree a change in the rules for time zones, and not even total unanimity within the ITU can stop that. I agree that the current system is dysfunctional. I typically carry around 100 GB of storage, a GHz of processing capability, and devices that can communicate with 4 different wireless protocols. That is how the world has changed since 1970 when everything was pencil, paper, and slide rule. My devices can receive something like TI, use it internally, and report to me something with added timezone offsets. But of those wireless protocols, one of them was entirely shut down by the FCC before I had owned the device 5 years, so that one is defunct and the hardware deserves replacement. I don't want to see mean solar time abandoned because of the shortcomings of systems with that sort of lifetime. -- Steve Allen WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
In message: <8d831340-be80-4595-9e73-eaa3465a4...@ucolick.org> Steve Allen writes: : : On 2008 Dec 20, at 10:55, M. Warner Losh wrote: : > Either we kill them entirely, since they are going away eventually : > anyway, or we put them on a regular schedule like leap years. The : > current system sucks too bad to be allowed to continue. : : Pardon me, but I'm missing something in this about the annoyance : of leap seconds. I thought the trouble was that they interrupt the : broadcast time scale (which I distinguish from UTC). That's one of many problems. : If the ITU-R decides to bless a new time scale like TI, then POSIX : can take note and say as of then time_t is to be interpreted as the : internationally-blessed broadcast time scale named TI. Bureacracy : that happens to have specified UTC can be reinterpreted on a case : by case basis to decide whether it wants TI or UTC, but in the : interim all the operational systems keep on working. I'd have to think about this carefully to make sure that it would work, but there's still at least one problem if UTC is still around... : If leap seconds go into zoneinfo, then they are only as much nuisance : as when the political princes of the world decree a change in the : rules for time zones, and not even total unanimity within the ITU can : stop that. There's three issues with this. First, long running programs (programs that run for years) will force the libraries that cope with these files to stat them from time to time to make sure that there isn't a new update (otherwise your time will be 1s off). Second, many programs need to run over leap seconds still and behave properly. Third, you never know if you have the right, up to date files when you startup (think systems that are cold spares that have been on the shelf for a year). How do you reconcile that? Also, there's silly operational things like "how do I update these files if there's no vendor to update them?" which is a matter of programming. And do I let anybody update them? What if my GPS control program wants to do it? What if ntpd wants to do it (assuming it goes to TI)? What if they both want to do it and the data are unconsistent? You still have to figure out who to believe in this case. And what's the recommended SOP for dealing with systems that learn that the current offset is 42 seconds, but the leap files only have 34 seconds listed? Is there a "good enough" standard for "interpolating" when these leap seconds could have happened and updates to the tables happen that way? And what about network protocols that still need to report UTC times rather than these new TI times for things like file modification time (say, NFS)? Since these are implemented in the kernel, now you have to give the kernel a reasonable table. And since timestamps span a number of years, the question about putative leap seconds from the previous paragraph doesn't sound so funny. People likely won't care too much if the timestamps are off a few seconds, but things like 'make' will care (if your sources are on a NFS server and your objects are on local storage). Oh, and likely a dozen other issues I've not thought of off the top of my head. At least with UTC, everybody botches leap seconds, but also the broadcast of time is deterministic. If you broadcast time that's offset, and rely on tables in the receiving device, then you lose some of that because of the problem of stale tables (or worse, wrong ones). : I agree that the current system is dysfunctional. Yea! : I typically carry around 100 GB of storage, a GHz of processing : capability, and devices that can communicate with 4 different : wireless protocols. That is how the world has changed since 1970 : when everything was pencil, paper, and slide rule. My devices can : receive something like TI, use it internally, and report to me something : with added timezone offsets. Right. However, many of these systems that I'm used to dealing with aren't connected to a meaningful network at all. Most of these systems have 100-300 MHz of power, ~100MB of storage (or less), and limited connectivity. Often times they just know the current offset (and that only after 30 minutes in a cold start case for gear that's been on the shelf for a while). Since their purpose is to display in UTC and interact with gear that uses UTC, plus weather a leap second w/o having a step in their internal time representation (which, btw, has to be efficient in storage and arithmetic operations done on it, which makes 'broken down UTC time + leap tables' a non-starter, so a count of SI seconds since some epoch is usually used, with the conversions to UTC done for display, which means to do any display, you have to know the right number of leap seconds). : But of those wireless protocols, one of them was entirely shut down : by the FCC before I had owned the device 5 years, so that one is defunct : and the hardware deserves replacement. : : I don't want to
Re: [LEAPSECS] (no subject)
In message <8d831340-be80-4595-9e73-eaa3465a4...@ucolick.org>, Steve Allen writ es: >If leap seconds go into zoneinfo, then they are only as much nuisance >as when the political princes of the world decree a change in the >rules for time zones, and not even total unanimity within the ITU can >stop that. That depends critically on how often we have to change the zoneinfo files. Many systems avoid local timezones, to decouple the princes whims from their operation, the poster boy example being air traffic control, where everything is in UTC. Putting leapseconds in zoneinfo would put an update obligation on ATC-, and possibly on-board-, systems to get their zoneinfo files updated regularly. The difference between six months and ten years is the difference between "unacceptable" and "something we an live with". Getting rid of leap seconds, solves the problem entirely for the ATC application domain. Poul-Henning -- 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 http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
On Sat, 20 Dec 2008, Steve Allen wrote: > > Please identify the operations which need one second predictability > over a time span of six months. Anything that needs to exchange time stamps with other systems that are both accurate and specified in some variant of UT (UTC, POSIX time, NTP time, etc.) needs an up-to-date leap second table. Even if the only future event that these systems need to predict is leap seconds, that is enough to affect their software update schedule or require some other way to periodically obtain a leap second table. > Please explain why changing the name of the broadcast time scale > to TI and putting UTC and the leap seconds into zoneinfo does > not satisfy all requirements of the need for uniform time scale. You keep asking this question and we keep explaining that it breaks too much software. Tony. -- f.anthony.n.finchhttp://dotat.at/ HUMBER THAMES DOVER: WEST OR NORTHWEST 5 OR 6, DECREASING 3 OR 4 BUT VARIABLE 3 OR LESS IN DOVER. SLIGHT OR MODERATE. MAINLY FAIR. MODERATE OR GOOD, OCCASIONALLY POOR. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
>> Please explain why changing the name of the broadcast time scale >> to TI and putting UTC and the leap seconds into zoneinfo does >> not satisfy all requirements of the need for uniform time scale. > >You keep asking this question and we keep explaining that it breaks >too much software. > >Tony. Tony, I am trying to clarify in my mind a couple of proposals, one of which is having no more leap-seconds in the civil (broadcast) time scale. I'm sorry, I must have missed your messages where you said that a lot of software would fail in that scenario - could you briefly clarify please? Peter ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
In message <49513.1229953...@uk2.net>, Peter Vince writes: >I am trying to clarify in my mind a couple of proposals, one of which is >having no more leap-seconds in the civil (broadcast) >time scale. I'm sorry, I must have missed your messages where you said that a >lot of software would fail in that scenario - >could you briefly clarify please? There is one (major) problem: software does not grok leapseconds. One of the solutions Rob peddles for this, is "Make a new timescale without leap seconds, and leave leap seconds in the UTC timescale". This does not fly because a lot of systems are legally mandated to use the UTC timescale. Changing all those laws and regulations, just because a single astronomer is very emotionally attached to the name "UTC" is just not going to happen :-) Poul-Henning -- 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 http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
On Mon, 22 Dec 2008, Peter Vince wrote: > > I am trying to clarify in my mind a couple of proposals, one of which is > having no more leap-seconds in the civil (broadcast) time scale. I'm > sorry, I must have missed your messages where you said that a lot of > software would fail in that scenario - could you briefly clarify please? This isn't really about broadcast timescales, but about the semantics of POSIX time_t. Steve proposes to provide a well-defined uniform timescale on Unix systems by redefining time_t to follow some linear atomic timescale instead of UTC, and that the zoneinfo/tzcode library would be used to translate from this new version of time_t to UTC, using a leap second table alongside the existing time zone tables. The code to implement this has in fact already been written, 15 or more years ago, but no-one uses it because it breaks too much stuff. For example, there is a lot of time-handling code in the kernel, and because it does not link with the tzcode library the proposed architecture doesn't accommodate its requirements. There's also a lot of code which doesn't use the C tzcode for time handling, such as the Java runtime. There is a pervasive assumption in Unix that midnight UT is when t % 86400 == 0. Tony. -- f.anthony.n.finchhttp://dotat.at/ SOUTHEAST ICELAND: SOUTHEASTERLY 5 OR 6 VEERING SOUTHWESTERLY 6 TO GALE 8. VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
On 22 Dec 2008 at 14:03, Poul-Henning Kamp wrote: > This does not fly because a lot of systems are legally mandated to > use the UTC timescale. And some laws in some places mandate Greenwich Mean Time, or lots of other things. No matter what is done with time scales in the future, it's going to run contrary to somebody's laws somewhere. -- == 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] (no subject)
On Dec 22, 2008, at 7:22 AM, Daniel R. Tobias wrote: On 22 Dec 2008 at 14:03, Poul-Henning Kamp wrote: This does not fly because a lot of systems are legally mandated to use the UTC timescale. And some laws in some places mandate Greenwich Mean Time, or lots of other things. No matter what is done with time scales in the future, it's going to run contrary to somebody's laws somewhere. One might also mention the usual example of attempting to legislate physical reality, the "Indiana pi bill": http://www.agecon.purdue.edu/crd/Localgov/Second%20Level%20pages/indiana_pi_bill.htm It may be hard to believe (whatever countries we live in), but dig deep enough down through our interlocking systems of laws and treaties and you eventually reach some underlying model of physical reality :-) Example: If the ITU proposal were to attempt to relayer civil timekeeping on Earth onto the length of the Martian day, one can be confident they would fail. The issue is how close is close enough? Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
On Mon 2008-12-22T14:10:25 +, Tony Finch hath writ: > The code to implement this has in fact already been written, 15 or more > years ago, but no-one uses it because it breaks too much stuff. I am aware of the interesting breakages that happened when zoneinfo files were retroactively modified to be inconsistent with POSIX. Clearly that change cannot be done for past history. That's part of the point of this live javascript page http://www.ucolick.org/~sla/leapsecs/epochtime.html > example, there is a lot of time-handling code in the kernel, and because > it does not link with the tzcode library the proposed architecture doesn't > accommodate its requirements. There's also a lot of code which doesn't use > the C tzcode for time handling, such as the Java runtime. There is a > pervasive assumption in Unix that midnight UT is when t % 86400 == 0. So if the broadcast time scale were to become TI then these operations would be taking place at "atomic day midnight" instead of mean solar day midnight. That's still a legitimate kind of day. Are there actually serious technical problems (kindly ignore bureaucratic ones about conformance with UTC) with that sort of thing? The argument that "atomic time will drift by no more than a few seconds from mean solar during this century has been used by those who want to abandon leaps. In the presence of an internationally approved atomic time scale I think that argument goes both ways. It doesn't hurt anybody if certain technical operations drift a few seconds from civil wall clock time. It has become clear in the ITU process that a change to the nature of the broadcast time scale cannot be decreed with less than a decade of advance notice. That's enough time to fix a lot of software and throw away a lot of hardware. If getting leaps out of the broadcast time scale is the principal and urgent *technical* goal then it might be far quicker to decide to choose "TI" than to hope for the *political* goals involved in getting the ITU to disregard the history and the words of the CGPM when they recommended UTC as a form of mean solar time. Technicians can adapt a lot faster than politicians. -- Steve Allen WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
In message <20081222160145.gb7...@ucolick.org>, Steve Allen writes: >If getting leaps out of the broadcast time scale is the principal and >urgent *technical* goal [...] No, the principal goal is make sure all UTC days have exactly 86400 seconds, playing games with the names of timescales will not help. -- 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 http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
On Mon, 22 Dec 2008, Steve Allen wrote: > > I am aware of the interesting breakages that happened when zoneinfo > files were retroactively modified to be inconsistent with POSIX. > Clearly that change cannot be done for past history. It can't be done for future history either, because it breaks invariants that are relied on all over the place. > > There is a pervasive assumption in Unix that midnight UT is when > > time_t % 86400 == 0. > > So if the broadcast time scale were to become TI then these operations > would be taking place at "atomic day midnight" instead of mean solar > day midnight. That's still a legitimate kind of day. This isn't about scheduling operations, it's about inter-converting between a count of seconds and broken-down civil time. There are lots of in-kernel functions and standard data formats (network protocols, file systems) that rely on the "trivial UT" assumption of 86400 seconds per day. POSIX time is one example amongst many. > The argument that "atomic time will drift by no more than a few > seconds from mean solar during this century has been used by those who > want to abandon leaps. In the presence of an internationally approved > atomic time scale I think that argument goes both ways. It doesn't > hurt anybody if certain technical operations drift a few seconds from > civil wall clock time. Disseminating a linear timescale instead of UTC doesn't address the problem if civil time continues to be UTC, because all these systems are more tightly coupled to civil time than they are to the timescale of their reference clock(s). Civil time is a pervasive dependency - i.e. lots of software has built-in assumptions about its structure - whereas time synchronization is a relatively self-contained function. Tony. -- f.anthony.n.finchhttp://dotat.at/ LUNDY FASTNET IRISH SEA: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 IN IRISH SEA. MODERATE, OCCASIONALLY ROUGH IN LUNDY AND FASTNET. DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
Poul-Henning Kamp wrote: There is one (major) problem: software does not grok leapseconds. If my car fails to grok gasoline, I fix the car. Leap seconds (or the equivalent) are simply a fact of life on a tidally slowing orb. If you wish to eliminate the overhead of managing leap seconds over the short term, you have to pay the price of managing them over the long term. No such management plan has been proposed. One of the solutions Rob peddles for this, is "Make a new timescale without leap seconds, and leave leap seconds in the UTC timescale". I haven't peddled any solution (other than better managing the status quo). It is premature to discuss solutions as more than brainstorming to better understand the problem at hand. This does not fly because a lot of systems are legally mandated to use the UTC timescale. And others are and have been legally mandated to use mean solar time. The ITU is attempting to separate the two without cleaning up the resulting mess. A better (and quicker) process would be to: 1) understand the problem 2) evaluate possible solutions 3) seek consensus before voting Changing all those laws and regulations, just because a single astronomer is very emotionally attached to the name "UTC" is just not going to happen :-) There are more on this list than a single supporter of preserving the meaning of UTC. This was also the consensus in Torino. Words like "emotionally attached" add nothing to the discussion. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
In message: Tony Finch writes: : On Mon, 22 Dec 2008, Peter Vince wrote: : > : > I am trying to clarify in my mind a couple of proposals, one of which is : > having no more leap-seconds in the civil (broadcast) time scale. I'm : > sorry, I must have missed your messages where you said that a lot of : > software would fail in that scenario - could you briefly clarify please? : : This isn't really about broadcast timescales, but about the semantics of : POSIX time_t. Steve proposes to provide a well-defined uniform timescale : on Unix systems by redefining time_t to follow some linear atomic : timescale instead of UTC, and that the zoneinfo/tzcode library would be : used to translate from this new version of time_t to UTC, using a leap : second table alongside the existing time zone tables. : : The code to implement this has in fact already been written, 15 or more : years ago, but no-one uses it because it breaks too much stuff. For : example, there is a lot of time-handling code in the kernel, and because : it does not link with the tzcode library the proposed architecture doesn't : accommodate its requirements. There's also a lot of code which doesn't use : the C tzcode for time handling, such as the Java runtime. There is a : pervasive assumption in Unix that midnight UT is when t % 86400 == 0. This has been called the 'naive math' problem. Applications don't fill out struct tm's to compute time_t's. If they all did, time_t's definitions wouldn't matter so much. However, many of them *KNOW* that it *IS* seconds since 1970 (with leap seconds swizzled in, so you can ignore them entirely). So the time_t for Feb 15, 2008 1:23:34 is computed like so: time_t t = ((2008 - 1970) * 365 + 9) * 86400 + 1 * 3600 + 23 * 60 + 34; Which is broken with the above software: it is off by the number of leap seconds. There's another problem. NFS requires UTC time stamps (the unredefined time_t values), so you have to know about leap seconds, and when they all happened to get the times right. Again, you could say "who cares" but lots of people do care about pedantic correctness, so you get bugs when things aren't exactly right. These conversions need to happen an all file accesses, so that can have a big negative performance effect, since rather than just copying 4 bytes, you have to do a table lookup (at beast O(ln(#leapseconds)). There's no way to compute leap seconds in the kernel without it. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
On Mon, 22 Dec 2008, M. Warner Losh wrote: > > Applications don't fill out struct tm's to compute time_t's. If they > all did, time_t's definitions wouldn't matter so much. However, many of > them *KNOW* that it *IS* seconds since 1970 (with leap seconds swizzled > in, so you can ignore them entirely). There are good reasons for this. I mentioned Java because libraries for languages other than C often want a native implementation of time and date functions so that they fit in better with the rest of the language. There's also the fact that the standard C library is bad in many ways so it's common for programmers to try to improve on it. Tony. -- f.anthony.n.finchhttp://dotat.at/ HUMBER THAMES DOVER: WEST OR NORTHWEST BACKING SOUTHWEST 4 OR 5, BUT BECOMING VARIABLE 3 IN DOVER. SLIGHT OR MODERATE. MAINLY FAIR. MODERATE OR GOOD, OCCASIONALLY POOR. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
In message <70692779-0276-4cb0-aab5-43a9c2cf9...@noao.edu>, Rob Seaman writes: >And others are and have been legally mandated to use mean solar time. Examples, please ? -- 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 http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
Poul-Henning Kamp wrote: In message <70692779-0276-4cb0-aab5-43a9c2cf9...@noao.edu>, Rob Seaman writes: And others are and have been legally mandated to use mean solar time. Examples, please ? This issue has come up repeatedly. Apparently Denmark: http://www.mail-archive.com/leapsecs@leapsecond.com/msg00509.html And the UK and EU (not sure how EU policies would resolve local differences): http://six.pairlist.net/pipermail/leapsecs/2007-August/91.html In any event, the UTC standard itself originally contained language: "GMT may be regarded as the general equivalent of UT." Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
In message <174da871-5a3d-4558-8522-eae34ba7e...@noao.edu>, Rob Seaman writes: >Poul-Henning Kamp wrote: >>> And others are and have been legally mandated to use mean solar time. >> >> Examples, please ? > >This issue has come up repeatedly. > >Apparently Denmark: > > http://www.mail-archive.com/leapsecs@leapsecond.com/msg00509.html The fact that Denmark does not follow its own law on this point is a severe blow to your argument. Do you have any *real* examples ? -- 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 http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
On Mon, 22 Dec 2008, Poul-Henning Kamp wrote: > > The fact that Denmark does not follow its own law on this point > is a severe blow to your argument. The thing that amused me about the WP7A update was Britain objecting to the demise of leap seconds. Our government abolished the Royal Greenwich Observatory because it had nothing useful left to do. Our timekeeping lab is the National Physical Laboratory. The other major part of the RGO was the Nautical Almanac Office which is now the Hydrographic Office, which produces nautical charts. I doubt we even have any government agency still involved in earth orientation - about the closest we have is the STFC which funds a number of physics and astronomy research facilities. I can't imagine it's that hard to fix our obsolete time legislation, which even the Government ignores - our official time references (MSF, the BBC, the stratim 1 NTP servers at the LINX) are all UTC, not GMT. Bah. On the other hand, perhaps the relevant civil servant doesn't want to put a time-related bill in front of parliament, because they'll probably start blethering about BST, whether the Scots can live with CET, when the Easter Act will be put into force, et cetera ad nauseam, until time runs out and the bill never gets enacted. Bah. Tony. -- f.anthony.n.finchhttp://dotat.at/ HEBRIDES BAILEY FAIR ISLE FAEROES SOUTHEAST ICELAND SOUTHERLY OR SOUTHWESTERLY VEERING WESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN BAILEY AND SOUTHEAST ICELAND, PERHAPS GALE 8 LATER IN HEBRIDES, FAIR ISLE AND FAEROES. VERY ROUGH OR HIGH. OCCASIONAL RAIN THEN MAINLY FAIR. MODERATE OR POOR BECOMING GOOD. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] (no subject)
You appear to be trying to get a rise out of me. Nothing in my previous messages were predicated on the de jure or de facto policies of any governments. That seems to be a facet of your argument. You asked for an example. I provided. You also previously chided me to read the archives. I could advise same. Rob --- On Dec 22, 2008, at 12:23 PM, Poul-Henning Kamp wrote: In message <174da871-5a3d-4558-8522-eae34ba7e...@noao.edu>, Rob Seaman writes: Poul-Henning Kamp wrote: And others are and have been legally mandated to use mean solar time. Examples, please ? This issue has come up repeatedly. Apparently Denmark: http://www.mail-archive.com/leapsecs@leapsecond.com/msg00509.html The fact that Denmark does not follow its own law on this point is a severe blow to your argument. Do you have any *real* examples ? ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
