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 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