First, to review, as I noted on this list just over a month ago, there is an IETF NTP working group now, working on version 4: http://www.ietf.org/html.charters/ntp-charter.html NIST has a leap seconds table: ftp://time.nist.gov/pub/leap-seconds.list Current xntpd code can use that table, and transport leap second tables around using an autokey feature: http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/db2f5f47aab68a3d/ There was some discussion of leap seconds at the NTP working group session of the Internet Engineering Task Force (IETF) meeting in Vancouver in September: http://www3.ietf.org/proceedings/05nov/ntp.html It is unclear whether the current autokey security mechanism will end up in an IETF standard, since it is rather different from other standard internet security mechanisms. On Tue, Feb 14, 2006 at 02:28:34PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : On Feb 14, 2006, at 12:50 PM, Markus Kuhn wrote: : : You can, of course, define, publish, implement, and promote a new : version (4?) of NTP that can also diseminate TAI, EOPs, leap-second : tables, and other good things. I'm all for it. : : But why are you for it? Before investing large amounts of time and : money in developing and deploying a large new timekeeping system, : wouldn't one want to invest smaller amounts in exploring the issues : and options? Heck - one has to imagine that a number of successful : grant applications are lurking around here somewhere. Time is an : issue that cuts across every funding agency out there. UTC time stamps in NTP are ambiguous. TAI ones are not. UTC time stamps do not convey enough information to properly implement things like intervals, while TAI ones do. The NTPNG stuff that I've seen appears to consider these problems as worthy of needing a solution and they plan on solving them. It isn't rocket science, but one has to divorce ones self from the chauvinistic view that UTC is always best. For time exchange, it is not the best, and has many problems around the edges. Yes it is messy, but the tradeoffs are complex. I don't think the latest drafts specify NTP timestamps. I suspect they still rely on the leap second bit to disambiguate the timestamp on a leap second, but I haven't checked recently. They are all linked to from the charter page I noted above. Doing NTP with TAI (and the implied requirement for DTAI) doesn't change what time is displayed for users. It does make it *MUCH* easier to get leap seconds right for those users that need them. Anything else is madness. UTC is a display convention, not a sane[*] counting convention. I think that changing to a different over-the-wire timestamp epoch would just add to the confusion, not make things simpler in practice. People still need to know UTC, and transmitting the leap second table info, especially via autokey, is much more complex than the basic protocol. But at least this is a standards process conducted in the open, where you can just get involved directly if you have something to add. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60 Warner [*] All variable radix counting conventions are insane by (my humble) definition :-).
Rob Seaman wrote: I hope we can all continue this discussion in a more positive manner. It is the nature of email lists to be good at stimulating discussion, and bad at generating clear resolutions. Thus was the FAQ born. But we have a more modern technology than FAQs, the wiki, which can more effectively funnel passionate energy from groups of people with diverging ideas into coherent descriptions of a variety of viewpoints, suitable for enlightening the world. Imperfectly, to be sure, but better than a mail list I think the thing we need to do is build on what clarity we can find in the moment, and document it at wikipedia. If the folks discussing the Jesus article can arrive at a relatively stable set of positions (and last time I looked, they had done remarkably well, considering), surely we can also. Note the relatively successful policy of presenting things from a Neutral Pointof View (NPOV): http://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view So would folks be willing to collaborate at http://en.wikipedia.org/wiki/Leap_second and related pages? Cheers, Neal McBurnett http://bcn.boulder.co.us/~neal/ On Sun, Jan 22, 2006 at 11:47:15PM +, Ed Davies wrote: I'm of the opinion that messages on this list (no matter how tricky :-) are always positive. Timekeeping is a fundamental issue. It would be remarkable if there weren't diverse opinions. Any negative aspects of this discussion are related to those who don't choose to participate. Which is to say, those who claim to have decision making authority over UTC at the ITU, for instance. The folks on this list appear to cluster into two groups (speak up if your opinion diverges from both): 1) Civil time should remain layered on UTC. UTC should remain largely unchanged. Leap seconds should continue. and 2) Civil time should be layered on some flavor of interval time. That timescale might be a variation of TAI called TI. TI will not have leap seconds. OK so far. Actually, I've yet to see any argument which would make me deeply unhappy with either of these outcomes. The proposal submitted to the ITU is neither of these. It is: 3) Civil time should remain layered on UTC. UTC should be modified to no longer be a useful approximation to universal time. Leap seconds will be issued 3600 at a time. You all know where I stand - but there are worlds of difference between #2 and #3 as alternatives to #1. All three proposals face the same looming quadratic emergency. Again, OK so far except perhaps a quibble that it seems to be widely expected that the leap hour probably would never happen. What bothers me about this discussion is that we don't seem to be able to get beyond bouncing backwards and forwards between 1 2. As soon as anybody puts up any proposal for further detail with respect to either of these possible outcomes almost all of the response comes back in the form of arguments for the other outcome rather than sensible discussion of the idea in itself. joke Maybe for the next little while we should assume one or other outcomes each week (1 in odd ISO 8601 numbered weeks, 2 in even numbered weeks) and carry on all the discussion in that context. /joke Ed.
On Mon, Jan 23, 2006 at 11:20:45AM -0500, Tim Shepard wrote: Be careful. The goals of the folk on this mailing list and the goals of the wikipedia project are probably not aligned. http://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_not In particular, note the section Wikipedia is not a publisher of original thought. It is certainly possible for people on this list to help improve the wikipedia's coverage of articles related to time keeping, but the wikipedia article is not an appropriate place for a group attempting to hash out a consensus on a mailing list to record all of its thoughts. Thanks - very true. An important point is that folks should include references to other sources. But there are a ton of other sources, and when we're behaving well, we already reference them in these discussions. I think having more folks working on wikipedia will both help our discussion here, and encourage folks to generate web pages and other sources for new proposals. My wikipedia talk page contains a number of relevant policy references, some of which may be a bit dated: http://en.wikipedia.org/wiki/User_talk:Nealmcb And note that it is good practice to discuss major or controvertial proposed changes to, e.g. the leap seconds page, at the associated discussion page, e.g. http://en.wikipedia.org/wiki/Talk:Leap_second Cheers, Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
On Fri, Jan 20, 2006 at 03:12:15PM -0500, John Cowan wrote: Rob Seaman scripsit: Only a minority (small minority, one would think) of systems currently include any DUT1 correction at all - although these will perhaps tend to be the most safety-critical applications. [...] That is, of course, one of the major issues for astronomers - we rely on UTC providing a 0.9s approximation to UT1 and most of our systems don't use DUT1. Even our high precision applications (in either interval or universal time) don't tend to require conversions other than as a preprocessing step. Remediating our systems for such a fundamental change to UTC would involve much larger changes than Y2K did - algorithms and data structures would have to change, not just the width of some string fields and sprinkling some 1900's around. I don't understand this. The first class of applications, those that actually receive DUT1 from somewhere, probably have a hard-coded assumption that |DUT1| never exceeds 0.9s or at worst 1.0s. They would need remediation. The second class, which just assumes UTC = UT1 and doesn't care about subsecond precision, would simply need to be front-ended with a routine that got DUT1 from somewhere and mixed it with TI to generate their own UT1. This is technically remediation, but of a rather black-box kind. I don't do this professionally, but here is my guess, and an attempt at an analogy. Hopefully the pros will correct me if I'm wrong. Imagine if someone changed the definition of the meter so that it changed over time How would you modify your systems to make sure that all your units were consistent - that some contractor didn't foul it up, and give you the wrong measurement, subtly or catastrophically changing the results? Like that fabled Mars mission that failed because some calculations were done with the wrong units? Today, for many systems, we can assume that DUT1 obeys the three-decade-old standard and is less than 0.9 s. If that changes because the definition of UTC changes, we have effectively a whole new unit, a non-UT civil time measure. And made it more confusing by reusing the old name and invalidating megatons of documentation! These astronomical and navigation systems currently get inputs of time from all sorts of other systems and people: other instruments, other computers, sub-contractors, etc. Changing the meaning of UTC would lead to a cascade of systems that changed their own timescales and I/O formats, meaning that auditing the flow of time data between them would get more and more complex for a long time. To sum it up, PLEASE don't fundamentally change the DEFINITION of UTC, or you risk whole new kinds of confusion. Hopefully by now the folks on this list that don't like leap seconds at least have agreed that any change should be to a new time scale like TI, and announced decades in advance. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
On Thu, Jan 19, 2006 at 12:59:42PM +0100, Poul-Henning Kamp wrote: I would far rather we tried to define a time API for POSIX to adopt that makes sense. By make sense I mean: o conforms to relevant international standards ie: recognizes the defininition of leap seconds since for all purposes and intents we're probably stuck with the blasted things for another 20 years. o is workable from a computer architecture point of view no more pseudo-decimal timeval/timespec idiocy. o Caters to the needs of relevant user communities. Now you're talking sense, Poul! Thanks for your proposal. Here's a strawman: Use a 128 bit signed integer. Assign the top 120 bits as one integer field with resolution of 1/2^56 seconds. Assign the bottom 8 bits to an enum containing the timescale in question. Assign different timescales very different numeric epochs: TAI:1972-01-01 00:00:00 UTC For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together. (I've seen more specific references that TAI was set according to both UT2 and UT1 - but they weren't the same then. Perhaps within known error at the time?) UTC:MJD's epoch. That would be midnight in Greenwich of 1858-11-17. I don't see the connection, and picking a time for which we don't know UT1 pretty accurately and authoritatively will cause all kinds of arguments. I'd pick 1972-01-01, after the rubber-second era, and so that there is an integer number of seconds difference, as usual. UT1:Flamsteads birthday ? Cute. 1646-08-19 NTP:defined in RFC1305 == 1900-01-01 Define functions to convert from one timescale to another and define ERANGE as a return value when outside the functions ability to do so (ie: future dates on UTC). Define a compact ascii (no i18n!) representation for machine readable use. (Ie: XML, protocols etc). Very clearly spell out that any timezone adjustments must be carried out-of-band to this field. Assign the UTC timescale a identifier of zero. Advantages: Sufficient resolution to represent any likely physical measurement or realizable frequency for the forseeable future (13.8e-18 seconds resolution). Extracting the whole second part can be done by accessing only the top 64 bits (which are enough to contain all of history and then some). Conversion to/from NTP timestamps is trivial. Conversion to time_t is a matter of addition and extraction of the relevant 32 bits. The binary format makes for fast and efficient arithmetic. By assigning the UTC timescale an identifier of zero, the majority of implementations can disrecard the multiple timescale aspect in total. Small platform implementations can use a smaller width, for instance 64 bits split 48/16 and easily transform to standard format by zero extension. That would work for 9 million years or so. High quality implementations will check the bottom 8 bits for identity and fail operations that mix but don't match timescales. Different epochs will make it painfully obvious when people mix but don't match timescales in low quality implementations. Now we just need a name for the proposal Neal McBurnett http://bcn.boulder.co.us/~neal/ -- 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.
This should provide some more grist for understanding the reality of civil time. This happens pretty often somewhere in the world. A DOT final ruling on Indiana came out today, affecting time zones starting April 2, 2006: http://www.dot.gov/affairs/dot0406.htm Under the Uniform Time Act of 1966, the Secretary of Transportation has the authority to set time-zone boundaries and must base decisions on the convenience of commerce. ... After five months, 22 hours of public hearing testimony and more than 6,000 public comments, the U.S. Department of Transportation today announced a final rule that will change the clock for eight of 17 Indiana counties seeking to move to the Central time zone. ... Seventeen Indiana counties asked the Department last September to change from Eastern to Central time. On Oct. 25, the Department issued a notice proposing Knox, Perry, Pike, St. Joseph and Starke counties move from Eastern to Central time, and made no change to time zones in the remaining 12 counties. ... I heard about this from the time zone mailing list. See e.g. http://www.twinsun.com/tz/tz-link.htm Deborah Goldsmith writes to [EMAIL PROTECTED] about it: Based on my reading of this document, only one zone in tzdata is affected, America/Indiana/Knox. That zone will start observing US Central Time starting April 2, 2006, at the time of the switchover to Daylight Savings Time. Probably the easiest thing to do is to change the last two lines as follows: From: -5:00 - EST 2006 -5:00 US E%sT to: -5:00 - EST 2006 Apr 2 2:00 -5:00 US C%sT Will your computer's time zone databases be up-to-date then? Cheers, Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
On Sat, Jan 14, 2006 at 02:09:20AM -0700, Rob Seaman wrote: On Jan 13, 2006, at 12:46 AM, John Cowan wrote: In the end, it will be impossible to maintain the notion that a solar day is 24h of 60m of 60s each: we wind up, IIRC, with the solar day and lunar month both at about 47 current solar days. There's a lot of difference between what happens over a billion years and a million years. Length of day increases only about 20s per million years. Should we be here to care in a million years, only a 1/4 of 1/10 of one percent tweak to the length of the civil second would suffice to allow our Babylonian clock paradigm to continue in use. Of course, since there is a future time of equilibrium (though a long time off...), the quadratic nature of the accumulation of leap seconds will also stop at some point, and eventually we won't need them any more. I hope the 47 day calculation takes the solar tidal influences into effect, and that the moon has to overcome that. It makes me wonder when the maximum rate of change in length of day will come? Not that we need to plan for events that far in the future - just some fun astronomy Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
On Fri, Jan 13, 2006 at 11:32:36AM -0700, Warner Losh wrote: Has anybody compiled a canonical list of the standards in this area? This is the first, I think I've seen ISO 8601 mentioned. As usual, the IETF does a much better job than the ITU of making this stuff available to the general public. See RFC 3339 Date and Time on the Internet: Timestamps http://www.potaroo.net/ietf/idref/rfc3339/ This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Written via an open process; free for all to read, copy, distribute, implement, or be involved in improvements to; with a complete ABNF syntax specification; compatible with ISO 8601 but without a sufeit of unnecessary alternative formats like ISO 8601. Includes a short section on Leap Seconds, lots of info on time zones, etc. LEAPSECS members Markus Kuhn and myself contributed suggestions to it. And as I noted earlier, the IETF ntp working group is working on updating the NTP standard (RFC1305 on NTP version 3, RFC2030 on SNTP version 4), again in a relatively refreshing and open manner: http://ietf.org/html.charters/ntp-charter.html http://www.potaroo.net/ietf/idref/rfc1305/ Join us and get a standard TAI spec for NTP! Cheers, Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
I referenced this page, but missed the most interesting part of it: http://www.exo.net/~pauld/physics/tides/tidalevolution.htm The height of a tidal bulge on a planet is proportional to the inverse cube of the distance between the planet and the object causing the tidal bulge. The torque which slows down the planet is proportional to the inverse sixth power of the distance. presumably because the the same third power works both on the size of the bulge and the differential pull on the bulge. That suggests that Phobos might raise a lower tide than the sun, but yet have a greater tidal braking effect. But I expect the speed of response of the planet to the tidal force could still play a role in comparing the Phobos and solar effects. Data on the speed of change of the orbit of Phobos combined with the conservation of angular momentum should give a good handle on the size of the effect from Phobox. http://en.wikipedia.org/wiki/Phobos_%28moon%29 tidal forces are lowering its orbit, currently at the rate of about 1.8 metres per century, and in about 50 million years it will either impact the surface of Mars or (more likely) break up into a planetary ring. But its too late to do that math tonight -Neal On Wed, Jan 11, 2006 at 11:41:27PM -0700, Neal McBurnett wrote: On Wed, Jan 11, 2006 at 11:44:13PM -0500, John Cowan wrote: I wouldn't be too quick to dismiss tidal braking from Phobos. It's awfully close to Mars, and tidal braking is as you say an inverse-cube effect. The formula (kai Wikipedia) is (2GMmr)/R^3, where M and m are the masses, r is the radius of the primary, and R is the orbital radius of the secondary. The mass of the Earth-Moon system is eight orders of magnitude larger than the Mars-Phobos system, and the radius of Earth I assume you mean the mass of phobos vs the mass of the moon, not the systems, since that is what fits in the raw numbers and equations you provide. But that is less than 7 orders of magnitude different, as I read your reference. is only twice the radius of Mars, but the ratio of the cubed orbital radii is five orders larger for Phobos than for the Moon. So the tidal acceleration of the Moon toward the Earth is only some three orders larger than Phobos's toward Mars. That puts the effect in the same ballpark. But the tides from the sun are very significant on earth, and much more pronounced on mars. (See http://www.madsci.org/posts/archives/oct98/908453811.As.r.html for the relevant masses and radii.) A quick google search for mars tides yields much more useful and interesting answers. http://www.findarticles.com/p/articles/mi_m1134/is_5_112/ai_102275148 the solid-body tides on Mars--caused by the Sun, not by a Martian satellite--are large enough to indicate that at least part of that planet's core is liquid. ... Early in the study, the investigators realized only a liquid core could give rise to a tidal bulge capable of having the observed gravitational effect on the spacecraft. And how much bulge is that? About a third of an inch. Fluid core size of Mars from detection of the solar tide, Science 300:299-303, April 11,2003) But of course we need to treat the web with some skepticism. I doubt this tidbit got it right about what causes the tides (Phobos vs the sun): http://ganymede.ipgp.jussieu.fr/GB/projets/netlander/ Another way to proceed will be to measure tides produced by Phobos, one of Mars' moons. Those tides are 10 times lower than the tides produced by the Earth' Moon. As for changes in the length of the day, we have to look at the mechanism by which tides relate to the slowing of the day: http://www.exo.net/~pauld/physics/tides/tidalevolution.htm There are also tides in the solid earth. The tidal bulge is about 1 meter high. The moon pulls up this tidal bulge on the earth, there is a time delay between the pull of the moon and the time when the tidal bulge reaches its maximum height. During this time the rotation of the earth carries this tidal bulge around the planet in the direction of rotation. The moon then pulls on the mass of the tidal bulge and slows the rotation of the earth. So the degree of slowing is affected by both the size of the bulge, how delayed the bulge is, and the angular velocity of the body giving rise to the tides, making it harder to compare the effects of the sun with rapidly-moving phobos. That is what would relate to this aspect of your question: How much difference in actual slowing can be attributed to Earth's ocean and Mars's lack of one I don't know. I also note that the axial orientation of Mars changes widely back and forth, which would clearly affect the long term effects due to the sun: While Earth's tilt varies from 23 to 25 degrees, the Red Planet's actually shifts from 15 to 40 degrees over a 100 million year period I don't see a handy reference to pull all that together
On Sat, Jan 07, 2006 at 04:02:04PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ed Davies writes: Ignoring the ridiculous parody - no, it's not a weird concept. Different timescales are useful for different purposes. Get used to it. I have no problems with different timescales for different purposes. For instance I very much wish the Astronomers would start to use UT1, which is very much their timescale, and stop abusing UTC, which isn't, as a convenient approximation. But I have big problems with people who want to introduce more timescales without thinking through the legal and technical complications. Yes And with people that want to redefine existing time scales so they mean one thing in one era, and another thing in a different era. As happened with GMT, or the proposed changes to UTC. The question is, where in the range of possible timescales is it most useful to put civil time. Civil time is in the hands of individual governments, and they tend to expect their computers to use the same time as the rest of their country. Yes again. And they are free to choose TAI if they want a uniform time scale. But why take the choice of a UTC that remains within 0.9s of the earth's average rotation rate? Nobody here is in any position to do anything about civil time or legal time, neither are we in a position to introduce a computer time scale in a pathetic attempt to paste over leap seconds. Here we disagree. I guess you're confirming what is in fact the current problem as I see it. We're here because an ITU committee, shrouded in secrecy, is trying to redefine UTC and the international distribution of time signals, which most jurisdictions rely on one way or another as civil time. But the way the ITU works undermines the sort of open and informed discussion that is necessary for an issue so sweeping in its legal, practical and philosophical implications. The thing that is most flawed here is the process. We can talk about _representation_ of a given timescale in computers, but there are far too many laws to rewrite if we want to dictate which timescale they should use. But it is inappropriate for ITU to do an end-run around the laws, and redefine the timescale so that it swings an extra hour back and forth. Some folks here suggest that legislatures just change their timezones periodically, forced by the actions of the ITU. But data was presented in Torino suggesting a cost to NASA and US DoD of a half a billion dollars to study, re-engineer and test their systems if UTC diverges markedly from UT1. Not an easy thing for a legislature to deal with. Again - it's a process problem The only time there has been an inclulsive international meeting devoted to the issue, at the colloquium in Torino, There was no overwhelming consensus on whether the status quo should be maintained or an alternative should be pursued. But If a change were to be made one alternative appeared to be preferred. The essence of this alternative was as follows: 1. Any change should slowly evolve from the current UTC Standard in transitioning to a uniform timescale, perhaps to be called Temps International (TI). 2. A suggested date for inaugurating any change would be 2022, the 50 TH anniversary of the UTC timescale. The date suggested is influenced by the lifetimes of existing systems that would be expensive to change. [http://www.ien.it/luc/cesio/itu/annex_a.pdf] So it is distressing to see committee members of the ITU headed in a different direction. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60 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.
On Wed, Jan 04, 2006 at 07:36:17AM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Neal McBurnett writes: On Tue, Jan 03, 2006 at 08:32:08PM +0100, Poul-Henning Kamp wrote: If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need to update the factory installed table of leapseconds. Do you have any evidence for this assertion? It is an educated guess. The IERS have already indicated that they belive they could do prediction under the 0.9 second tolerance with two or three year horizon. The Torino Colloquium had some discussion of this. Proceedings of the Colloquium on the UTC Timescale held by ITU-R SRG 7A http://www.ien.it/luc/cesio/itu/ITU.shtml Prediction of Universal Time and LOD Variation D. Gambis and C. Bizouard, (IERS) http://www.ien.it/luc/cesio/itu/gambis.pdf After a bunch of nice graphs (not all of which were easy to interpret) I found the periodogram (essentially a discrete Fourier transform of the input data) interesting. The way I read it (expert advice welcomed), the broad peaks at 26 years (0.6 ms/d) and 52 years (0.3 ms/d) suggest that the most common pattern is a gradual cycle a few decades long of lengthening and shortening of the day, presumably driven by movements in the earth's mantle and core. Page 14 of the pdf has a table: Skill of the UT1 prediction statistics over 1963-2003 Horizon Prediction accuracy in ms 3 years 308 2 years 163 1 year 68 180 days 36 90 days21 30 days 7 10 days 3 Perhaps these are worst cases? It would be nice to have confidence intervals. They presented these conclusions: Possibility to predict UT1 with a 1s accuracy at least over 4 years using a simple method : seasonal, bias and drift. New prediction methods are under investigation (Singular Spectrum Analysis, neural network,..) Possibility to use Core Angular Momentum prediction for decadal modeling Steve Allen wrote: http://www.ucolick.org/~sla/leapsecs/McCarthy.html This deserves discussion and analysis and explanation. I wrote Dennis McCarthy about that, and he said he'd look up the details and get back to me next week. But he did remind me of this, which I remember seeing in data they published via ftp years ago: Regarding the accuracy of these long-term predictions, the IERS Rapid Service and Prediction Center located at the U. S. Naval Observatory does make predictions of Delta-T in the IERS Annual Report. The algorithm for those predictions was determined empirically by testing a wide range of possibilities. It is essentially an auto-regressive model using the past ten years of data. The accuracy based on comparison of observations with what would have been predicted using that model is shown in the table below. Note that the accuracy estimates are 1-sigma estimates and that excursions of 2-sigma (or more) may not be unexpected. +-+ |Year in the Future|Accuracy (1s) (seconds| |--+--| |1 | .04 | |--+--| |2 | .08 | |--+--| |3 | .3 | |--+--| |4 | .8 | |--+--| |5 | 1. | |--+--| |6 | 2. | |--+--| |7 | 2. | |--+--| |8 | 3. | |--+--| |9 | 4. | +-+ The http://www.iers.org/ points eventually to http://18.104.22.168/MainDisp.csl?pid=47-25786 but the links from there to the annual reports seem broken right now. I still haven't seen any good data on predictions for periods of longer than 9 years. Neal McBurnett http://bcn.boulder.co.us/~neal/
On Wed, Jan 04, 2006 at 08:24:39PM +, Ed Mirmak wrote: Those who have submitted data, plots, or descriptions of system response to the leap second addition may want to forward those messages to ITU WP-7A. Related to the Nov 2005 U.S. proposal to the ITU to redefine UTC and abandon leap seconds, they are soliciting information from various sources on both positive and negative experiences. See: http://www.bipm.fr/en/scientific/tai/future_utc.html http://www.bipm.fr/utils/en/pdf/ITU-R_leapseconds_letter.pdf They give two different e-mail addresses. From the first web page: Responses can be sent before 13 February 2006 to [EMAIL PROTECTED], indicating 'UTC consultation' in the subject of the message. From the letter, e-mail address is: [EMAIL PROTECTED] This is so sadly typical of this whole closed ITU process. The letter and request, dated December 7, 2005, took over a month to reach the leapsecs list, the open list of people with a deep interest in and experience in the subject. The PDF letter itself is unnecessarily hard to forward, archive, search, translate or use because it is in scanned image format, not e.g. text or HTML. When was this actually published? E.g. I find no links via google to http://www.bipm.fr/en/scientific/tai/future_utc.html And the proposal itself remains unavailable outside the inner circle as far as I've seen, despite requests from me and others to open it up. All I get when I go to their page http://www.itu.int/md/meetingdoc.asp?type=sitemslang=eparent=R03-WP7A-C-0021 and request a document is a request for a TIES account, whatever that is. I urge people to share their reports openly with the world by posting them on the web and sending them to the leapsecs list or other open forums. And I urge the ITU to open up their process. http://rom.usno.navy.mil/archives/leapsecs.html http://firstname.lastname@example.org/ Neal McBurnett http://bcn.boulder.co.us/~neal/
On Tue, Jan 03, 2006 at 08:32:08PM +0100, Poul-Henning Kamp wrote: If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need to update the factory installed table of leapseconds. Do you have any evidence for this assertion? It seems to me that if IERS had presented a table in 1980, based on the conventional wisdom that the earth is continuing to slow down over time, we'd have been at the edge of that 10-second window in 2000. And who knows how far off a 1995 prediction would be in 2015, or what decadal fluctuations have in store for us in the future. http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html Anyone have a prediction algorithm in mind, and a result of running it on the last several decades or centuries of data? Neal McBurnett http://bcn.boulder.co.us/~neal/
There is an interesting thread at http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/30a0f68a30f83f1e/ in which Bruce Penrod notes that some of their customers didn't configuree their CDMA cell phone basestations right: We are pleased to announce that our GPS NTP servers and our CDMA NTP servers configured in user leap mode performed the leap properly this afternoon. We are aware that some of the cellular basestations set the leap second a day early, and some PCS basestations have still not set it. We regret that some customers apparently had not configured their NTP servers to operate in user leap second mode, and apologize for any problems this might have caused. David L. Mills writes: There is an obvious remedy here. If your unit implements Autokey, and it does implement just about everything else, it could run in TAI and deliver the UTC offsets in an extension field. I would be happy to collaborate on an RFC to that effect. I also note this at http://www.eecis.udel.edu/~mills/ntp.html: Recently, the precision time kernel support now incorporated in the kernels for Tru64, Solaris, Linux and FreeBSD has been updated to improve accuracy and resolution to the nanosecond. In addition, a plan has been worked out with NIST for the distribution of International Atomic Time (TAI) via NTP using the Autokey protocol. I'd love to see TAI over NTP, and am glad to see some motion in that direction. Anyone know more? Cheers, Neal McBurnett http://bcn.boulder.co.us/~neal/
I hadn't run across NIST's leap seconds table before: ftp://time.nist.gov/pub/leap-seconds.list I'm finally beginning to catch up on NTP developments over the last several years, and find that current xntpd code can use that table, and transport leap second tables around using an autokey feature: http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/db2f5f47aab68a3d/ There is an IETF NTP working group now: http://ietf.org/html.charters/ntp-charter.html There was some discussion of leap seconds at the NTP working group session of the Internet Engineering Task Force (IETF) meeting in Vancouver in September: http://www3.ietf.org/proceedings/05nov/ntp.html It is unclear whether the current autokey security mechanism will end up in an IETF standard, since it is rather different from other standard internet security mechanisms. That meeting also mentions IEEE 1588-2002 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. See http://ieee1588.nist.gov/ It seems that IEEE 1588 time bases are continuous from a defined epoch, but I don't know much more about that. There was also a note in the IETF meeting of possible leap second issues in the RTP protocol. There was later discussion on the NTP working group mail list about sending in comments to the ITU. Here is Steve Allen's comment, cogent as always, and links to the rest: http://lists.ntp.isc.org/pipermail/ntpwg/2005-October/000165.html I don't know if they ever sent in comments to ITU. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
Here are some notes on facilities in some Unix systems to show evidence of leap seconds. Some recent distributions are out of date as noted below. Can folks check others (Solaris, *BSD, etc?). First, this should work for everyone who cares about time and runs ntp. Make sure you're in NTP sync with a host that knows a leap second is coming. Look for leap=01 in the output of this: $ ntpq -c rv assID=0 status=46f4 leap_add_sec, sync_ntp, 15 events, event_peer/strat_chg, version=ntpd [EMAIL PROTECTED]:4.2.0a-11-r Mon Mar 14 12:39:28 GMT 2005 (1)?, processor=i686, system=Linux/2.6.10-6-386, leap=01, stratum=3, precision=-19, rootdelay=158.366, rootdispersion=77.103, peer=17708, refid=22.214.171.124, reftime=c76127cd.19f9acff Sat, Dec 31 2005 8:52:45.101, poll=7, clock=0xc7612b1b.74322291, state=4, offset=-0.430, frequency=37.132, error=0.572, jitter=1.795, stability=64.092 Next check to see if your time zone files are up-to-date. I'm no expert (help!) but it appears that on many Unix systems, the Olson notion of right/ timezones allows the system to understand leap seconds. E.g. note the back-to-back output of two date commands, with and without the right/ timezone prefix: $ date; TZ=right/US/Mountain date; Sat Dec 31 09:56:22 MST 2005 Sat Dec 31 09:56:00 MST 2005 That prefix tells the date command that the system clock includes all seconds (including leap seconds) since the unix epoch in 1970. Since that is not true on my machine, it is off by the 22 leap seconds since then. But will it know about the 23rd one tomorrow? That depends on up-to-date timezone files. The zdump command shows time discontinuities (daylight savings, leap seconds, and legal changes) for the files installed somewhere like /usr/share/zoneinfo. E.g. here is an excerpt of its output on my Ubuntu 5.10 (Breezy) system: $ zdump -v right/UTC ... right/UTC Thu Dec 31 23:59:60 1998 UTC = Thu Dec 31 23:59:60 1998 UTC isdst=0 gmtoff=0 right/UTC Fri Jan 1 00:00:00 1999 UTC = Fri Jan 1 00:00:00 1999 UTC isdst=0 gmtoff=0 Note the famous 23:59:60 entry for the last leap second. But note that it dosen't now about the 2005 leap second, despite the fact that my release of Ubuntu came out in October of 2005. The Debian releases, including unstable, don't seem to be updated either. But Redhat's Fedora core 4 is up-to-date, as are RHEL and centos. zdump works for other time zones also, including daylight savings times changes: $ zdump -v right/US/Mountain | grep 1998 right/US/Mountain Sun Apr 5 08:59:59 1998 UTC = Sun Apr 5 01:59:59 1998 MST isdst=0 gmtoff=-25200 right/US/Mountain Sun Apr 5 09:00:00 1998 UTC = Sun Apr 5 03:00:00 1998 MDT isdst=1 gmtoff=-21600 right/US/Mountain Sun Oct 25 07:59:59 1998 UTC = Sun Oct 25 01:59:59 1998 MDT isdst=1 gmtoff=-21600 right/US/Mountain Sun Oct 25 08:00:00 1998 UTC = Sun Oct 25 01:00:00 1998 MST isdst=0 gmtoff=-25200 right/US/Mountain Thu Dec 31 23:59:60 1998 UTC = Thu Dec 31 16:59:60 1998 MST isdst=0 gmtoff=-25200 right/US/Mountain Fri Jan 1 00:00:00 1999 UTC = Thu Dec 31 17:00:00 1998 MST isdst=0 gmtoff=-25200 $ zdump -v right/US/Mountain | grep 2005 right/US/Mountain Sun Oct 30 07:59:59 2005 UTC = Sun Oct 30 01:59:59 2005 MDT isdst=1 gmtoff=-21600 right/US/Mountain Sun Oct 30 08:00:00 2005 UTC = Sun Oct 30 01:00:00 2005 MST isdst=0 gmtoff=-25200 You can get updated time zone tables as indicated at http://www.twinsun.com/tz/tz-link.htm It also includes changes for US daylight savings in 2007. The package that needs updating for Debian and Ubuntu is libc6 Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
Thanks to Steve Allen for his excellent efforts to enable public discussion of the proposals to abolish leap seconds, difficult though that task has been, given the official secrecy that has surrounded it. See e.g. this quote from a Wall Street Journal article in July Why the US wants to end link between time and sun http://www.post-gazette.com/pg/05210/545823.stm For now, U.S. officials still regard their proposal as secret, despite Dr. Gambis's email and the public comments. The head of America's delegation to the ITU's timing committee, D. Wayne Hanson of the National Institute of Standards and Technology, declined to take calls on the matter. Through a spokeswoman, he said that the U.S. proposal is a private matter internal to the ITU and not for public discussion. For a while, the proposal was made public: On Wed, Sep 28, 2005 at 06:33:22AM -0700, Steve Allen wrote: The draft US document which is under consideration for submission is available for review and still open for comment http://www.fcc.gov/ib/sand/irb/weritacrnc/review/nc1985wp7a/01.doc The significant difference from last year seems to be that leap seconds would stop not in 2007 but rather five years after the ITU general assembly approves the change. This URL no longer works, but yields this un-encouraging message: Not Found The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it. [They could at least offer some entertainment under the circumstances :-) e.g. Marvin the Paranoid Android moans about requests for missing pages: http://bcn.boulder.co.us/~neal/humor/marvin-the-server-404.html ] If anyone knows of a new place to find the latest proposal, please post it. And does anyone know where to find an archive of the comments made in response to the proposal? In the meantime, I highly recommend Steve's excellent web page at http://www.ucolick.org/~sla/leapsecs/nc1985wp7a.html which summarizes the cogent arguments of who disagrees with the proposal. Neal McBurnett http://bcn.boulder.co.us/~neal/
I can post to the leapsecs list, but like some other people, I haven't gotten any mail from it for over a month. FYI, here is an update from the admin at USNO: - Forwarded message from David Johns [EMAIL PROTECTED] - Sorry about the problems with the mailing list. It's very old software and hardware and I can't figure out the current problem. Demetrios is currently talking to Tom Van Baak about taking over the list. Hope things improve in the future. I agree entirely with USNO that LISTPROC is very old software. I wish I had a sense for how many people are no longer getting the list. I hope Demetrios and Tom come up with a good solution soon. I'd recommend Mailman, myself. I think it is important that the list archives are also ported. If necessary, I can also help finding a host for the list. Neal McBurnett http://bcn.boulder.co.us/~neal/
Thanks to Steve for the reference: http://danof.obspm.fr/IAU_resolutions/Resol-UAI.htm I reproduce below a resolution of more specific relevance to this discussion that was made at that meeting of the International Astronomical Union. I'm glad the IAU is looking at a wider range of options than the International Telecommunication Union Radiocommunication Study Group is. The IAU working group is due to report in mid-2003. Who knows more about this IAU working group and their discussions? This brings up the broader question of who is involved in this decision making process. ITU CCIR Recommendation 460-4. (188) is available at http://www.cl.cam.ac.uk/~mgk25/volatile/ITU-R-TF.460-4.pdf It is RECOMMENDATION 460-4 STANDARD-FREQUENCY AND TIME-SIGNAL EMISSIONS and contains this language: UTC is the time-scale maintained by the BIPM, with assistance from the International Earth Rotation Service (IERS), which forms the basis of a coordinated dissemination of standard frequencies and time signals. That leads me to believe that while the ITU wrote the recommendation on how to *disseminate* UTC, the actual legal basis for determining UTC rests with the BIPM, which is part of the General Conference on Weights and Measures, which also handles the International System of Units (SI). http://www.bipm.fr/enus/ Neal McBurnett http://bcn.boulder.co.us/~neal/ GPG/PGP signed and/or sealed mail encouraged. Keyid: 2C9EBA60 IAU Resolutions Adopted at the 24th General Assembly (Manchester, August 2000) Resolution B2 Coordinated Universal Time The XXIVth International Astronomical Union General Assembly, Recognising 1. that the definition of Coordinated Universal Time (UTC) relies on the astronomical observation of the UT1 time scale in order to introduce leap seconds, 2. that the unpredictability of leap seconds affects modern communication and navigation systems, 3. that astronomical observations provide an accurate estimate of the secular deceleration of the Earth?s rate of rotation, Recommends 1. that the IAU establish a working group reporting to Division I at the General Assembly in 2003 to consider the redefinition of UTC, 2. that this study discuss whether there is a requirement for leap seconds, the possibility of inserting leap seconds at pre-determined intervals, and the tolerance limits for UT1-UTC, and 3. that this study be undertaken in cooperation with the appropriate groups of the International Union of Radio Science (URSI), the International Telecommunications Union (ITU-R), the International Bureau for Weights and Measures (BIPM), the International Earth Rotation Service (IERS), and relevant navigational agencies. On Thu, Jan 30, 2003 at 04:25:22PM -0800, Steve Allen wrote: The resolutions that have established the change have happened over the past four meetings of IAU General Assembly. The most recent set of resolutions which switched things from the old, non-inertial definitions to the new ones is visible at http://danof.obspm.fr/IAU_resolutions/Resol-UAI.htm