.NET - Canadian DateTime Format Bug

EthanTowne

I currently have an application that needs to support multiple cultures. A date string is being passed in and is being parsed to a DateTime object. To allow for multiple cultures I am first setting the thread's culture and UICulture.

Here is an example of my code as it is:

First I set the culture for this thread. This is passed in on the URL (ex. en-us, en-ca, fr-ca):

CultureInfo ci = new CultureInfo(culture, false);
Thread.CurrentThread.CurrentUICulture = ci;
Thread.CurrentThread.CurrentCulture = ci;

I then take a date string that is also passed in on the URL and convert it to a DateTime. Depending on the culture the date will be passed in as mm/dd/yyyy or dd/mm/yyyy.

I parse the date strings with the following code:

DateTime DateTimeObject;
bool validDate = DateTime.TryParse(DateStringFromURL, Thread.CurrentThread.CurrentCulture, DateTimeStyles.None, out DateTimeObject);

The TryParse works for most cultures and out comes a valid datetime object. A problem arises with en-ca and fr-ca though. If the wrong format is passed in, the datestring does not parse correctly.

The following shows which format .NET seems to expect for each culture:

         dd/MM/yyyy    MM/dd/yyyy
EN-CA      Valid        Invalid
FR-CA     Invalid        Valid

EDIT: To be more exact here are the examples causing me problems:

For EN-CA:

DateTime.Parse("26/08/2014") //VALID
DateTime.Parse("08/26/2014") //EXCEPTION THROWN

For FR-CA:

DateTime.Parse("26/08/2014") //EXCEPTION THROWN
DateTime.Parse("08/26/2014") //VALID

This is backwards from how other systems treat this culture's date formatting.

Why are the formats seemingly backwards? Is this a bug with .NET 4.5?

Any and all help would be appreciated, thanks.

NOTE: .NET Version 4.5

Derek

You should probably look into Invariant culture. That is what you should use for your URL passing. You can use the local culture for display purposes on the client.

Typically, whenever you are storing data (for example, in a database or file ) it is best to use the Invariant culture. When displaying data you can use the local culture. When passing data around, you want to use Invariant culture.

Read more here.

Collected from the Internet

Please contact [email protected] to delete if infringement.

edited at
0

Comments

0 comments
Login to comment

Related

From Dev

.net DateTime Serialization Deserialization bug

From Dev

PHP DateTime::format('I') inaccuracy bug?

From Dev

PHP DateTime::format('I') inaccuracy bug?

From Dev

DateTime format in c# .Net

From Dev

Bug in .NET's DateTime.ToString("R") with UTC dates?

From Dev

Convert Datetime Format in Vb.net

From Dev

Convert a string to datetime format in asp .net

From Dev

String is not recognized as datetime format asp.net?

From Dev

Convert Datetime Format in Vb.net

From Dev

DateTime::createFromFormat is this a bug?

From Java

Specifying a custom DateTime format when serializing with Json.Net

From Dev

datetime tostring format changes date in vb.net

From Dev

ASP.NET MVC 4 - DateTime format issue in View

From Dev

Issue DateTime.ToString with string format "M" in .NET

From Dev

Datetime in 24 hours Clock format in asp.net

From Dev

standard format to convert string to datetime in vb.net

From Dev

asp.net DetailView datetime field format doesn't match the SQL Server format

From Dev

PHP MongoDate/DateTime bug or missunderstanding

From Dev

Is this intended behavior or a bug in datetime timedelta?

From Dev

is this a DateTime bug in php code ? 7.0.0

From Dev

ColdFusion serializeJSON date format (bug?)

From Dev

"Bug" in String.Format and Float

From Dev

Default format of a cell is "Time". Is it a bug?

From Dev

JIT .Net compiler bug?

From Dev

TimeZoneInfo bug in .net 4.5

From Dev

SQL Server / .Net bug?

From Dev

JIT .Net compiler bug?

From Dev

SQL Custom datetime format to datetime

From Dev

Convert datetime to another datetime format