Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-Id: <5.2.0.9.2.20030902101741.04b6a8b8@pop3.rowe-clan.net>
Date: Tue, 02 Sep 2003 10:23:03 -0500
To: "Justin Erenkrantz" <justin@erenkrantz.com>
From: "William A. Rowe, Jr." <wrowe@apache.org>
Subject: Re: remaining issues prior to 1.0?
Cc: "Brian Pane" <brian.pane@cnet.com>,dev@apr.apache.org
In-Reply-To: <1124.68.5.222.127.1062462505.squirrel@scotch.ics.uci.edu>
References: <1062367074.15872.60.camel@desktop>
 <Pine.LNX.4.56.0306250127010.19211@deepthought.cs.virginia.edu>
 <3EF94AF8.9070900@apache.org>
 <3F043E39.4000907@apache.org>
 <1062367074.15872.60.camel@desktop>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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