Re: remaining issues prior to 1.0?

[Justin Erenkrantz <ju...@erenkrantz.com>]

> Brian Pane wrote:
>
> Here's my attempt at summarizing all the proposals.
> There was a lot of debate about the naming of the time
> type--whether it was good or bad to give it a name so
> similar to time_t, whether the type name should reflect
> an implementation like binary microseconds, etc.  For
> simplicity, I'll just describe the implementations as
> I remember them, independent of the naming issues.

My take is that what we have now is fine for 1.0.  Perfect?  No.  So be
it.  It works.

Any changes to the time code can be in the next major release.  This will
give us enough time to appropriately discuss what should go in there.

IIRC, there was also an explicit veto on any change to the time code
because it could break source and/or binary compatibility.  Therefore, if
that veto still stands, we have to do any changes to the time code *after*
1.0 not before.  And, for lots of other reasons, I tend to agree to do it
after 1.0.

Count me as post-1.0 for any time fixes.  -- justin

Re: remaining issues prior to 1.0?

["William A. Rowe, Jr." <wr...@apache.org>]

At 07:28 PM 9/1/2003, Justin Erenkrantz wrote:
>> Brian Pane wrote:
>>
>> Here's my attempt at summarizing all the proposals.
>> There was a lot of debate about the naming of the time
>> type--whether it was good or bad to give it a name so
>> similar to time_t, whether the type name should reflect
>> an implementation like binary microseconds, etc.  For
>> simplicity, I'll just describe the implementations as
>> I remember them, independent of the naming issues.
>
>My take is that what we have now is fine for 1.0.  Perfect?  No.  So be
>it.  It works.

I agree here - I don't like the downsides of any of the alternatives (who does?)
but no longer prefer binary microseconds for the following reason...
...if you take a sample several times for delta time arithmetic you will get
rounding errors.  Are these more significant than samples taken and summed
using the obvious rounding errors of 10(-6) decimal math?  Probably not, but
users will be puzzled and frustrated by these sorts of discrepancies.

>Any changes to the time code can be in the next major release.  This will
>give us enough time to appropriately discuss what should go in there.

1.0 is the major release.

>IIRC, there was also an explicit veto on any change to the time code
>because it could break source and/or binary compatibility.  Therefore, if
>that veto still stands, we have to do any changes to the time code *after*
>1.0 not before.  And, for lots of other reasons, I tend to agree to do it
>after 1.0.

I believe the veto was over changing this in the .9 development branch...
although this might be a developer's version, it is widely deployed today
and needs to be treated as a 'stable' version.

So for 1.0 itself, anything goes if we can come to concensus.

>Count me as post-1.0 for any time fixes.  -- justin