Re: Mechanism to provide tai-utc.dat locally

2006-12-29 Thread Tony Finch
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

Re: Mechanism to provide tai-utc.dat locally

2006-12-29 Thread Steve Allen
On Fri 2006-12-29T07:43:56 +, Tony Finch hath writ: Astronomers still count Julian years (365.25 days instead of exact years) when dealing with long MJD intervals. Such intervals are almost always expressed in the IAU's time scale of Terrestrial Time (TT) which is taken to be a more

Re: Mechanism to provide tai-utc.dat locally

2006-12-29 Thread Steve Allen
On Thu 2006-12-28T18:31:43 -0700, M. Warner Losh hath writ: Let's turn the question around. What would the harm be if |DUT1| were 1.1s? 1.5s? 2.0s? Contrast this with the harm and difficulty that the current 6 month scheduling window affords. I have previously indicated that I believe this

Re: Mechanism to provide tai-utc.dat locally

2006-12-29 Thread Rob Seaman
Tony Finch wrote: 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. As Steve Allen has pointed out, it is in the nature of a clock to be reset on occasion. What is NTP but a mechanism for

Re: Mechanism to provide tai-utc.dat locally

2006-12-29 Thread John Cowan
Rob Seaman scripsit: Seems like? Chances are? Pick some other random technical issue - say, automobile airbags, standardized educational testing, the lead content of pigment in children's crayons, and so forth and so on. Would seems like and chances are be phrases you would want to see in

Re: Mechanism to provide tai-utc.dat locally

2006-12-29 Thread Michael Deckers
On 2006-12-09, Clive D.W. Feather challenged, and I couldn't resist: For something more challenging, try the 8 Bank Holidays in England: ... (8) Second weekday after 24th December. second weekday after 24th December in Gregorian year( Y ) = Gregorian calendar( Y, December, 26

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Rob Seaman
Poul-Henning Kamp wrote: I seriously don't belive you do equality comparisons at the 1msec level in real world software. Please provide examples. You know you're in trouble when PHK and I agree. One would think a (double precision) floating point epsilon test might be what you want. In

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Tony Finch
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

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Tony Finch
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

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread John Cowan
Tony Finch scripsit: Still, your minute/month system does not deal with variable-length days. I assume you mean 23-hour or 25-hour LCT days? True. It does work against UCT days, though, since they are uniformly 1440 minutes long. -- Overhead, without any fuss, the stars were going out.

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Rob Seaman
John Cowan wrote: I assume you mean 23-hour or 25-hour LCT days? True. It does work against UCT days, though, since they are uniformly 1440 minutes long. Not should leap hours replace leap seconds.

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Rob Seaman
I am talking about time intervals; you are talking about periodic events. Two different things. Amen!

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Steve Allen
On Thu 2006-12-28T17:35:00 +, Tony Finch hath writ: 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? Problems with the Gregorian

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Rob Seaman
M. Warner Losh wrote: And avoiding the ugly 61 or 59 second minutes to define away the problem... It was the time lords who decreed that rubber minutes were prettier than rubber seconds. We're now to skip right over rubber hours to rubber days? Their aesthetic sense seems strangely

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: M. Warner Losh wrote: And avoiding the ugly 61 or 59 second minutes to define away the problem... It was the time lords who decreed that rubber minutes were prettier than rubber seconds. We're now to skip right over rubber hours to rubber days?

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : We can get that only by increasing the DUT tolerance. Yes. Letting DUT be bounded by +- 10s rather than +- 0.9s is going to affect a tiny number of users. Having leapseconds only known 6 months in advance

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Rob Seaman
Poul-Henning Kamp wrote: It is not an ├Žsthetic issue, it is an issue of practical implementation. Well, it's both. The big question is practical implementation of what? In these days of heavily computerized infrastructure, we need more than half a years warning about discontinuities in the

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread John Cowan
Rob Seaman scripsit: I don't care if you want to implement leap-milliseconds, as long as you tell me 10 years in advance when they happen. Again - with no intent to minimize the issues - what supports this assertion? Is there any reason to believe that 10 years advance notice would

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread M. Warner Losh
In message: [EMAIL PROTECTED] John Cowan [EMAIL PROTECTED] writes: : Rob Seaman scripsit: : : I don't care if you want to implement leap-milliseconds, as long : as you tell me 10 years in advance when they happen. : : Again - with no intent to minimize the issues - what supports

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Rob Seaman
M. Warner Losh wrote: Let's turn the question around. What would the harm be if |DUT1| were 1.1s? 1.5s? 2.0s? Contrast this with the harm and difficulty that the current 6 month scheduling window affords. Indeed. Go for it. I look forward to reading your report. Who and what interests

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread John Cowan
Rob Seaman scripsit: Indeed. Go for it. I look forward to reading your report. Who and what interests are adversely affected in each case? How are these effects mitigated as a function of the limit on DUT1? Also, contrast what benefits accrue. One would think that the responsibility for

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Rob Seaman
John Cowan wrote: It can't possibly be. Nobody can know what a change is going to cost except those who are going to have to pay for it (or not pay for it). Are you really suggesting that the planning of technical projects is impossible? One might expect some investment of time and money in

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : Let's turn the question around. What would the harm be if |DUT1| were : 1.1s? 1.5s? 2.0s? Contrast this with the harm and difficulty that : the current 6 month scheduling window

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Rob Seaman
M. Warner Losh wrote: vague rumblings about astronomical software needing to be rewritten, Unlike Y2K, there is no solid public proposal for astronomers to cost against, but the cost is likely to dwarf Y2K in our community, since algorithms and deployed services would have to change, not just

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Steve Allen
On Thu 2006-12-28T22:07:08 -0700, M. Warner Losh hath writ: I know the benefits, but nobody has yet produced a study on why 0.9s was chosen. That's pretty easy. In 1969 the CCIR subcommittee was preparing its unilateral decision to switch from rubber seconds and 200 ms steps to leap seconds.

Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Tony Finch
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. --

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Clive D.W. Feather
M. Warner Losh said: time_t is so totally broken, it isn't funny. That's the closest thing to a standardized API there is for time. All others are stuff folks have done here or there, but they aren't universal enough to be considered. Too bad the problems with time_t are well known, well

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley
On Dec 26, 2006, at 23:02, M. Warner Losh wrote: Of course, needing to know TAI-UTC offsets leads one to interesting situations. What does one do if one has TAI time, but not UTC and a conversion is asked for? If it's a time in the future rather than just the current time, the thread may

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Zefram
Ashley Yakeley wrote: On Dec 27, 2006, at 01:23, Clive D.W. Feather wrote: Any proposal has got to deal with a whole load of issues, many of which haven't been properly documented. For example, it should be possible to add and subtract times and intervals (e.g. what time is 14 months and 87 days

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Tony Finch
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

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Zefram writes: Ashley Yakeley wrote: In the Haskell time library, I represent UTC time by what seemed to me the simplest possible correct type. This is a record containing an integer to represent day number (as MJD), and a fixed-point decimal (picosecond resolution)

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Rob Seaman
Clive D.W. Feather writes: WG14 is willing in principle to make changes to time_t, up to and including completely replacing it by something else. *BUT* it needs a complete and consistent proposal and, preferably, experience with it. This is at the heart of my distaste for the so-called leap

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread John Cowan
Zefram scripsit: In the general case: to determine or use an interval of N calendar FOOs, it is convenient to represent the time as a linear count of calendar FOOs plus details of the exact position within the current FOO. FOO may be minute, hour, day, week, month, or year. I think there

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley
On Dec 27, 2006, at 06:29, Poul-Henning Kamp wrote: That's a pretty bad format. Computers are binary and having pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec and picoseconds in Haskell is both inefficient and stupid. The fractional part should be a binary field, so that

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley
On Dec 27, 2006, at 14:32, Poul-Henning Kamp wrote: It's impossible to accurately represent a millisecond using binary fractions. That would be unacceptable for most sub-second use. Reality check: with a 32bit fraction, the error would be 69 ps. ...which accumulates in arithmetic and causes

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread John Cowan
Rob Seaman scripsit: Mucking with leap seconds is equivalent to redefining the concept of a day. Very true. And adopting the Egyptian-Roman calendar redefined the concept of a month. Somehow civilization survived. -- John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan I must confess

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Daniel R. Tobias
On 27 Dec 2006 at 20:57, John Cowan wrote: Very true. And adopting the Egyptian-Roman calendar redefined the concept of a month. Somehow civilization survived. Keeping months in sync with phases of the moon apparently turned out to be insufficiently important to civilization to require it as

Re: Mechanism to provide tai-utc.dat locally

2006-12-26 Thread Zefram
M. Warner Losh wrote: Actually, the real answer is domain specific. There are many things that don't really care (when do I need to make the next 20 house payments, off by one second just doesn't matter at all since transcations are batched on a daily basis a few days early). In that case you

Re: Mechanism to provide tai-utc.dat locally

2006-12-26 Thread Tony Finch
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

Re: Mechanism to provide tai-utc.dat locally

2006-12-26 Thread Steve Allen
On Tue 2006-12-26T17:10:34 +, Tony Finch hath writ: You should treat this kind of conversion in the same way that you treat local time zone conversions, which are also unpredictable. This past year was fun in the state of Indiana as daylight time happened for the first time ever in many

Re: Mechanism to provide tai-utc.dat locally

2006-12-26 Thread Zefram
Tony Finch wrote: You should treat this kind of conversion in the same way that you treat local time zone conversions, which are also unpredictable. I wish timezone data would come with a guaranteed validity period, so that the library could say I don't know in the right places. Unfortunately

Re: Mechanism to provide tai-utc.dat locally

2006-12-26 Thread Tony Finch
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

Re: Mechanism to provide tai-utc.dat locally

2006-12-25 Thread Ed Davies
Ashley Yakeley wrote: ... This has led me to consider run-time methods of obtaining leap-second information, and how that might be standardised for use by software authors. For instance, I imagine a software package that established a well-known place in the directory hierarchy to find

Re: Mechanism to provide tai-utc.dat locally

2006-12-25 Thread Rob Seaman
Good discussion. On Mon 2006-12-25T15:42:12 -0500, Keith Winstein hath writ: 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

Re: Mechanism to provide tai-utc.dat locally

2006-12-25 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Zefram [EMAIL PROTECTED] writes: : Keith Winstein wrote: : 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? : : Refuse, of course. The correct

Re: Mechanism to provide tai-utc.dat locally

2006-12-25 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Zefram [EMAIL PROTECTED] writes: : Steve Allen wrote: : and if I continue that practice : I can later give you an estimate of how wrong I was when I told you. : : This is something that's missing from current

Re: Mechanism to provide tai-utc.dat locally

2006-12-25 Thread Ashley Yakeley
On Dec 25, 2006, at 04:46, Zefram wrote: The table at ftp://time.nist.gov/pub/leap-seconds.list has an explicit expiry date. (I'm going to make Time::UTC use this at some point.) I agree this is better because of the expiry date. This is a bit faster:

Mechanism to provide tai-utc.dat locally

2006-12-24 Thread Ashley Yakeley
Hello, I just joined the leap seconds list. I wrote the time package for the Haskell programming language. http://semantic.org/TimeLib/ I include code for making conversions between TAI and UTC, given a leap-second table. I also include code for parsing a tai-utc.dat file into a leap-second

Re: Mechanism to provide tai-utc.dat locally

2006-12-24 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Ashley Yakeley [EMAIL PROTECTED] writes: : Hello, I just joined the leap seconds list. I wrote the time : package for the Haskell programming language. : http://semantic.org/TimeLib/ : : I include code for making conversions between TAI and UTC, given a :