Looks pretty good, and thanks!

src/base/time.hh (Diff revision 1)

Maybe define a constant for this? It's hard to count out that many zeros reliably.

src/base/time.cc (Diff revision 1)

Are you sure you want to use CLOCK_MONOTONIC here? My book says this is in reference to an "unspecified point in the past" and is for a clock source that can't jump around if, for instance, somebody updates the system time. There isn't necessarily anything wrong with that, but I don't think that's what gettimeofday does. If you want to really have a gettimeofday substitute, I think you want to use CLOCK_REALTIME, although that's mostly just a relatively uninformed interpretation of what's in the book and may be wrong.

src/base/time.hh (Diff revision 1)

heh, but the constant will have that many zeroes too!  I could use 1000*1000*1000 if you prefer.  I'll figure something out.

src/base/time.cc (Diff revision 1)

Oh, I used whatever you used.  CLOCK_REALTIME is fine too, though I guess I never really cared about the fact that I could print the time as a string.  I am generally more interested in using it for measuring how long things take.  I hesitate to make this code more complex, but I guess I could create a set_wallclock() func that does one and a set_timer() that does the other.

1. Gabe Black Jan. 13, 2011, 5:43 p.m. (Jan. 13, 2011, 5:43 p.m.)

   Yeah, CLOCK_MONOTONIC is probably better in a lot of ways since the simulation shouldn't generally care what the actual time is, and it avoids some issues. It would be nice to make gettimeofday more like clock_gettime with CLOCK_MONOTONIC than the other way around, if that's possible. You could have set() just do what it's doing now and a set_wallclock() (setWallclock() since it's a member of a class?) for the less commonly useful wall time.