DateTime.Now vs DateTime.UtcNow

Tuesday, January 10, 2012 2:50 PM

Try to use .UtcNow() as much as you can over .Now() as it is inherently faster than the later. The problem seems to stem from the fact that DateTime.Now performs a DateTime.UtcNow first and then performs a very expensive called to figure out daylight savings time and time zone information.

public static DateTime Now
{
    get
    {
        DateTime utcNow = DateTime.UtcNow;
        bool isAmbiguousDst = false;
        long ticks = TimeZoneInfo.GetDateTimeNowUtcOffsetFromUtc(utcNow, 

out isAmbiguousDst).Ticks;
        long num = utcNow.Ticks + ticks;
        if (num > 3155378975999999999L)
        {
            return new DateTime(3155378975999999999L, DateTimeKind.Local);
        }
        if (num < 0L)
        {
            return new DateTime(0L, DateTimeKind.Local);
        }
        return new DateTime(num, DateTimeKind.Local, isAmbiguousDst);
    }
}

public static DateTime UtcNow
{
    [TargetedPatchingOptOut("Performance critical to 

inline across NGen image boundaries"), SecuritySafeCritical]
    get
    {
        long systemTimeAsFileTime = DateTime.GetSystemTimeAsFileTime();
        return new DateTime((ulong)(systemTimeAsFileTime + 

504911232000000000L | 4611686018427387904L));
    }
}

Thanks to Keyvan Nayyeri who did a detail analysis of DateTime.Now, DateTime.UtcNow and Stopwatch class at his blog post called The Darkness Behind DateTime.Now. Very good read for detail explanation.

Note that Environment.TickCount is also faster than DateTime.UtcNow.Ticks.