Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As you pointed out, there are cultural differences to how we treat dates when they are represented by strings. The <code>DD/MM/YYYY</code> format is common throughout much of Europe and other parts of the world, while <code>MM/DD/YYYY</code> is used almost exclusively by the USA (with a few exceptions). There are plenty of other formats as well.</p> <p>There is one <em>important</em> format that you should know, which is the <a href="http://en.wikipedia.org/wiki/Iso8601" rel="nofollow">ISO8601</a> standard. You may typically see this as a timestamp, such as <code>2013-05-31T02:20:33</code>. Sometimes a trailing <code>Z</code> is included to indicate that the time is at UTC. You might also see an offset such as <code>-07:00</code> or just <code>-0700</code>. This is all part of the same standard. The most common usage is also denoted in <a href="http://www.ietf.org/rfc/rfc3339.txt" rel="nofollow">RFC3339</a>. Whenever you actually need to send a <code>DateTime</code> as a string, you should probably be using this format. (The exception is when showing the string to a user, and when gathering input from a user.)</p> <p>Now, you should understand that a <code>DateTime</code> is <em>not</em> a string value. It is internally represented by a 64-bit integer. It does not internally keep <em>any</em> format or culture settings. Conversion between <code>DateTime</code> and <code>string</code> should only be done for purposes of input and output. Usually this is in your user interface, or in the case of ASP.Net, it can be on your web page.</p> <p>Anywhere else that you work with <code>DateTime</code>, you should <em>not</em> be dealing with strings at all. Especially when comparing values. Let us dissect your code. First we had this line:</p> <pre><code>DateTime time1 = Convert.ToDateTime("6/2/2013 5:21:05 PM"); </code></pre> <p>Now you said it was coming out of the database, but if that is the case then you shouldn't have a string. Let's assume you are using a SQL Server database (but the same concept applies in others), and the data is in a column of <code>DateTime</code> type. When you retrieve the value from your data access layer, it should flow from SQL to .Net as a pure <code>DateTime</code>. There is no string involved. Let's just assume you are using ADO.Net and you have a <code>DataReader</code>. You should be loading your value as:</p> <pre><code>DateTime time1 = (DateTime)reader["columnname"]; // good </code></pre> <p>If instead you are doing something like this:</p> <pre><code>DateTime time1 = Convert.ToDateTime(reader["columnname"].ToString()); // bad! </code></pre> <p>then you are introducing culture info into the string that you are using as the intermediate step. This is likely the source of your problem. Don't use a string when you don't need to.</p> <p>Also, I would avoid using <code>Convert.ToDateTime</code> at all. If you really do need to parse a string, you should use <code>DateTime.Parse</code>, and if you already know the exact format of that string then you should use <code>DateTime.ParseExact</code>.</p> <p>Next line from your code was:</p> <pre><code>DateTime now = DateTime.Now; </code></pre> <p>For this, you should understand that you are taking the local time from the clock on your server. This is probably not the time of the user of your site. And since you are comparing it to a database value, that means you are storing local times in your database as well. This can be very problematic, because the server could have particular time zone settings. Also, if the time zone goes through changes for Daylight Saving Time (a.k.a. Summer Time), then there are some values that don't exist and some values that exist <em>twice</em>. This can cause major issues, especially when comparing these values. The better approach would be to use either <code>DateTime.UtcNow</code>, or use the <code>DateTimeOffset</code> type instead of the <code>DateTime</code> type. You can read more about this, <a href="http://codeofmatt.com/2013/04/25/the-case-against-datetime-now/" rel="nofollow">here</a>.</p> <p>Last line:</p> <pre><code>int num = DateTime.Compare(time1, now); </code></pre> <p>This is fine, but you might find it easier to use regular boolean comparisons, such as:</p> <pre><code>if (time1 &gt;= now) ... </code></pre> <p>So how then to deal with culture issues? When parsing input from the user, do something like this:</p> <pre><code>// Use the culture setting of your user. Perhaps DNN has this already. CultureInfo provider = new CultureInfo("de-DE"); // Parse the input string, but let the provider do the work to know the format. DateTime dt = DateTime.Parse("31/5/2013", provider); // Send data back to the user with the same provider. string s = dt.ToString("d", provider); </code></pre> <p>You may prefer to use the <a href="http://msdn.microsoft.com/en-us/library/9h21f14e.aspx" rel="nofollow"><code>TryParse</code></a> method, in case your user gives bad data:</p> <pre><code>DateTime dt; if (!DateTime.TryParse(s, provider, DateTimeStyles.None, out dt) { // handle invalid data } </code></pre> <p>Lastly, you should familiarize yourself with <a href="http://msdn.microsoft.com/en-us/library/system.datetime.kind.aspx" rel="nofollow"><code>DateTime.Kind</code></a>, and understand the difference between <code>Local</code>, <code>Utc</code>, and <code>Unspecified</code> kinds. And if you find you need to deal with other time zones in your application, then you may also need to learn about the <a href="http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx" rel="nofollow">TimeZoneInfo</a> class.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload