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