> + others that I haven't checked. In any case, since we use the > + system's time_t time() function to get the time value everywhere > + except Win32 w/SYSTEMTIME, we only ever have a resolution of > + seconds or milliseconds. So, why the hell are we storing usecs? > + We don't use them. We don't even have display functions for them. > + We have to do a stupid conversion every time we actually do > something > + useful with time in order to support somebody's wet dream of a > + potentially useful feature? That's crap! This is exactly why > + I hate portability libraries that aren't based on the demonstrated > + needs of a specific application.]
Um, Roy? WTF are you talking about? >From apr/time/unix/time.c: APR_DECLARE(apr_time_t) apr_time_now(void) { struct timeval tv; gettimeofday(&tv, NULL); return tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec; } And as for "demonstrated needs," you're thinking too Apache-centric by a longshot. I very frequently use APR in my research work, which is graphics-rendering-related (thus, nothing to do with Apache at all). I *need* microsecond resolution in real time or as close to it as I can get. Even millisecond resolution usually isn't enough for my timing needs (think about it -- 60 frames per second means I need timing information at a very high resolution, since I get a grand total of a whopping 16ms for each frame, and I have to make decisions on how to spend that time). Resolution of time only in seconds would do me zero good. The fact that APR has provided me with a platform-neutral way to get high-resolution time has been a *huge* boon to my work. While I realize this is a limited example, the same applies to many other use cases I can think of. Stop hand-waving-saying-we're-hand-waving, please. IMO there's definitely a very valid case for having sub-second time resolution in this portability library, as getting high-resolution time across platforms is a *bear* to do yourself. --Cliff