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?


--
Robert W.
Vancouver, BC
www.mwtech.com

Robert W. <(E-Mail Removed)> wrote:

> 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

--
http://barrkel.blogspot.com/

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?

--
Robert W.
Vancouver, BC
www.mwtech.com



"Barry Kelly" wrote:

> Robert W. <(E-Mail Removed)> wrote:
>
> > 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
>
> --
> http://barrkel.blogspot.com/
>

Robert W. <(E-Mail Removed)> wrote:

> 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

--
http://barrkel.blogspot.com/

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.


--
Robert W.
Vancouver, BC
www.mwtech.com



"Barry Kelly" wrote:

> Robert W. <(E-Mail Removed)> wrote:
>
> > 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
>
> --
> http://barrkel.blogspot.com/
>

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

"Robert W." <(E-Mail Removed)> wrote in message
news2855438-A3BD-4728-BD54-(E-Mail Removed)...
> 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.
>
>
> --
> Robert W.
> Vancouver, BC
> www.mwtech.com
>
>
>
> "Barry Kelly" wrote:
>
>> Robert W. <(E-Mail Removed)> wrote:
>>
>> > 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
>>
>> --
>> http://barrkel.blogspot.com/
>>