Codebetter.com has an interesting blog entry about avoiding DateTime.Now. It’s not completely clear from the article, but the problem it is referring to is that of building test cases for code that uses DateTime.Now. If you have code that directly uses “Now” is its calculations, it can be hard for the test code to anticipate the correct output of the these computations. This is mainly because you have to build all of your test cases off of the current time in which case the results of the test cases might not be reproducible — they might pass/fail differently depending on when they were run. Another problem is that the test code can’t know the exact time the tested code will use in it’s computations because it cannot get the exact same “Now” value as the tested code. This is less of a problem if the computations are only accurate to a second, minute, hour, etc.
The solution proposed by the post is to create interfaces for various date time functions, and then write implementation to the interfaces that map to the underlying DateTime.Now value. This way, when you are testing, you can always mock the wrapper classes and return a constant date/time to test various logical scenarios.