> It's definitely a failure in the development process, for the software that is supposed to work in some bigger time frame, and not only shortly. This is why

> It's definitely a failure in the development process, for the software that is supposed to work in some bigger time frame, and not only shortly. This is why I've recently started abstracting time/date calls in all my work so that I can test using arbitrary dates/times rather than using the various "now" library calls directly. This has already had the side-benefit of allowing me to deal with stuff like the time arbitrarily going backwards when NTP synchronises the clock. I don't typically rely on wallclock time for sequencing, this just keeps things a little more robust.