<p>I've been wondering what exactly are the principles of how the two properties work. I know the second one is universal and basically doesn't deal with time zones, but can someone explain in detail how they work and which one should be used in what scenario?</p>

[{'answer_id': 62160, 'author': 'Blair Conrad', 'author_id': 1199, 'author_profile': 'https://Stackoverflow.com/users/1199', 'pm_score': 10, 'selected': True, 'text': '<p><a href="http://msdn.microsoft.com/en-us/library/system.datetime.utcnow.aspx" rel="noreferrer">DateTime.UtcNow</a> tells you the date and time as it would be in Coordinated Universal Time, which is also called the Greenwich Mean Time time zone - basically like it would be if you were in London England, but not during the summer. <a href="http://msdn.microsoft.com/en-us/library/system.datetime.now.aspx" rel="noreferrer">DateTime.Now</a> gives the date and time as it would appear to someone in your current locale. </p>\n\n<p>I\'d recommend using <code>DateTime.Now</code> whenever you\'re displaying a date to a human being - that way they\'re comfortable with the value they see - it\'s something that they can easily compare to what they see on their watch or clock. Use <code>DateTime.UtcNow</code> when you want to store dates or use them for later calculations that way (in a client-server model) your calculations don\'t become confused by clients in different time zones from your server or from each other.</p>\n'}, {'answer_id': 62164, 'author': 'Jeff Atwood', 'author_id': 1, 'author_profile': 'https://Stackoverflow.com/users/1', 'pm_score': 7, 'selected': False, 'text': '<p>It\'s really quite simple, so I think it depends what your audience is and where they live.</p>\n\n<p>If you don\'t use Utc, you <em>must</em> know the timezone of the person you\'re displaying dates and times to -- otherwise you will tell them something happened at 3 PM in system or server time, when it really happened at 5 PM where they happen to live.</p>\n\n<p>We use <code>DateTime.UtcNow</code> because we have a global web audience, and because I\'d prefer not to nag every user to fill out a form indicating what timezone they live in.</p>\n\n<p>We also display relative times (2 hours ago, 1 day ago, etc) until the post ages enough that the time is "the same" no matter where on Earth you live.</p>\n'}, {'answer_id': 62166, 'author': 'kender', 'author_id': 4172, 'author_profile': 'https://Stackoverflow.com/users/4172', 'pm_score': 1, 'selected': False, 'text': "<p>When you need a local time for the machine your application runs at (like CEST for Europe), use Now. If you want a universal time - UtcNow. It's just matter of your preferences - probably making a local website / standalone application you'd want to use the time user has - so affected by his/her timezone setting - DateTime.Now.</p>\n\n<p>Just remember, for a website it's the timezone setting of the server. So if you're displaying the time for the user, either get his prefered timezone and shift the time (just save Utc time to database then, and modify it) or specify it's UTC. If you forget to do so, user can see something like: <em>posted 3 minuses ago</em> and then a time in the future near it :)</p>\n"}, {'answer_id': 62169, 'author': 'Omer van Kloeten', 'author_id': 4979, 'author_profile': 'https://Stackoverflow.com/users/4979', 'pm_score': 3, 'selected': False, 'text': '<p>DateTime has no idea what time zones are. It always assumes you\'re at your local time. <em>UtcNow</em> only means "Subtract my timezone from the time".</p>\n\n<p>If you want to use timezone-aware dates, use <strong>DateTimeOffset</strong>, which represents a date/time with a timezone. I had to learn that the hard way.</p>\n'}, {'answer_id': 76542, 'author': 'Carl Camera', 'author_id': 12804, 'author_profile': 'https://Stackoverflow.com/users/12804', 'pm_score': 5, 'selected': False, 'text': '<p>One main concept to understand in .NET is that <strong>now</strong> is <strong>now</strong> all over the earth no matter what time zone you are in. So if you load a variable with <code>DateTime.Now</code> or <code>DateTime.UtcNow</code> -- the assignment is identical.*  Your <code>DateTime</code> object knows what timezone you are in and takes that into account regardless of the assignment.</p>\n\n<p>The usefulness of <code>DateTime.UtcNow</code> comes in handy when calculating dates across Daylight Savings Time boundaries.  That is, in places that participate in daylight savings time, sometimes there are 25 hours from noon to noon the following day, and sometimes there are 23 hours between noon and noon the following day. If you want to correctly determine the number of hours from time A and time B, you need to first translate each to their UTC equivalents before calculating the <code>TimeSpan</code>.</p>\n\n<p>This is covered by a <a href="http://carl.camera/default.aspx?id=76" rel="noreferrer">blog post i wrote</a> that further explains <code>TimeSpan</code>, and includes a link to an even more extensive MS article on the topic.</p>\n\n<p>*Clarification: Either assignment will store the current time. If you were to load two variables one via <code>DateTime.Now()</code> and the other via <code>DateTime.UtcNow()</code> the <code>TimeSpan</code> difference between the two would be milliseconds, not hours assuming you are in a timezone hours away from GMT. As noted below, printing out their <code>String</code> values would display different strings.</p>\n'}, {'answer_id': 572968, 'author': 'Magnus Krisell', 'author_id': 69311, 'author_profile': 'https://Stackoverflow.com/users/69311', 'pm_score': 6, 'selected': False, 'text': '<p>Also note the performance difference; <code>DateTime.UtcNow</code> is somewhere around <strong>30</strong> times faster then <code>DateTime.Now</code>, because internally <code>DateTime.Now</code> is doing a lot of timezone adjustments (you can easily verify this with Reflector).</p>\n\n<p>So do NOT use <code>DateTime.Now</code> for relative time measurements.</p>\n'}, {'answer_id': 762610, 'author': 'Jan Zich', 'author_id': 15716, 'author_profile': 'https://Stackoverflow.com/users/15716', 'pm_score': 2, 'selected': False, 'text': '<p>Just a little addition to the points made above: the DateTime struct also contains a little known field called <a href="http://msdn.microsoft.com/en-us/library/system.datetime.kind.aspx" rel="nofollow noreferrer">Kind</a> (at least, I did not know about it for a long time). It is basically just a flag indicating whether the time is local or UTC; it does not specify the real offset from UTC for local times. Besides the fact that it indicates with what intentions the stuct was constructed, it also influences the way how the methods <a href="http://msdn.microsoft.com/en-us/library/system.datetime.touniversaltime.aspx" rel="nofollow noreferrer">ToUniversalTime()</a> and <a href="http://msdn.microsoft.com/en-us/library/system.datetime.tolocaltime.aspx" rel="nofollow noreferrer">ToLocalTime()</a> work.</p>\n'}, {'answer_id': 7431423, 'author': 'Sorin Comanescu', 'author_id': 117290, 'author_profile': 'https://Stackoverflow.com/users/117290', 'pm_score': 2, 'selected': False, 'text': '<p>A little bit late to the party, but I found these two links (4guysfromrolla) to be very useful:</p>\n\n<p><a href="https://web.archive.org/web/20201202215446/http://www.4guysfromrolla.com/articles/081507-1.aspx" rel="nofollow">Using Coordinated Universal Time (UTC) to Store Date/Time Values</a> </p>\n\n<p><a href="https://web.archive.org/web/20211020140128/https://www.4guysfromrolla.com/articles/040710-1.aspx" rel="nofollow">Advice for Storing and Displaying Dates and Times Across Different Time Zones</a></p>\n'}, {'answer_id': 12427822, 'author': 'PapillonUK', 'author_id': 144400, 'author_profile': 'https://Stackoverflow.com/users/144400', 'pm_score': 3, 'selected': False, 'text': '<p>The "simple" answer to the question is:</p>\n\n<p><strong>DateTime.Now</strong> returns a <strong>DateTime</strong> value representing the current, system time (in whatever time zone the system is running in). The <strong>DateTime.Kind</strong> property will be <strong>DateTimeKind.Local</strong></p>\n\n<p><strong>DateTime.UtcNow</strong> returns a <strong>DateTime</strong> value representing the current Universal Co-ordinated Time (aka UTC) which will be the same regardless of the system\'s time zone. The <strong>DateTime.Kind</strong> property will be <strong>DateTimeKind.Utc</strong></p>\n'}, {'answer_id': 25725833, 'author': 'user1315023', 'author_id': 1315023, 'author_profile': 'https://Stackoverflow.com/users/1315023', 'pm_score': 1, 'selected': False, 'text': "<p>DateTime.UtcNow is a continuous, single-valued time scale, whereas DateTime.Now is not continuous or single-valued. The primary reason is Daylight Savings Time, which doesn't apply to UTC. So UTC never jumps forward or back an hour, whereas local time(DateTime.Now) does. And when it jumps backward, the same time value occurs twice.</p>\n"}, {'answer_id': 30132890, 'author': 'Ted Bigham', 'author_id': 868121, 'author_profile': 'https://Stackoverflow.com/users/868121', 'pm_score': 5, 'selected': False, 'text': '<p>This is a good question. I\'m reviving it to give a little more detail on how .Net behaves with different <code>Kind</code> values.  As @Jan Zich points out, It\'s actually a critically important property and is set differently depending on whether you use <code>Now</code> or <code>UtcNow</code>.</p>\n\n<p>Internally the date is stored as <code>Ticks</code> which (contrary to @Carl Camera\'s answer) is different depending on if you use <code>Now</code> or <code>UtcNow</code>.  </p>\n\n<p><code>DateTime.UtcNow</code> behaves like other languages.  It sets <code>Ticks</code> to a GMT based value.  It also sets <code>Kind</code> to <code>Utc</code>.  </p>\n\n<p><code>DateTime.Now</code> alters the <code>Ticks</code> value to <strong>what it would be if it was your time of day in the GMT time zone</strong>.  It also sets <code>Kind</code> to <code>Local</code>.</p>\n\n<p>If you\'re 6 hours behind (GMT-6), you\'ll get the GMT time from 6 hours ago.  .Net actually ignores <code>Kind</code> and treats this time as if it was 6 hours ago, even though it\'s supposed to be "now".  This breaks even more if you create a <code>DateTime</code> instance then change your time zone and try to use it.</p>\n\n<p><strong>DateTime instances with different \'Kind\' values are NOT compatible.</strong></p>\n\n<p>Let\'s look at some code...</p>\n\n<pre><code>    DateTime utc = DateTime.UtcNow;\n    DateTime now = DateTime.Now;\n    Debug.Log (utc + " " + utc.Kind);  // 05/20/2015 17:19:27 Utc\n    Debug.Log (now + " " + now.Kind);  // 05/20/2015 10:19:27 Local\n\n    Debug.Log (utc.Ticks);  // 635677391678617830\n    Debug.Log (now.Ticks);  // 635677139678617840\n\n    now = now.AddHours(1);\n    TimeSpan diff = utc - now;\n    Debug.Log (diff);  // 05:59:59.9999990\n\n    Debug.Log (utc &lt;  now);  // false\n    Debug.Log (utc == now);  // false\n    Debug.Log (utc &gt;  now);  // true\n\n    Debug.Log (utc.ToUniversalTime() &lt;  now.ToUniversalTime());  // true\n    Debug.Log (utc.ToUniversalTime() == now.ToUniversalTime());  // false\n    Debug.Log (utc.ToUniversalTime() &gt;  now.ToUniversalTime());  // false\n    Debug.Log (utc.ToUniversalTime() -  now.ToUniversalTime());  // -01:00:00.0000010\n</code></pre>\n\n<p>As you can see here, comparisons and math functions don\'t automatically convert to compatible times.  The <code>Timespan</code> should have been almost one hour, but instead was almost 6.  "utc &lt; now" should have been true (I even added an hour to be sure), but was still false.</p>\n\n<p>You can also see the \'work around\' which is to simply convert to universal time anywhere that <code>Kind</code> is not the same.</p>\n\n<p>My direct answer to the question agrees with the accepted answer\'s recommendation about when to use each one.  You should always <strong>try</strong> to work with <code>DateTime</code> objects that have <code>Kind=Utc</code>, except during i/o (displaying and parsing).  This means you should almost always be using <code>DateTime.UtcNow</code>, except for the cases where you\'re creating the object just to display it, and discard it right away.</p>\n'}, {'answer_id': 52625078, 'author': 'ChaiVan', 'author_id': 5822206, 'author_profile': 'https://Stackoverflow.com/users/5822206', 'pm_score': 2, 'selected': False, 'text': '<p>DateTime.UtcNow is a Universal time scale omitting Daylight Savings Time. So UTC never changes due to DST.</p>\n\n<p>But, DateTime.Now is not continuous or single-valued because it changes according to DST. Which means DateTime.Now, the same time value may occur twice leaving customers in a confused state.</p>\n'}, {'answer_id': 58100522, 'author': 'Michel LAPLANE', 'author_id': 6564189, 'author_profile': 'https://Stackoverflow.com/users/6564189', 'pm_score': 1, 'selected': False, 'text': '<p>The big difference :) is that DateTime.Now is not supported in SharePoint Workflow you must use DateTime.UtcNow</p>\n'}]
['https://Stackoverflow.com/questions/62151', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/1801/']