Re: A lurker surfaces
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Rob Seaman writes: Jim Palfreyman wrote: Just a reminder that UTC has no - none - nada - discontinuities. Various computer mis-implementations may, but the standard is very carefully constructed to avoid spring-forward or fall-back gaps or do- overs. Rob, If you feel uncomfortable with calling leapseconds discontinuities, then we can use the term arrhythmia instead. If we assume that every month has 30 days and obtain a day number by multiplying the month number by 30 and adding the day in month (call this the SDN - Silly Day Number) and then look at SDN-MJD (modified Julian day number) we would see discontinuities. The only way to see discontinuities in UTC-TAI is by making an equally silly assumption in numbering the seconds of UTC: assuming all UTC minutes are 60 seconds or, equivalently, all UTC days are 86 400 seconds. The unfortunate thing is that people actually do think of it this way. E.g.: http://hpiers.obspm.fr/eop-pc/earthor/utc/TAI-UTC_tab.html The whole idea of the expression UTC-TAI being meaningful and evaluating to a number of seconds is a convenient but rather sloppy shorthand. Any strongly typed programming language ought to give a type error on that expression. UTC times of day are variable radix - in just the same way as days and months are in the Gregorian calendar. Except, of course, that the Gregorian calendar is fixed and completely predicable. I have an awful lot of sympathy for the idea of making leap seconds predictable over longer periods, even if it risks UTC-UT1 becoming larger than at present allowed. Ed.
Re: A lurker surfaces
On Sun 2006-12-31T07:59:35 +, Poul-Henning Kamp hath writ: Rob, If you feel uncomfortable with calling leapseconds discontinuities, then we can use the term arrhythmia instead. The point of my allegory about unplanned pregnancies is that all practically available time scales have arrhythmias. Almost everything has jumps at some point during power on self test, and the national time bureaus (and the GPS almanac) publish their current estimate of their deviation from regularity. If you can handle leap seconds, then you can handle reality. The decision made 37 years ago was that the reality of most systems didn't/couldn't care about seconds, and that's the part that now is getting scrutiny. What tweaks me is that I get the impression that a lot of folks are perfectly willing to accept those irregularities and to let Dave Mills diddle with the rates of their system clocks so long as they never have to admit the existence of a named leap second. It's as if everything is okay so long as the baby never comes to term -- everyone can live in denial about those things going on behind the scenes -- but as soon as the county recorder gets that birth certificate with Mr. Astronomer named as father the social order of the world breaks down. I see this as a form of denial. Almost all applications may be capable of tolerating the level of irregularity in the currently practically available time scales, but they are irregular. What happens in a world with terabit per second information streams coming over fibers from sources whose clocks, even if they are ion-trap clocks (especially if so), are different tidal potentials that vary diurnally? (Of course the glib answer is that if the optical fiber engineers do manage to notice this first then they will win the Nobel prize just as surely as Penzias and Wilson did after they found that cleaning pigeon shit out of their microwave horns did not manage to make the background noise go away.) What happens in a world where systems begin to be sensitive to the effective leap microseconds or variations in length of seconds which happen even if Dave Mills is conditioning their clocks? It's my expectation that if all systems are allowed to deny the reality of precision time keeping we will eventually find ourselves living in a timekeeping world that resembles C.M. Kornbluth's story The Marching Morons. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: A lurker surfaces
On Sun, 31 Dec 2006, John Cowan wrote: However, it's clear that UTC does not contain the sort of jumps that LCT does, where a single broken-down time may represent two different UTC seconds. Not if you include the timezone offset in the representation. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ THAMES DOVER WIGHT PORTLAND PLYMOUTH BISCAY: SOUTHWEST VEERING WEST 6 TO GALE 8, INCREASING 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. ROUGH OR VERY ROUGH BUT HIGH IN PLYMOUTH AND BISCAY. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.
Re: A lurker surfaces
Rob Seaman wrote: Just a reminder that UTC has no - none - nada - discontinuities. I concur, and so I prefer to say that UTC has _irregularities_. The rest of what Jim Palfreyman said applies to these irregularities: they must occur frequently so that the method of handling them is implemented and well tested. -zefram
Re: A lurker surfaces
In message: [EMAIL PROTECTED] John Cowan [EMAIL PROTECTED] writes: : Tony Finch scripsit: : On Sun, 31 Dec 2006, John Cowan wrote: : : However, it's clear that UTC does not contain the sort of jumps : that LCT does, where a single broken-down time may represent : two different UTC seconds. : : Not if you include the timezone offset in the representation. : : Quite so. Or alternatively a standard/daylight flag. The point is, : people usually don't. This is the leapsecond problem in a nutshell: While it is possible to keep enough information around in the representation of time, most people opt not to do so. It complicates the representation of time, and is one (or more) pieces of information that need to be carried around, mostly just to handle weird edge cases. Sure, you can do it, and some people try. However, there's no standardized way to do so, and people re-invent it wrong over and over again. Another poster I think was right: ntpd (and the underlying OS) hides a lot of these sins. Either by just twitterpating at the leapsecond in some way (time stands still, time jumps back a little, etc), or for a period of time around the leapsecond (by sticking its fingers in its ears, singing lalala and changing the size of a second to get through it a millisecond at a time). Warner
Re: A lurker surfaces
Poul-Henning Kamp wrote: Rob, If you feel uncomfortable with calling leapseconds discontinuities, then we can use the term arrhythmia instead. Which raises the question of why projects requiring an interval time scale lacking in such arrhythmias would have selected UTC in the first place. And why timekeepers who understand these issues would focus on remediating (i.e., eviscerating) UTC as the cure. Astronomers are among the power users for interval time as well as time-of-day. Helioseismologists (http://gong.nso.edu) needed an interval timescale that would be even tempered over years or even decades (a solar cycle is eleven years - the magnetic field flips at solar max, so a complete sample would require 22 years) - so they selected GPS, not UTC. But actually, I think we should call leap seconds what they are - intercalary events. My wife works at the Arizona-Sonora Desert Museum. We have family visiting and decided to spend the day at the museum - a good way to end a year. I especially recommend the raptor free flight program - the ferruginous hawk is especially impressive. My point is that a javelina is not a pig, a coatimundi is not a raccoon, and a ringtail cat is not a cat. A kangaroo rat is, of course, neither. And a leap second is a not a discontinuity. Imprecision in terminology leads to poor decision making. Rob
Re: A lurker surfaces
In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : Poul-Henning Kamp wrote: : : Rob, If you feel uncomfortable with calling leapseconds : discontinuities, then we can use the term arrhythmia instead. : : Which raises the question of why projects requiring an interval time : scale lacking in such arrhythmias would have selected UTC in the : first place. The real world often times requires both kinds of time keeping, with correlation back and forth between all the timescales. The customers want to deal with times in UTC. To get an effective, high precision time system, you need to count seconds in a sane way (UTC isn't a sane way for this purpose) so some conversion between this count and UTC is needed. The problem is that most interesting systems have a need to do things based on UTC time of day, as well as in a time scale that has none of the complications of the unpredictable UTC implementation we have today. So you can't just 'pick one' because real-world systems need to use different ones for different things, and they also need to translates events from one timescale to events in the other timescale. Let me give you a concrete example. Let us say we are measuring a number of atomic clocks against one another. We get the measurements and those measurements are in a monotonic timescale that is defined as PPS's from some epoch (or number of 5MHz or 10MHz ticks from some arbitrary epoch). We get data from GPS, which has a similar timescale. We compute the clock states and deside that we need to steer one of the clocks. These algoritmns are very much elapsed time sorts of deals. So we schedule a time to steer it, and then note the time when we are done steering it. Since we cannot easily get the GPS or timer times without interfereing with the operations of those subsystems (maybe because the steering system and GPS system are on dufferent cpus), we get the system time when the steer starts and when the clock tells us the steer is complete (since a steer isn't an instantaneous event). Since this system also is an ntpd server, that system time is in UTC. Now we have to convert UTC into the internal timescale so that the algorithms know when the steer happened and can take that into account for their next round of measurments and decision making. To make this all work out well, one has to have perfect leap second knowledge and all the special case code you have for dealing with the arrhythmia of a leap second has to work perfectly. Anything that can be dobe to make things more perdictable helps out quite a bit... Warner
