Re: UT1 confidence
On Thu, 18 Jan 2007, M. Warner Losh wrote: > > : http://www.ucolick.org/~sla/leapsecs/torino/guinot.pdf > > I like figure 8, that shows that 20ms steps lead to 50ms steps lead to > 100ms steps lead to 1s steps. :-) In the late 1960s some stations broadcast "stepped atomic time" which had 200ms steps (and non-rubber seconds). Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FISHER: SOUTHWEST 6 TO GALE 8 OCCASIONALLY SEVERE GALE 9, PERHAPS STORM 10 LATER. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Re: The Martian Chronicles
On Mon, 15 Jan 2007, Rob Seaman wrote: > > I'm wondering whether the clock discipline might better emphasize > only frequency in such circumstances, as opposed to merely tempering > the PLL. I think that if you only correct the frequency of a clock then each time the frequency makes a deviation (e.g. because of temperature changes) you will accumulate a phase error, and if there's a bias in frequency deviations then the phase error will increase over time and become a long-term frequency error. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ ROCKALL MALIN HEBRIDES: WEST OR SOUTHWEST 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10, VEERING NORTHWEST 5 OR 6 LATER. HIGH, OCCASIONALLY VERY HIGH. RAIN THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: Introduction of long term scheduling
On Mon, 15 Jan 2007, Peter Bunclark wrote: > > > http://www.eecis.udel.edu/~mills/ipin.html > > That page does not seem to mention UTC... Look at the slides. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BISCAY FITZROY: VARIABLE 4, BECOMING SOUTHWESTERLY 5 TO 7 IN NORTHWEST FITZROY. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. SHOWERS. GOOD.
Re: Introduction of long term scheduling
On Mon, 8 Jan 2007, Steve Allen wrote: > > Don't forget that UTC and TAI are coordinate times which are difficult > to define off the surface of the earth. For chronometers outside of > geostationary orbit the nonlinear deviations between the rate of a local > oscillator and an earthbound clock climb into the realm of > perceptibility. There seems little point in claiming to use a uniform > time scale for a reference frame whose rate of proper time is notably > variable from your own. According to the slides linked from Dave Mills's "Timekeeping in the Interplanetary Internet" page, they are planning to sync Mars time to UTC. http://www.eecis.udel.edu/~mills/ipin.html Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ LUNDY FASTNET IRISH SEA: SOUTHWEST 6 TO GALE 8. ROUGH OR VERY ROUGH. RAIN OR DRIZZLE. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sat, 6 Jan 2007, M. Warner Losh wrote: > > Unfortunately, the kernel has to have a notion of time stepping around > a leap-second if it implements ntp. Surely ntpd could be altered to isolate the kernel from ntp's broken timescale (assuming the kernel has an atomic seconds count timescale) Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ NORTHWEST BISCAY: SOUTHWEST 5 TO 7, OCCASIONALLY GALE 8. VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Mon, 8 Jan 2007, Zefram wrote: > Possibly TT could also be used in some form, for interval calculations > in the pre-caesium age. In that case you'd need a model (probably involving rubber seconds) of the TT<->UT translation. It doesn't seem worth doing to me because of the small number of applications that care about that level of precision that far in the past. The main requirement for a proleptic timescale is that it is useful for most practical purposes. Therefore it should not be excessively complicated, such as requiring a substantially different implementation of time in the past to time in the present. What we actually did in the past was make a smooth(ish) transition from universal time to atomic time, so it would seem reasonable to implement (a simplified version of) that in our systems. In practice this means saying that we couldn't tell the difference between universal time and uniform time before a certain date, which we model as a leap second offset of zero. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BAILEY: SOUTHWEST 5 TO 7 BECOMING VARIABLE 4. ROUGH OR VERY ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sun, 7 Jan 2007, Daniel R. Tobias wrote: > > Formulas for UTC, as actually defined at the time, go back to 1961 > here: You helpfully snipped the part where I said that it probably isn't worth implementing rubber seconds. > ftp://maia.usno.navy.mil/ser7/tai-utc.dat > It appears the offset was 1.4228180 seconds at the start of this. If you extend the initial period backwards to the start of 1958 then the offset drops close to zero. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FITZROY: WEST BACKING SOUTHWEST 5 TO 7, OCCASIONALLY GALE 8. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. SHOWERS, THEN RAIN. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sun, 7 Jan 2007, M. Warner Losh wrote: > > Having tried it, there are a lot of little 33 second anomolies in many > applications :-(. How did you extend the UTC translation back past 1972 if the undelying clock followed TAI? I assume that beyond some point in the past you say that the clock times are a representation of UT. However TAI matched UT in 1958 and between then and 1972 you somehow have to deal with a 10s offset. It would be over-engineering to implement rubber seconds for the whole system when only very few applications need them. I suppose you could invent a leap second schedule for the 1960s, but perhaps it's more sensible to define the underlying timescale to be TAI+10 so that your system makes the universal->atomic time split at the point when UTC was established. > I've toyed with the idea of running the kernel in TAI and having 'smart' > processes tell libc they want no UTC translation and having all the > TAI<->UTC translation happen in libc (also hacking those FS that want > UTC time to be able to get it). It would seem sensible to me to fix time_t's lack of range at the same time as fixing its model of time. Perhaps the transition model to follow is the one used on non-BSD systems for large file support, which allows the developer to either set a compile time flag to get the new behaviour, or use a wide form of the API, e.g. stat64() instead of stat(). Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ ROCKALL: SOUTHWEST 6 BECOMING CYCLONIC 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER. VERY ROUGH BECOMING HIGH. SHOWERS, RAIN LATER. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sun, 7 Jan 2007, M. Warner Losh wrote: > > [POSIX time] is designed to be UTC, but fails to properly implement > UTC's leap seconds and intervals around leapseconds. >From the historical point of view I'd say that UNIX time was originally designed to be some vague form of UT, and the POSIX committee retro-fitted a weak form of UTC synchronization. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ DOGGER FISHER GERMAN BIGHT HUMBER: SOUTHWEST, VEERING NORTHWEST FOR A TIME, 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 IN DOGGER. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sun, 7 Jan 2007, Rob Seaman wrote: > > It's not the correct time under the current standard if the > timekeeping model doesn't implement leap seconds correctly. I don't > think this is an impossible expectation, see http:// > www.eecis.udel.edu/~mills/exec.html, starting with the Levine and > Mills PTTI paper. As http://www.eecis.udel.edu/~mills/leap.html shows, NTP (with kernel support) is designed to stop the clock over the leap second, which I don't call "correct". Without kernel support it behaves like a "pinball machine" (according to Mills). Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SOUTHEAST ICELAND: CYCLONIC 6 TO GALE 8, BECOMING VARIABLE 4 FOR A TIME. ROUGH OR VERY ROUGH. OCCASIONAL RAIN OR WINTRY SHOWERS. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sat, 6 Jan 2007, M. Warner Losh wrote: > > Most filesystems store time as UTC anyway... POSIX time is not UTC :-) Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SOUTHEAST ICELAND: CYCLONIC 6 TO GALE 8, DECREASING 5 OR 6 LATER. ROUGH OR VERY ROUGH. OCCASIONAL RAIN OR WINTRY SHOWERS. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sat, 6 Jan 2007, Ashley Yakeley wrote: > > Presumably it only needs to know the next leap-second to do this, not > the whole known table? Kernels sometimes need to deal with historical timestamps (principally from the filesystem) so it'll need a full table to be able to convert between POSIX time and atomic time for compatibility purposes. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SHANNON ROCKALL MALIN: MAINLY WEST OR SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sat, 6 Jan 2007, Steve Allen wrote: > > No two clocks can ever stay in agreement. I don't think that statement is useful. Most people have a concept of accuracy within certain tolerances, dependent on the quality of the clock and its discipline mechanisms. For most purposes a computer's clock can be kept correct with more than enough accuracy, and certainly enough accuracy that leap seconds are noticeable. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ HEBRIDES BAILEY FAIR ISLE FAEROES: SOUTHWEST 6 TO GALE 8. VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Sat, 6 Jan 2007, M. Warner Losh wrote: > > OSes usually deal with timestamps all the time for various things. To > find out how much CPU to bill a process, to more mondane things. > Having to do all these gymnastics is going to hurt performance. That's why leap second handling should be done in userland as part of the conversion from clock (scalar) time to civil (broken-down) time. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SOUTHEAST ICELAND: SOUTHWEST BECOMING CYCLONIC 5 TO 7, PERHAPS GALE 8 LATER. ROUGH TO HIGH. SQUALLY SHOWERS. MAINLY GOOD.
Re: Introduction of long term scheduling
On Thu, 4 Jan 2007, Michael Deckers wrote: > >This leads me to my question: would it be helpful for POSIX implementors >if each and every UTC timestamp came with the corresponding value of DTAI >attached (instead of DUT1)? Would this even obviate the need for a leap >seconds table? No, because you need to be able to manipulate representations of times other than the present, so you need a full leap second table. You might as well distribute it with the time zone database because both are used by the same component of the system and the leap second table changes more slowly than the time zone database. You don't need to transmit TAI-UTC with every timestamp: for example, NTP and GPS transmit UTC offset tables and updates comparatively infrequently. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ WIGHT PORTLAND PLYMOUTH: WEST 4 OR 5, BECOMING CYCLONIC 5 TO 7 FOR A TIME, THEN NORTHWEST 5 OR 6 LATER. MODERATE OCCASIONALLY ROUGH IN PORTLAND AND PLYMOUTH. OCCASIONAL RAIN OR DRIZZLE. GOOD OCCASIONALLY MODERATE OR POOR.
Re: how to reset a clock
On Thu, 4 Jan 2007, Zefram wrote: > > Interval clock and real-time clock remain conceptually distinct. If you > have a single clock counter alongside a variable epoch, the sum of the > two is the effective real-time clock. I don't think you're gaining > anything by not reifying it. I'm gaining simplicity. A count of seconds (perhaps fractional) is much simpler than a broken-down time. It's much simpler to keep a simple interval representation separate from leap second and time zone handling. Your points about recording adjustments across reboots are useful, thanks. > The solution is to just let the clock run, never adjust it, and treat > it as an independent seconds count. You don't care about it showing > the wrong time, because you don't treat its output as an absolute time. > Instead, collect your data on how far out it is (or rather, what absolute > time -> output function it is computing) and add the epoch in software. > Any number of users of the same clock can do this without treading on > each other's toes. I think that's what I was suggesting :-) Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ THAMES DOVER WIGHT PORTLAND PLYMOUTH: WEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 AT FIRST IN THAMES AND DOVER, DECREASING 4 OR 5 LATER. ROUGH, OCCASIONALLY MODERATE LATER. SHOWERS DYING OUT. GOOD.
how to reset a clock
The time APIs that I am familiar with represent time as an interval based on a fixed implicit epoch. To reset a clock that is wrong, its couner value must be set to the correct value. This implies that the system's real time clock and interval timer must be separate, so that processes depending on correct relative time continue to work across RTC resets. Are there any APIs which have an explicit variable epoch, and which reset the clock by adjusting its epoch instead of its counter? This would eliminate the need for seperate interval and real-time clocks. (This post only considers abnormal resets of a grossly incorrect clock, and ignores corrections based on adjusting the clock's frequency.) Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ WIGHT PORTLAND PLYMOUTH: SOUTHWEST VEERING WEST OR NORTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9, LATER DECREASING 5 OR 6. ROUGH OR VERY ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.
Re: Introduction of long term scheduling
On Wed, 3 Jan 2007, Magnus Danielson wrote: > > Assuming you have corrected for another gravitational field, yes. The > current SI second indirectly assumes a certain gravitational force, we > is assumed to be "at sea level" whatever level that is. Wrong. The SI second is independent of your reference frame, and is defined according to Einstein's principle of equivalence. What *does* depend on the gravitational potential at the geoid is TAI (and TT), since a timescale (unlike a fundamental unit) is relative to a reference frame. > We still depend on geophysics to some degree. Note that the standard relativistic transformations between TT, TCG, and TCB is (since 2000) independent of the geoid. So although the realization of these timescales is dependent on geophysics (because the atomic clocks they are ultimately based on are sited on the planet) the mathematical models try to avoid it. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SOLE LUNDY FASTNET IRISH SEA: SOUTHWEST VEERING WEST OR NORTHWEST 7 TO SEVERE GALE 9, LATER DECREASING 4 OR 5. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH IN WEST SOLE. RAIN THEN SCATTERED SHOWERS. MODERATE OR GOOD.
Re: A lurker surfaces
On Sun, 31 Dec 2006, Rob Seaman wrote: > > But actually, I think we should call leap seconds what they are - > intercalary events. Yes! I also liked Zefram's comment "As a calendar, UTC is presently of the observational variety." http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg01367.html Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BISCAY FITZROY: SOUTHWEST VEERING WEST 6 TO GALE 8, DECREASING 4 OR 5. ROUGH OR VERY ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.
Re: A lurker surfaces
On Tue, 2 Jan 2007, Steve Allen wrote: > > And, yes, explaining all this is very hard. It's not obvious to the > geek that the political and funding realities are more real than the > underlying physics, but that's the way the world works. I've been reading "The Measurement of Time" by Audoin and Guinot, and one of the things its history of time keeping makes clear is that a lot of the improvements have been driven by cross-comparison of different measures of time. At the moment UTC requires the keepers of atomic time and astronomical time to work together, guaranteeing continued funding and employment for both :-) If we were to move to a purely atomic foundation for civil time, I wonder what effect that will have on the organizational arrangements. Will there continue to be enough cross-checks to drive the keepers of time to further improvements? Will geodesy be enough to preserve the astronomers' jobs? I usually take a technical view of things so this slightly meta way of thinking is unfamiliar to me... (Audoin and Guinot seem to favour purely atomic time.) Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FAIR ISLE FAEROES: SOUTHWESTERLY BECOMING CYCLONIC THEN NORTHWESTERLY 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. VERY ROUGH OCCASIONALLY HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OCCASIONALLY POOR.
Re: Introduction of long term scheduling
On Tue, 2 Jan 2007, Warner Losh wrote: > > Curiously, BIH is currently, at least in the document I have, expected > to predict what the value of DUT1 is to .1 second at least a month in > advance so that frequency standard broadcasts can prepare for changes > of this value a month in advance. There's an exception for IERS to > step in two weeks in advance if the earth's rotation rate hickups. I was amused by the dates in http://hpiers.obspm.fr/eoppc/bul/buld/bulletind.94 Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BAILEY: SOUTHERLY VEERING WESTERLY 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER. VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Re: A lurker surfaces
On Tue, 2 Jan 2007, Zefram wrote: > > Same for years too: the Roman calendar was naturally arranged so > that the annual period of growing and harvesting things was entirely > encompassed by the calendar year. Imagine how annoying it would be if the > summer overlapped the legal year end. Oh, wait: southern hemisphere. > Somehow they cope without a season zone offset six months from the > northern hemisphere. cf. academic and tax years. I note that typical time libraries don't support the 2006/7 notation, so a similar notation for days would be likely to cause problems given their more widespread use. > I have an idea what might precipitate the switch to UT, too. [...] > I think Pacific airlines will be the first to give up on timezones, > and adopt UTC, so that the schedules are less confusing. Good call. I have found that keeping my watch on GMT worked quite well when I was in San Francisco and regularly communicating with people in the UK, but when I moved back to Cambridge a GMT watch during BST was similar yet wrong enough to be too confusing. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ MALIN HEBRIDES: SOUTHWEST 4 OR 5, BACKING SOUTH 7 OR GALE 8, PERHAPS SEVERE GALE 9 LATER. MODERATE, BECOMING ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.
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: Mechanism to provide tai-utc.dat locally
On Fri, 29 Dec 2006, Rob Seaman wrote: > > Folks keep fretting here about retrieving lists of leap seconds > autonomously, although no specific use case is proffered about why > one needs to use UTC to measure intervals across various and sundry > leap second events. You need to do so in order to implement an accurate clock, since the clock produces interval time and you need a way to convert its output to time of day. > M. Warner Losh wrote: > > > > Daylight savings time and time zones prove that society at large has a > > very high tolerance for variations between the mean solar time at an > > arbitrary location, maybe hundreds of miles away, and the local time. > > This is a static offset. No, it is subject to arbitrary political variations. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SHANNON: SOUTHERLY BECOMING CYCLONIC GALE 8 TO STORM 10, OCCASIONALLY VIOLENT STORM 11. HIGH. RAIN OR SQUALLY SHOWERS. MODERATE, OCCASIONALLY POOR.
Re: Mechanism to provide tai-utc.dat locally
On Thu, 28 Dec 2006, M. Warner Losh wrote: > > We've accepted a statistical solution for the leap-day problem now for > about 500 years. The Julian calendar reform was in 46 BC. Astronomers still count Julian years (365.25 days instead of exact years) when dealing with long MJD intervals. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: SOUTHERLY 7 OR GALE 8, OCCASIONALLY SEVERE GALE 9. ROUGH OR VERY ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE, OCCASIONALLY POOR.
Re: Mechanism to provide tai-utc.dat locally
On Thu, 28 Dec 2006, John Cowan wrote: > > Distinguo. I am talking about time intervals; you are talking about > periodic events. Two different things. Still, your minute/month system does not deal with variable-length days. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SHANNON: SOUTH BECOMING CYCLONIC 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10, PERHAPS VIOLENT STORM 11 LATER. VERY ROUGH OCCASIONALLY HIGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
On Wed, 27 Dec 2006, John Cowan wrote: > > If we confine ourselves to the Gregorian calendar, a time interval can > be safely represented as a triple of months, minutes, and seconds. It seems to me that that would put too much complexity at too low a level but still without enough complexity to deal with the whole problem. How does your proposal deal with local time zone changes, e.g. "same time tomorrow", or times based on weeks, e.g. "last thursday in the month"? I don't see much point in having an intermediate stage between day counts and fully broken down dates. Similarly for times, I favour a split between interval time (which the RTC would produce) and broken-down time of day plus day count (with leap seconds and local time handled in the latter layer). Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FISHER GERMAN BIGHT HUMBER: NORTHWEST BACKING SOUTH 4 OR 5, INCREASING 6 OR 7. SLIGHT OR MODERATE, OCCASIONALLY ROUGH LATER. OCCASIONAL RAIN. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
On Wed, 27 Dec 2006, Zefram wrote: > > Your principle is probably correct; I'm just saying that the > implementation you're thinking of doesn't actually satisfy the criterion. When you quoted me you snipped the bit where I said "its implementation is far from ideal". This is not just because of the update problem: the whole library is built around time_t and the traditional time API both of which are hopeless. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ NORTH UTSIRE SOUTH UTSIRE: WEST OR NORTHWEST 3 OR 4, OCCASIONALLY 5. SLIGHT. FAIR. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
On Wed, 27 Dec 2006, Zefram wrote: > > So I'm not convinced that leap second uncertainty and timezone > uncertainty should be treated the same way. I was thinking partly from the point of view of infrastructure: if you have a mechanism that can keep the system's timezone database up-to-date, then it is adequate for keeping the leap second table up-to-date. This is an approach to answering Ashley's initial question, and the one taken by Linux's use of the Olson database (though its implementation is far from ideal). > The nature of the uncertainty is very different. The uncertainty of > future UTC can be managed, but for timezones the only sane path is to > eschew their use entirely. That isn't possible for applications like appointment books and job schedulers. As Warner suggests, you need to calculate future times provisionally, and in a way that insulates you from discontinuities. For example, "same time tomorrow" instead of "in 86400 seconds". Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FAIR ISLE FAEROES SOUTHEAST ICELAND: SOUTH OR SOUTHWEST 4 OR 5, DECREASING 3 IN FAIR ISLE. MODERATE. FAIR. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
On Mon, 25 Dec 2006, Keith Winstein wrote: > > Even if a program is able to calculate TAI-UTC for arbitrary points in the > past and near future, what should a library do when a program asks to > convert between UTC and TAI for some instant further than six months in > the future? You should treat this kind of conversion in the same way that you treat local time zone conversions, which are also unpredictable. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SOLE: SOUTHEASTERLY 5 TO 7, OCCASIONALLY GALE 8, VEERING SOUTHWESTERLY 3 OR 4. MODERATE OR ROUGH. RAIN. MODERATE OR GOOD.
