Re: Consensus rather than compromise
In message: [EMAIL PROTECTED] Steve Allen [EMAIL PROTECTED] writes: : If POSIX were to fix the definitions of time_t and epoch, why would : this not imply that handling leap seconds with Unix would become : trivial? Because leap seconds are not trivial. If you make time_t a TAI-like thing, then you break all programs that do math to calculate a date and time since the usual naive math no longer works. You could fix these programs to use new APIs to do the math instead. However, you also enforce upon all systems a requirement to keep a leap second table up to date. While not so bad for systems that are constantly running, this can cause problems for people that maintain a stockpile of spare parts. These spares generally aren't on when leap updates occur and won't have them for some period of time after being deployed. Also, many systems just aren't connected to a public network, or aren't connected to a network at all, but still have a need to have knowledge of leap seconds. The class of functions that is defined as being continuous at all points, except where it isn't, while easy to understand can and is hard to implement correctly in all cases. Warner
Re: Consensus rather than compromise
Steve Allen scripsit: Yet the zoneinfo needs to be updated numerous times per year at unpredictable intervals as a result of arbitrary actions by legislatures all over the world. Indeed, but the user has a substantial incentive to update to the latest data if directly affected by the change: the computer's clock will be wrong by an hour. The pressure to update to the latest leap-second table is far less. The additional data required to handle leap seconds in the right versions of zoneinfo is trivially smaller than the geopolitical data, and the scheduling is more predictable. Granted. If POSIX were to fix the definitions of time_t and epoch, why would this not imply that handling leap seconds with Unix would become trivial? Because there is far too much code that believes, for example, that if you add 86400 to a time_t representing 2005-12-31T00:00UTC, you get a time_t representing 2006-01-31T00:00UTC. Or that if you have a time difference in seconds, you can divide by 3600 and get one represented in hours. The upside of Posix is that time arithmetic is simple. The downside is that Posix sometimes lies about elapsed time and labels both a leap second and the preceding second with the same time_t. -- Newbies always ask: John Cowan Elements or attributes? http://www.ccil.org/~cowan Which will serve me best? http://www.reutershealth.com Those who know roar like lions; [EMAIL PROTECTED] Wise hackers smile like tigers. --a tanka, or extended haiku
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]
Re: Consensus rather than compromise
On Wed, Aug 31, 2005 at 11:14:17AM -0400, John.Cowan wrote: Because there is far too much code that believes, for example, that if you add 86400 to a time_t representing 2005-12-31T00:00UTC, you get a time_t representing 2006-01-31T00:00UTC. Or that if you have a And then your whole office would be saying I can't believe it's almost February! It seems like only yesterday it was December. -- trey valenta [EMAIL PROTECTED] seattle, wash. The way to make a small fortune in the commodities market is to start with a large fortune.
Re: Consensus rather than compromise
M. Warner Losh wrote: Also, many systems just aren't connected to a public network, or aren't connected to a network at all, but still have a need to have knowledge of leap seconds. Can you give any examples of systems which need to follow UTC to sub-second accuracy (running to their own little time- zone not being good enough), have a clock stable enough to do so and yet are not connected by any mechanism which could potentially provide leap-second information? Presumably there are a few but I find them hard to imagine. Ed Davies
Re: Consensus rather than compromise
In message: [EMAIL PROTECTED] Ed Davies [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : Also, many systems just aren't connected to a public : network, or aren't connected to a network at all, but still have a : need to have knowledge of leap seconds. : : : Can you give any examples of systems which need to follow : UTC to sub-second accuracy ... have a clock stable enough to : do so and yet are not connected by any mechanism which could : potentially provide leap-second information? First, your question is a bit of a red herring. More systems than just those are affected. If you have system time in TAI, and you want to convert to/from UTC, you must necessarily know all the leap seconds that have ever happend, or you can't do it. The classic example of a system that's not connected to any source of leap seconds is the spare sitting off in the corner. It has no knowledge of leap seconds that happened 6 months after it was made, and has to acquire that knowledge somehow after it is first powered on. However, to answer your hypothetical question directly: Consider a system that has GPS steering a stable time source (say a cesium clock or rubidium standard). GPS goes away for some reason. You have a stable time source for a long period of time, yet no further knowledge of leap seconds. If the system is installed down the block, it is a simple matter to go out and fix the GPS antenna. If the system is in the middle of nowhere in alaska controlling timing signal automatically, it can take a while to get a crew out to fix it. Yet, it is highly desirable that it continue to work for as long as possible. Leap seconds artificially limit how long ntp will work on such a system, for example, because you can't flywheel more than about 6 months since after a leap second opportunity, you don't know if there was one or not. Of course, certain manual proceedures can be put into place for the above example. However, they are added complications that can't be dismissed out of hand. You have to design them well, or you get all kinds of weird edge case behavior. : (running to their own little timezone not being good enough), Might I suggest that digs like this make rational discussions difficult? Warner
Re: Consensus rather than compromise
On Aug 31, 2005, at 9:54 AM, M. Warner Losh wrote: : (running to their own little timezone not being good enough), Might I suggest that digs like this make rational discussions difficult? I agree with the general sentiment - after six years we're all a bit over sensitized and perhaps too willing to take shortcuts in both reading messages and writing our own replies. That said, irony does have a useful place in productive communication - even in highly technical discussions. I have to agree with Ed Davies' assessment of the mechanism being suggested. It does sound like we are being encouraged to replace the worldwide timezone system with the adoption of ad hoc local usage, perhaps down to the level of municipalities and isolated mountaintops. In an extreme analysis, the fix it all in the timezones and leap hours proposal amounts to a return to nineteenth century practices of clock time diverging between one railroad station and the next. I don't believe that extreme would occur any more than you do, but this is the area of phase space we're exploring at the moment. And if a standard were to be implemented that relies on the tweaking of local timezones to compensate for a drifting non-solar fundamental reference, it is not remarkable to expect that mechanisms for avoiding the slapdash creation of ad hoc timezones and for allowing the appropriate tracking of historical timestamps would be considered in advance and perhaps be implemented under the force of law. It isn't sufficient for any of us simply to claim that our own pet proposal has no negative ramifications and to leave it at that. Rob Seaman National Optical Astronomy Observatory
Re: Consensus rather than compromise
On Wed 2005/08/31 07:29:22 +0200, Poul-Henning Kamp wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL If such a system were to be adopted, then in future, in order to determine a historical time, the full record of timezone changes would be needed. How is this different than today ? To determine the civil time in Copenhagen at a specified epoch we take UTC, add the timezone offset then possibly add 1 hour for DST. zoneinfo provides rules for the latter - e.g. DST starts on the first week of March and ends whenever. Currently the timezone offset is essentially fixed for a particular place, yes there are quirks but it's hardly relevant to the argument. Under the proposed scheme, timezone offsets would be a function of epoch as well as place, thus requiring another table for each timezone. However, there would be a fundamental difference between the DST and TZ rules: the former are quantized at 0 or +1, so you can only ever get it wrong by one hour. However, the TZ offset would not be limited in range, over millenia it would span many hours, one hour in the first millenium and accelerating. John Cowan argues that timezones will tend to coalesce as nations reach agreement, but remember that we are talking about timescales of millenia. Over such times nations as a whole don't tend to reach agreement - consider how the Gregorian calendar was adopted piecemeal by different countries (empires really) over centuries. Consider the way the map of Europe has changed since the Roman Empire, or even over the last couple of centuries, or even within our own lifetimes. And consider also the disparate and antagonistic nature of political ideologies in those periods. But the killer is that a timezone only needs to fragment *once* in order to require the creation of a separate TZ rule table. How is it different from having to keep a total history of leapseconds ? The table of leapseconds is a function of time but not place. Mark Calabretta ATNF
Re: Leap seconds BoF
On Wed 2005/08/31 07:30:17 +0200, Poul-Henning Kamp wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL The closest I'll get is Copenhagen Denmark :-( If noone can present your arguments in person then we did also invite a submission. Given the amount of energy expended on this list (far too much for me to keep abreast of!) I would have thought that you might channel some into preparing a few slides. The example of the GPS device in remote Alaska with the atomic clock that loses its antenna, given in a later email by M. Warner Losh might be a good starting point. Can you guys get together behind the scenes and do it? Or must we try to represent your arguments for you? Mark Calabretta ATNF
Re: Consensus rather than compromise
Mark Calabretta scripsit: Currently the timezone offset is essentially fixed for a particular place, yes there are quirks but it's hardly relevant to the argument. If by currently you mean at this very moment, then that's trivially true. If by currently you mean in the last few decades, then it's false. Zoneinfo currently recognizes 365 distinct localities on the basis of nationality or distinct history (since the Epoch, some 1125539538 seconds ago) or both. Of these, only 129 have had a fixed offset since the beginning of LCT in that locality. And of those, 55 have changed their DST rules at least once, leaving only 74 that have been entirely stable. Under the proposed scheme, timezone offsets would be a function of epoch as well as place, thus requiring another table for each timezone. This is already the case: nothing new is needed. However, there would be a fundamental difference between the DST and TZ rules: the former are quantized at 0 or +1, so you can only ever get it wrong by one hour. However, the TZ offset would not be limited in range, over millenia it would span many hours, one hour in the first millenium and accelerating. Eastern Kiribati has already changed from UTC-10 to UTC+14, a 24-hour discrepancy. It'll be a long time before any rotationally induced offset changes will amount to that. Eventually, of course, it'll be impossible to maintain the fiction that the Earth rotates in anything like 24 hours. IIRC the maximum possible slowing before the Earth becomes tidally locked to the Moon is 47 current days; when an hour lasts almost two sleep-wake cycles, the current clock will *have* to be revised. John Cowan argues that timezones will tend to coalesce as nations reach agreement, but remember that we are talking about timescales of millenia. Over such times nations as a whole don't tend to reach agreement - consider how the Gregorian calendar was adopted piecemeal by different countries (empires really) over centuries. A process which is now essentially complete, however. A few countries still use other calendars officially, but the Gregorian calendar is well-known there anyhow. No novel calendar has been adopted anywhere since 1583. But the killer is that a timezone only needs to fragment *once* in order to require the creation of a separate TZ rule table. Quite so, but what of it? People who do not care about LCT in the new locations can ignore the table update; those who do care have a strong incentive to download the new tables. Systems that need not worry about LCT, need not care at all. -- While staying with the Asonu, I met a man from John Cowan the Candensian plane, which is very much like [EMAIL PROTECTED] ours, only more of it consists of Toronto. http://:www.ccil.org/~cowan --Ursula K. Le Guin, Changing Planes
