Best way to handle datetimes for any culture?

[Guest]

My app runs perfectly when run in Canada or the U.S. But others are
experiencing problems. So I switched my computer to the UK culture and
immediately saw a problem. This line was failing:

Convert.ChangeType(newdate, propType, null);

where propType = System.DateTime

It would only fail for dates like this: May 18, 2006 = 5/18/2006 in
US/Canadian format.

So I changed it to this:

Convert.ChangeType(newdate, propType, CultureInfo.InvariantCulture)

and this *seems* to have resolved the problem. But then I got to wondering:
What happens if a data file is created in England, where the format is
dd/mm/yyyy and opened on a US/Canadian computer where the format is
mm/dd/yyyy ?

Put another way, I'm looking for suggestions on best practices for handling
dates internationally. Is there a simple dotNet way to handle/store dates?

 

[Barry Kelly]

Put another way, I'm looking for suggestions on best practices for handling
dates internationally. Is there a simple dotNet way to handle/store dates?

Yes. DateTime - and always use UTC where you can, only displaying
local time on the user interface.

If you want round-trip guaranteed to a data file in text format, then
use DateTime.ToString("s"). The "s" format conforms to ISO 8601, and
what's more, it's character-by-character sortable in proper order.
Alternatively, use the "u" or "U" formats, which are similarly sortable
but slightly different. Make sure you read the documentation on Standard
DateTime Format Strings.

You can read these strings back in using DateTime.Parse or ParseExact.

-- Barry

 

[Guest]

Barry,

Thank you for the invaluable advice. I just found this page and read it
thoroughly: http://msdn2.microsoft.com/en-us/library/az4se3k1.aspx

It's still early on in my Alpha testing program so I suppose I could tell
everyone involved to just delete their existing data files and start afresh,
but I think it might be better to add some code to load in existing "en-US"
date formats. Do you think I should look for the existence of the "T" as the
11th character in the "s" format or perhaps just have a try-catch clause to
handle those situation where an en-US date is encountered?

Another question: Is it commonplace to store in a data file the Culture in
which the data file was created?

 

[Barry Kelly]

It's still early on in my Alpha testing program so I suppose I could tell
everyone involved to just delete their existing data files and start afresh,
but I think it might be better to add some code to load in existing "en-US"
date formats. Do you think I should look for the existence of the "T" as the
11th character in the "s" format or perhaps just have a try-catch clause to
handle those situation where an en-US date is encountered?

DateTime has a TryParseExact method, so you don't need to do a try-catch
to try to parse. You can put your priority order with a list of:

if (!DateTime.TryParseExact(/* ... */)
&& !DateTime.TryParseExact(/* ... */) // etc.

Another question: Is it commonplace to store in a data file the Culture in
which the data file was created?

That depends on the data file and its application. If it needs to be
user-readable, and you don't need guaranteed round-tripping, then it's
OK to use the current culture.

Otherwise, pick one invariant format and stick with it.

-- Barry

 

[Guest]

Barry,

I'm only running VS2003 so TryParseExact isn't an option for me.

Here's some sample code I've been experimenting with:

// Get the current date & time
DateTime today = DateTime.Now;

// Convert into a string using the ISO8601 format
string sDate = today.ToString("s");

// Convert the string interpretation of the date back into DateTime
format
DateTime newDate = DateTime.Parse(sDate, CultureInfo.InvariantCulture);


This all *SEEMS* to work, but we'll see what happens when I implement it
throughout my codebase.

 

[Claes Bergefall]

There is a ParseExact method that you can use if you need to specify the
exact format of the input string (however weird it may be). You can even
give it an array of possible formats. This method exists in all versions of
..NET. Using this method you can rewrite your sample as follows:

// Get the current date & time
DateTime today = DateTime.Now;

// Convert into a string using the ISO8601 format
string sDate = today.ToString("s");

// Convert the string interpretation of the date back into DateTime format
DateTime newDate = DateTime.TryParse(sDate, "s", null);

Since the "s" format string is culture independent (same goes for "u" btw)
you don't need to worry about the culture

/claes