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
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
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
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)
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
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
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
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
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
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
10 matches
Mail list logo
