DateTime.Now returns the current date and time in the machine's local time zone. DateTime.UtcNow returns the current date and time in Coordinated Universal Time (UTC). For server-side code, logging, and anything that crosses time zone boundaries, use DateTime.UtcNow. Use DateTime.Now only when you specifically need to display the local time to a user on that machine.

The Fundamental Difference

Both properties return a DateTime struct, but they represent different moments when interpreted:

1DateTime local = DateTime.Now;
2DateTime utc = DateTime.UtcNow;
3
4Console.WriteLine($"Local: {local}");       // e.g., 2026-06-18 14:30:00
5Console.WriteLine($"UTC:   {utc}");         // e.g., 2026-06-18 18:30:00
6Console.WriteLine($"Kind:  {local.Kind}");  // Local
7Console.WriteLine($"Kind:  {utc.Kind}");    // Utc

DateTime.Now applies the system's local time zone offset and daylight saving rules. DateTime.UtcNow does not. The Kind property on each result reflects this: DateTimeKind.Local vs. DateTimeKind.Utc.

Why DateTime.UtcNow Is the Default Choice

Local time is ambiguous. During a daylight saving "fall back," the same local time occurs twice. During a "spring forward," an hour of local time does not exist at all. Storing or comparing local times without their time zone offset leads to bugs that only manifest twice a year and are difficult to reproduce.

1// Scenario: server in New York, user in London
2// If you store DateTime.Now, the timestamp is EDT (UTC-4)
3// But nothing in the DateTime struct records that offset
4// Anyone reading the value later has no way to know it was EDT
5
6DateTime ambiguous = DateTime.Now;
7Console.WriteLine(ambiguous.Kind);  // Local -- but local to WHICH machine?

UTC is unambiguous. It never changes for daylight saving. It is the same everywhere. Store UTC, convert to local only at display time.

Performance Difference

DateTime.UtcNow is slightly faster than DateTime.Now because .Now must query the system's time zone rules and apply an offset. In practice the difference is microseconds, but in tight loops (logging millions of events), it is measurable.

1// Benchmark-style comparison
2var sw = System.Diagnostics.Stopwatch.StartNew();
3for (int i = 0; i < 10_000_000; i++)
4{
5    _ = DateTime.UtcNow;
6}
7sw.Stop();
8Console.WriteLine($"UtcNow: {sw.ElapsedMilliseconds}ms");
9
10sw.Restart();
11for (int i = 0; i < 10_000_000; i++)
12{
13    _ = DateTime.Now;
14}
15sw.Stop();
16Console.WriteLine($"Now: {sw.ElapsedMilliseconds}ms");
17// UtcNow is consistently faster

Comparison Table

Converting Between Local and UTC

1// UTC to local
2DateTime utcTime = DateTime.UtcNow;
3DateTime localTime = utcTime.ToLocalTime();
4
5// Local to UTC
6DateTime now = DateTime.Now;
7DateTime utcFromLocal = now.ToUniversalTime();
8
9// Convert to a specific time zone
10DateTime utcNow = DateTime.UtcNow;
11TimeZoneInfo eastern = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
12DateTime easternTime = TimeZoneInfo.ConvertTimeFromUtc(utcNow, eastern);
13Console.WriteLine($"Eastern: {easternTime}");
14
15// On Linux/macOS, use IANA time zone IDs
16// TimeZoneInfo.FindSystemTimeZoneById("America/New_York");

The Better Alternative: DateTimeOffset

DateTime has a design flaw: the Kind property is metadata that is easily lost during serialization, database storage, or arithmetic. DateTimeOffset solves this by embedding the UTC offset directly in the value.

1DateTimeOffset now = DateTimeOffset.Now;
2DateTimeOffset utcNow = DateTimeOffset.UtcNow;
3
4Console.WriteLine(now);     // 2026-06-18 14:30:00 -04:00
5Console.WriteLine(utcNow);  // 2026-06-18 18:30:00 +00:00
6
7// The offset is part of the value, not a separate metadata field
8// This survives serialization, JSON, database round-trips

If you are starting a new project, prefer DateTimeOffset over DateTime. It eliminates the "which time zone was this?" ambiguity entirely.

1// Store in a database as datetimeoffset column
2// SQL Server, PostgreSQL (timestamptz), and most ORMs handle this natively
3
4// Entity Framework example
5public class AuditLog
6{
7    public int Id { get; set; }
8    public string Action { get; set; }
9    public DateTimeOffset Timestamp { get; set; }  // not DateTime
10}

When to Use Each

Common Pitfalls

• Storing DateTime.Now in a database without recording the time zone. When the server moves to a different time zone (or the application is deployed to a cloud region), all historical timestamps become ambiguous.
• Comparing DateTime values with different Kind properties. DateTime.Equals() ignores Kind, so a Local time and a UTC time with the same numeric value will compare as equal even though they represent different moments.
• Using DateTime.Now for elapsed time calculations. The system clock can be adjusted by NTP sync, daylight saving transitions, or manual changes. Use Stopwatch or Environment.TickCount64 for measuring durations.
• Assuming ToLocalTime() and ToUniversalTime() are inverses. They behave differently depending on the Kind of the input. If Kind is Unspecified, ToLocalTime() assumes the value is UTC, and ToUniversalTime() assumes it is local. This silent assumption is a common bug source.
• Serializing DateTime to JSON without specifying the format. The default serialization varies by library and may or may not include the time zone indicator. Always use ISO 8601 with an explicit Z suffix for UTC.

Summary

• Use DateTime.UtcNow as the default for server-side code, logging, storage, and any timestamp that crosses machine or time zone boundaries.
• Use DateTime.Now only when you need to display the local time on the current machine.
• DateTimeOffset is a better type than DateTime for most applications because it embeds the UTC offset and survives serialization round-trips.
• Always store timestamps in UTC and convert to local time only at the display layer.
• Never use DateTime.Now for elapsed time measurement. Use Stopwatch instead.