I agree that Nullable<DateTime> is a better choice in the absence of other considerations.
You do however need to consider other systems with which you need to interoperate.
For example:
if you are exposing your .NET DateTime to COM clients, you won't be able to use Nullable<DateTime>.
if you are storing the value in a SQL Server database, remember that SQL Server can't store DateTime.MinValue as a DateTime.
Another point to consider is that Nullable can add some complexity for callers of an API: they may need to consider how the null case should be handled. In some cases it may be simpler to use a default value for the null case. For example, consider a class that exposes a property "ExpiryDate", where a value is needed to indicate that the item never expires.
One approach is to use a Nullable<DateTime>
with null representing "never expires". An alternative approach is to use a standard DateTime with DateTime.MaxValue
representing "never expires".
In this example, the test for "is expired" is simpler for the standard DateTime:
if (item.ExpiryDate <= DateTime.Today) ...
than for the Nullable<DateTime>
:
if (item.ExpiryDate.HasValue && item.ExpiryDate <= DateTime.Today) ...