Re: ideas for new UTC rules
> Am especially baffled at why it wouldn't occur to D-Link that it was
> their responsibility to field their own NTP servers. This is even
They don't even need to do that. They could have simply wired
"pool.ntp.org" into the device. See http://www.pool.ntp.org/ for
more info.
-Tim Shepard
[EMAIL PROTECTED]
Re: Comparing Time Scales
> > A computer system could represent UTC time in a way which also makes > > this clear, for example by a structure or abstract data type which > > includes in it (1) the day number and (2) how-many nanoseconds are we > > into this day. When executing a leap second insertion, we would get > > all the way up to 86,400,999,999,999 nano seconds in the day before we > > wrapped around that field to zero and incremented the day number (one > > nanosecond later). > > How is this really different from using broken-out time and allowing > the seconds field to go up to 60? I would agree. Same idea. -Tim Shepard [EMAIL PROTECTED]
Re: Comparing Time Scales
> No. The article specifically says that after it the system time gets > to ,600, it is decremented by one and there is specific code in the > code that returns the system time to applications that makes it stand > still. The second isn't *NOT* repeated. Repeat: The second is *NOT* > repeated in what they said. Time stands still outside of the kernel, > while inside the kernel the last second of the day *IS* repeated, > hence the need for the limiter that the article talks about. > > Not all kernels keep time standing nearly still during the leap second > (since that has other bad effects). Some expose this decrement to the > users. The highlighed part of what I quoted said exactly this. > > I've actually implemented this for FreeBSD. You are arguing theory, > and I'm arguing the fine points of an actual, real implementation. But there's a difference between NTP timestamps, and the details of the implementation of a system which uses NTP for synchronization. The NTP timestamps have more than 64-bits in them when you include the leap warning bits. NTP timestamps do not repeat any seconds when a leap second occurs. Note that in Figure 8 in RFC-1305 the sequence of NTP timestamps are: 2,871,590,399 + 2,871,590,400 + 2,871,590,400 2,871,590,401 The plus represents the leap warning bits indicating an upcoming (or in-progress) leap second insertion. There are four distinct seconds, each with its own unique timestamp. I'll extend this to include half seconds, just to be very clear: 2,871,590,398.5 + 2,871,590,399.0 + 2,871,590,399.5 + 2,871,590,400.0 + 2,871,590,400.5 + 2,871,590,400.0 2,871,590,400.5 2,871,590,401.0 When the leap warning bits are included, each point in time has a unique time stamp (to the resoultion of the NTP timestamp, which is better than a nanosecond with all 32 bits of fraction). A computer system could represent UTC time in a way which also makes this clear, for example by a structure or abstract data type which includes in it (1) the day number and (2) how-many nanoseconds are we into this day. When executing a leap second insertion, we would get all the way up to 86,400,999,999,999 nano seconds in the day before we wrapped around that field to zero and incremented the day number (one nanosecond later). -Tim Shepard [EMAIL PROTECTED]
Re: wikipedia "Leap Seconds" collaboration
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.
-Tim Shepard
[EMAIL PROTECTED]
distribute TAI as well (was Re: [LEAPSECS] Risks of change to UTC )
> TAI is specifically contraindicated as a time > scale. and > TAI is not currently recommended by its creators as a viable time > scale. I would love to know why. The only hint of a reason I've heard on this list to explain why would also seem to apply to UTC since UTC is defined in terms of TAI ticks. (IIRC the reason was that TAI is constructed after-the-fact from observations between the atomic clocks which are scattered at a number of different locations around the world, so you can only know what time it is TAI after the fact. Well, if that's the problem, then UTC is not any better.) I think we should stop arguing about what other people should use for a time scale and simply distribute both TAI and UT. I believe both kinds of time scales are needed. Some cases only need one kind, other cases need only the other kind. So distribute both and be done with it. Computers getting time over the net should make both kinds of time available to programs. (Why not?) If someone's best judgement is that one kind of timescale is for their purposes better than the other, then they will be free to exercise that judgement. This also avoids the issue of agreeing when to make "the change". UTC can continue to be distributed as it is. Improvements (e.g. to distribute TAI as well, continuously broadcast a complete table of historic and scheduled leap seconds, distribute a higher-precision DUT1, etc.) can be made incrementally without causing a semantic mess and without breaking any properly implemented existing systems. We could start down this road without delay. My hope is that proceeding down this path could make everyone happy. -Tim Shepard [EMAIL PROTECTED]
Re: Internet-Draft on UTC-SLS
> The serious timekeeping people gave up on rubberseconds in 1972 and > I will object with all that I can muster against reinventing them > to paste over a problem that has a multitude of correct solutions. As I learned from a recent posting to this mailing list, it seems that even TAI has rubber seconds (adjustments to the rate is made from time to time to compensate for errors that have been accumulating, making TAI a better (more useful) approximation time). Do you object to those adjustments (rubber seconds) to TAI as well? If so, then what are we to do? (Even two atomic clocks will not run at exactly the same speed, and something must be done to cope with the fact that they will drift apart.) If not, then would you please quantify your threshold of objection regarding the size of changes to the rate of a second of TAI? Is it one ppm, 100 ppb, 10 ppb, 1 ppb, 10^(-10), 10^(-11), 10^(-12), or *what*? > > "Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS)", > > Markus Kuhn, 18-Jan-06. (36752 bytes) > > > > http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt This draft bugs me a bit because it changes the length of a second (as seen by its clients) by a rather large amount (a thousand ppm). A change in rate of one ppm would not bother me, but that would take a bit more than 11.5 days to accomplish the change. A change in rate of ten ppm could accomplish the phase change with less than 1 day's warning before the UTC leap second insertion if accomplishing it could be split between the 50,000 seconds before UTC midnight and the 50,000 seconds after UTC midnight. Hmm -Tim Shepard [EMAIL PROTECTED]
Re: The real problem with leap seconds
> We've recently had a question about this on this list which > wasn't answered clearly. MJD 27123.5 means 12:00:00 on day > 27123 if it's not a leap second day, but what does it mean > on a day with a positive leap second? 12:00:00.5? I think > it only works if that level of precision doesn't matter but > maybe some document somewhere has a convention. I'm not the expert, but I just read through http://en.wikipedia.org/wiki/Julian_day and from what I learned there the answer appears to be that MJD can be either MJD(UT) or MJD(TT), and leap seconds are not involved. So MJD 27123.5 means 12:00:00. on day 27123. MJD(UT) 27123.5 means UT 12:00:00.0 on day 27123. MJD(TT) 27123.5 means TT 12:00:00.0 on day 27123. UTC is an approximation of UT, perhaps the poorest one in the family of UT time scales. If you care about what time it is UT to better than one second, then UTC is probably not the right time scale for you to be using (at least not directly). If a fuzz of +/- 1 second doesn't bother you, then you can pretend that UTC is UT, and things are easier. For the time scale experts on this list, did I get that right? -Tim Shepard [EMAIL PROTECTED]
Re: The real problem with leap seconds
> > I still think NTP should have distribute TAI, but I understand using > > Was your failure to form a past-participle a Freudian slip? I'm with you > if you really mean "NTP should distribute TAI"!!! Uh, probably yes. I didn't even see the grammer error when I re-read it the first time just now. About 15 years ago I came to believe that it would have been better if NTP distributed TAI instead of (or perhaps alongside) UTC. And yes, I still believe that. Now I think it would be best if TAI and UTC were both distributed by time signals (and NTP, etc), with equal emphasis to make it clear to all users that they have a choice to make. Atomic time based on the SI second (TAI) and traditional time based on earth orientation (UT) are both needed in the modern world. Both should be distributed. People who have some need to synchronize clocks should be forced to decide which kind of time would be best for them. (Or perhaps in some cases it would be best for them to implement both side-by-side in their system.) A system which distributes TAI (which never has leap seconds) and also distributes the current number of seconds of offset for UTC, as well as leap warnings (or continuously broadcasts the table of all known (past and scheduled) leap seconds), would seem to be reasonable. This would allow the decisions about what would be the best time scale to use to be made downstream. Build good mechanisms that allow a variety of policies, and leave policies to those downstream of you. My preference would be for civil time keeping to continue to be tied to earth orientation, as it was when GMT was the standard. So UT1 or UTC would continue to be "normal" time, and TAI (or something like it) would be the "weird" time that certain geeks care about. The other alternative would be for civil timekeeping to be based on TAI (something which never has leap seconds), with UTC (or something like it) to be the "weird" time that certain geeks care about. This is the radical proposal, but I can understand that some would want to do this. If humans spread out to other places besides the earth, an earth-centric time scale might begin to seem somewhat quaint. Distributing leap second information to a Mars colony seems kind of silly. (Though I guess that those on a Mars colony would in fact care about earth orientation, e.g. if they wished to communicate with friends back on Earth using their amateur laser-communication gear in their backyards.) I very much dislike the proposal to *redefine* UTC to abolish leap seconds. I dislike very much trying to understand code that was written with descriptive names (for variables, functions, constants, etc) but which has evolved such that what the names apparently mean and what they really mean are very different. UTC is a type of UT time. If you stop putting leap seconds in UTC to keep it close to all the other UT time scales, then it no longer deserves to have a name that starts with UT. So fine, if we must stop maintaining UTC with leap seconds and move civil time keeping users to some sort of new standard, please do *not* call it UTC after the change. The hack of having UTC ticks align with TAI ticks and adjusting UTC with leap seconds was perhaps not the best idea. But it was done, and has been in place for more than 30 years, and is now a widely implemented and understood standard. If this hack should be replaced with something better (and perhaps it should be), I'd want 20 years advance notice that a change is coming, and 15 years advance notice as to what exactly the change will be. (I suspect though I won't get that much notice.) "leap hours" are a horrible idea, whether they be leap hours inserted in to some UTC-like global standard, or by local jurisdictions. Well, those are my opinions. Thanks for listening. -Tim Shepard [EMAIL PROTECTED]
Re: The real problem with leap seconds
> >and you still cannot even get it [TAI] reliably from your > >average local NTP server. > > This is a circular argument: The reason NTP doesn't provide it > is that time_t needs UTC. No, I asked David Mills about 15 or so years ago why NTP distributes UTC and not TAI (me thinking and suggesting that it would have been so much better if NTP distributed TAI) and the reason was quite simple: There was no convenient way to get TAI. The time signals broadcast by WWV and WWVB in the US distributed UTC and leap warning bits, but did not distribute (and still do not AFAIK) what the TAI offset is. GPS receivers were (very) rare back then, so getting GPS time and subtracting out the constant offset to get back to TAI was not a viable option either (though perhaps it would be today, as long as the GPS system keeps running). I still think NTP should have distribute TAI, but I understand using TAI was not practicable option when NTP was designed. BTW, I don't know if the Fuzzball OS had any Posix time_t's in it, or anything resembling them, but I suspect not. I vaguely recall hearing that it had some other way of keeping the time in a collection of 16-bit registers (PDP-11s, don't you know). -Tim Shepard [EMAIL PROTECTED]
Re: went pretty dang smoothly at this end
> The first officer gave us a countdown to midnight in London, and
> I'm happy to report that the plane failed to fall out of the sky,
> explode, or otherwise deviate from its course at 23:59:60.
Did his countdown reach zero at 23:59:60 31-December-2005 UTC or
at 00:00:00 1-January-2006 UTC ?
-Tim Shepard
[EMAIL PROTECTED]
knowing what time it is
I've been lurking on this list for a few months now. About 15 years ago I was playing with NTP on 4.3 BSD unix. I remember thinking then that Posix was making a serious error in specifiying that the time_t returned by time() or in the .tv_sec field of the structure returned by gettimeofday() would contain UTC. TAI would have seemed to be the better choice. I suggested in e-mail to David Mills that NTP should have been built around TAI, not UTC. He did not disagree with me but pointed out that there were no broadcast sources that he could get TAI from, so the choice of UTC was forced upon him. I still think TAI would have been the better choice, and would be the better choice going forward. But existing practice is slow to change, and not easy to change. I think what happened 33 or so years ago is that we went from having a single time scale (GMT) to having multiple time scales (UTC and TAI). What should happen (and what should have happened) is that both time scales should be distributed, side by side, requiring those who need to know what time it is to make a choice about which kind of time scale they wish to have. There's no use pretending that we don't have two time scales. We can argue forever about which should be the prefered "normal" time scale. But regardless of who wins that argument, the losing time scale will not cease to exist. The discussion on this list has been enlightening. I now see that no solution will be simple. But in my mind, the ideal would be if every system that distributes time (e.g. WWV, WWVB, GPS, NTP, etc...) would convey what time it is UTC, what time it is TAI, and what the entire table of leap seconds is (or the 200 or so most recent leap seconds). And systems downstream should try hard not to throw away any of the information, and pass all of it along to whoever gets time from them. I think much of the trouble we are in now is because we have not embraced this notion that there are two timescales involved here. But since 1972 there are two. Neither single timescale will be suitable for all uses. So both are needed. Systems that have any claim to general-puruposefulness need to carry both, along with information about what leap seconds have been and will be inserted. If the bundle of information you got that told you what time it is also told you what leap seconds have been and will be inserted, then all would be OK. Then 6 months would be plenty of warning for pending leap seconds because very few devices are capable of keeping time with 150 ppb accuracy over 6 months running open loop. The mistake is to distribute time without distributing both scales (UTC and TAI) and a table of historical and pending leap seconds. So that's all ideal. But we're in a mess now. Is it reasonable to hope we may be able to somehow get to the ideal I've described? In maybe 10 or 15 years? It seems what is needed most is education. -Tim Shepard [EMAIL PROTECTED]
eBay official time (was Re: Precise time over time )
Tom Van Baak said:
> Things are more precise now;
> [...]
> My favorite example is eBay.
eBay is a great example. The eBay snipers are probably the best
example of a significant number of people who ever care what time it
is to a sub-second precision. (I wonder which community is larger,
astronomers or eBay snipers?)
Which led me to wonder: Has eBay thought about the upcoming leap
second and how are they going to handle it?
Anyone on this list know? Anyone have a good contact at eBay that we
could ask?
-Tim Shepard
[EMAIL PROTECTED]
