> 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 [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
