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
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 confes
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
In message <[EMAIL PROTECTED]>, Ashley Yakeley
writes:
>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 s
In message: <[EMAIL PROTECTED]>
Ashley Yakeley <[EMAIL PROTECTED]> writes:
: 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
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 th
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
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 ho
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 re
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 th
Tony Finch wrote:
>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.
The Olsen software has a built-in assumption that the timezone dat
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
On Dec 27, 2006, at 01:23, Clive D.W. Feather wrote:
POSIX in the past deferred to WG14 (the ISO C committee) because
that's
where time_t came from.
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 a
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 have
In message <[EMAIL PROTECTED]>, "Clive D.W. Feather
" writes:
>M. Warner Losh said:
>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.
>
>An
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, w
16 matches
Mail list logo
