DateTime.UtcNow is generally preferable to DateTime.Now

re: DateTime.UtcNow is generally preferable to DateTime.Now

Kirill Osenkov - MSFT — Thu, 12 Jan 2012 06:04:38 GMT

Sk - sorry about that - follow the link to Keyvan's article, he has detailed explanations and the benchmark source code.

re: DateTime.UtcNow is generally preferable to DateTime.Now

Sk — Thu, 12 Jan 2012 01:47:34 GMT

@Kirill Could you add the labels for the xy-axis on the chart. I am not sure what we are comparing. I just see numbers only which is not that informative. Thanks.

re: DateTime.UtcNow is generally preferable to DateTime.Now

Kirill Osenkov - MSFT — Thu, 12 Jan 2012 00:58:34 GMT

James - also thanks for the DateTimeOffset tip :)

re: DateTime.UtcNow is generally preferable to DateTime.Now

Kirill Osenkov - MSFT — Thu, 12 Jan 2012 00:57:51 GMT

Oleg - we just use it as a random number generator when we need a random looking version :)

re: DateTime.UtcNow is generally preferable to DateTime.Now

Kirill Osenkov - MSFT — Thu, 12 Jan 2012 00:57:07 GMT

Folks, I just noticed that Keyvan's benchmark counts allocations of the Stopwatch object. If he reuses the same Stopwatch instance, the perf will be much much better than shown on his graph. I've posted my own graph in the post above without allocations for Stopwatch.

re: DateTime.UtcNow is generally preferable to DateTime.Now

Damian Hickey — Wed, 11 Jan 2012 12:48:56 GMT

Consider not using DateTime.UtcNow either but a 'SystemTime' abstraction. Reading DateTime.UtcNow can also be significantly optimized.

dhickey.ie/.../SystemClock.aspx

re: DateTime.UtcNow is generally preferable to DateTime.Now

Oleg Mihailik — Wed, 11 Jan 2012 09:29:49 GMT

Why would you use localized time for Version generation?

In global companies with projects developed from multiple time zones it is likely to ruin the ordering. Consider this very real and likely situation:

I build and release an app from New Jersey. Version generated from wall clock is 1.234.

The app has a bug which is picked by my colleague from Bangalore.

In 15 minutes she fixes, tests and releases a new patched version, which is 1.155.

It is late night in Jersey City, but early morning in Bangalore. So my version is larger than hers. Imagine how misleading it will be to debug any problem in this situation.

re: DateTime.UtcNow is generally preferable to DateTime.Now

James Manning — Wed, 11 Jan 2012 05:13:20 GMT

IMHO using DateTimeOffset (datetimeoffset type in SQL Server) is better for many applications since you 'free' yourself from having to worry about converting to or from UTC - when it comes time to display it to the user, you can have it display in their timezone regardless of what it started out as.

*So* many headaches/bugs come up from people forgetting to 'normalize' onto UTC, that it really doesn't seem worth using 'just' DateTime in the vast majority of cases.

And there's still DateTimeOffset.UtcNow to use for that case, which should be very fast since it's DateTime.UtcNow with TimeSpan.Zero :)

re: DateTime.UtcNow is generally preferable to DateTime.Now

Diego F. — Tue, 10 Jan 2012 20:41:45 GMT

Great tip, never thought about it, even while seeing performance reports pointing to DateTime.Now costs. The small things that make difference. I didn't know I had a cheap alternative.