One of the things on my list at the moment is to implement a field for how many milliseconds have passed since something happened.  It sounds so simple, but from experience, dealing with time always makes me shudder.  Consider the properties of electronic time:
  1. Time is finite.  It doesn't matter what field size you choose, eventually, it will run out.  Sometimes you can wrap around to zero without pain; other times, that breaks things.
  2. Time is bidirectional.  Some of this comes from network time resynchronisation, and occasionally, hardware limitations.  Time can go backwards.  If you want to know how long it's been since an event, and poll twice in succession, the second can come before the first.  It also follows that time from any given event may be negative.
  3. Time is unstable.  If you're using the current clock at all in calculations, and it changes, it could change by years at a time.  To avoid this, you either can't use the current clock, or have to tolerate some really odd calculations.
  4. If an error occurs, time will remain in error forever.  Consider computers with flat CMOS batteries and odd times in the past.  Many time based calculations will follow the error paths, because the time being compared against won't happen for decades.  This can be anything from a file created in the future, an audit log entry for something that hasn't yet happened, unzipping files and creating files that won't be created into the future, an encyption certificate that won't be issued for years, or dependency-based build process.  It gets worse if any new data is created using that bogus date: consider how your audit log looks when it contains 2005 data followed by 1980 data followed by 2005 data again...
I'm sure time has other odd properties too.  When Einstein announced his belief that time was not absolute, the reaction was mixed; in electronic terms, time is not only not absolute, but tends towards being random.  Software can only compensate so much.