> Evidently Justin has found the second use case. And if you are trying
> to preserve time when udate'ing() on a file, you better know the original
> time if you want to roundtrip.
But that is a *BSD thing only, and they provide the POSIX values already.
> >Four macros, by four different scales, equals 16 macros. And, at the
> >end of the day, the values stored are useful once you leave APR.
>
> s/the values/none of the values/ ... I presume.
yes.
> >BTW, the apr_time_xmake(sec, xsec) macro is completely wrong IMHO. In
> >order to use it, I need to provide multiple values, but that doesn't
> >make any sense, because we have four time scales. Either provide a
> >single value, or four. Two just doesn't make sense.
>
> You are being somewhat goofy or clueless. I have two numbers. Perhaps they
> are seconds and microseconds, perhaps seconds and milliseconds. Both are
> very common. In either case, you want an APR time. Plug them both in
> (from a tm struct, or whatever) and you get a result.
yes, but what happens when I have three numbers? Or when my two numbers
are milliseconds and microseconds? Why have three macros when one can do
it?
> > > I have no problem fixing the ambiguity between _xsec_get and _to_xsec,
> > > since the difference is subtle. Perhaps apr_time_frac_to_xsec(time)
> > > instead of _xsec_get? (saying, only the fractional portion of a
> >second?)
> >
> >Perhaps an example of the difference, because I don't see it.
>
> Skipping the algebraic differences? Simply you have two things;
>
> Give me a timeout in milliseconds == apr_time_as_msec(apr_time_value)
>
> Fill me a tm structure;
> tm.sec == apr_time_sec_get(apr_time_value)
> tm.usec == apr_time_usec_get(apr_time_value)
>
> There is a big difference here, the first apr_time_as_msec gave you the
> WHOLE time, integers and fraction of a second. The second case, _get,
> got you only the intregal seconds and the intregal usec fraction of a second.
>
> If you want _frac_ in the macro, that's fine.
Got it thanks for the explanation.
> Sorry you find them obtuse. Perhaps Aaron's pointer to the "Veto early,
> veto often, prevent people from wasting their efforts" shouldn't be changed
> at all.
>
> I'd suggest you snooze, you lose, but of course this is only two weeks old,
> not two years old.
I am going to ignore this flame bait.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
|