> 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
