DateTime dt = DateTime.MinValue;            // {01.01.0001 00:00:00}
Console.WriteLine(dt == DateTime.MinValue); // True
dt = dt.ToLocalTime();                      // {01.01.0001 03:00:00} 
Console.WriteLine(dt == DateTime.MinValue); // False

A>DateTime dt = DateTime.MinValue;            // {01.01.0001 00:00:00}
A>Console.WriteLine(dt == DateTime.MinValue); // True
A>dt = dt.ToLocalTime();                      // {01.01.0001 03:00:00} 
A>Console.WriteLine(dt == DateTime.MinValue); // False
A>

A>dt = dt.ToLocalTime();                      // {01.01.0001 03:00:00}

A>dt = dt.AddHours(hours);

dt == DateTime.MinValue

WHERE [Created] BETWEEN ISNULL(@CreatedFrom, '1753-01-01 00:00:00')
                    AND ISNULL(@CreatedTo, '9999-12-31 23:59:59');

_FR>>"Косяком" является то, что вызов "dt.ToLocalTime();" вызвращает что-то не то, что было до этого? других косяков не заметил Или "косяк" — это появление в некоторых случаях "говнокода"? Тогда, косяк.

var xxx = yyy.AddMonth(2, CultureInfo.InvariantCulture.Calendar);
// или, как сейчас
var xxx = CultureInfo.InvariantCulture.Calendar.AddMonth(yyy, 2);

var xxx = yyy.AddMonth(2);

_FR>>Пожалуй, да. Они, кстати, где-то даже каялись за DateTime

Душа моя Павел,
Держись моих правил:
Люби то-то, то-то,
Не делай того-то.
Кажись, это ясно.
Прощай, мой прекрасный.

There was a lot of desire to keep the type system simple, and while a time zone aware DateTime was better at representing absolute points in time such as a file time-stamp, it got awkward when doing certain things:

— Interoperating with database, COM or legacy systems where the time zone could not be reliably inferred.

— Representing genuinely abstract dates and time, e.g. the opening times for stores of a company spanning time zones.

— Representing whole dates, e.g. the type for a calendar control to return. (Obviously a “Date” type is an even better way of representing this, and many people have asked for separate Date and Time types, but in V1.0 there was a desire to keep the number of base types small to limit complexity of the platform. This feature request is definitely still on the table, although not planned for .NET 3.5).

Prior to JDK 1.1, the class Date had two additional functions. It allowed the interpretation of dates as year, month, day, hour, minute, and second values. It also allowed the formatting and parsing of date strings. Unfortunately, the API for these functions was not amenable to internationalization. As of JDK 1.1, the Calendar class should be used to convert between dates and time fields and the DateFormat class should be used to format and parse date strings. The corresponding methods in Date are deprecated.

class UtcTime {
    long _ticks;

    static long Zero = new DateTime(2000, 1, 1, 0, 0, 0).Ticks; // we count it as UTC

    public implicit operator UtcTime(DateTime dt) {
        switch(dt.Kind) {
        case DateTimeKind.Utc: return UtcTime(dt.Ticks);
        case DateTimeKind.Local: return UtcTime(dt.ToUniversalTime(dt.Ticks));
        }
        throw InvaldArgumentException("Unspecified DateTime value");
    }    

    public implicit operator DateTime(UtcDateTime dt) {
         return new DateTime(Zero + _ticks, DateTimeKind.Utc);
    }    

    ... 
    // TODO: определить мемберы, аналогично мемберам DateTime
}

_FR>>WHERE [Created] BETWEEN ISNULL(@CreatedFrom, '1753-01-01 00:00:00')
_FR>>                    AND ISNULL(@CreatedTo, '9999-12-31 23:59:59');
_FR>>

_FR>> Но передавать надо, конечно же, null.

WHERE (@CreatedFrom IS NULL OR [Created] >= @CreatedFrom)
  AND (@CreatedTo IS NULL OR [Created] < @CreatedTo)