DateTime.Now usage analyzer

[tugberkugurlu]

DateTime.Now is 99.9% of time is evil. Hmm, let's make it 100% 😄

The analyzer should analyze DateTime.Now usage and give warnings for usages. It should also suggest replace it with DateTime.UtcNow.

[sharwell]

It should first prefer to change it to DateTimeOffset.Now, but also offer the secondary option to change it to DateTime.UtcNow.

[sharwell]

Fields, parameters, and local variables of type DateTime could also be changed to DateTimeOffset to reduce the change of application errors.

[tugberkugurlu]

DateTimeOffset.Now case would be really hard to cover as you implied. You need to possibly scan all the solution to do the refactoring which would be hard I assume.

I think it is possible to suggest more than one code action for a diagnostic. So, the simpliest one would be to replace it with DateTime.UtcNow which would be trivial. Later, it can have the DateTimeOffset.Now refactoring.

[mattjohnsonpint]

I love the idea of this analyzer. I've been advocating against DateTime.Now for quite awhile. It should also find any usages of DateTimeKind.Local, including various methods on DateTime such as ToLocalTime, ToUniversalTime, and IsDaylightSavingTime.

In client-side code (desktop, phone, store apps, etc), DateTime.Now should usually be replaced with DateTimeOffset.Now, since the local time zone is still applicable. The benefit here is that the offset doesn't get lost when communicated to the server, and that offset changes (like those caused by daylight saving time) are still accounted for.

However, on the server, the local time zone is almost never appropriate. Server applications should either work strictly with UTC, or use TimeZoneInfo to work with specific time zones. DateTimeOffset.Now isn't a good idea for server applications.

I'm not sure exactly how suggested replacements should be implemented. It's great that something would warn you about the problems of using local time. However, when you get in to automatic refactoring, swapping in DateTime.UtcNow where there was previously DateTime.Now is not necessarily a complete solution. That would create invalid data unless the developer takes the extra step to understand how the data impacts their system and compensate accordingly.