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
