DateTime question!

[DBC User]

Is it possible to check a datetime value as in which culture format?
My program is written for international customers. I have a function
which converts the date and time to en-US format and is working. But I
want to check before converting to see if the date and time is already
in en-US format? Can I do this without using Try and catch?

Thanks.

[Jon Skeet [C# MVP]]

On Mar 30, 2:25 pm, "DBC User" <[e-mail]:

Is it possible to check a datetime value as in which culture format?

No. A DateTime is just a point in time (well, nearly - there are
timezone issues too).

My program is written for international customers. I have a function
which converts the date and time to en-US format and is working. But I
want to check before converting to see if the date and time is already
in en-US format? Can I do this without using Try and catch?

That's like saying:

double x = 10.5;

Is that double in European format ("10,5") or English format ("10.5")?
The answer is neither - the number is just a number. It's only when
you format it that it takes on any cultural significance.

Jon

[DBC User]

On Mar 30, 8:29 am, "Jon Skeet [C# MVP]" <[e-mail]:

On Mar 30, 2:25 pm, "DBC User" <[e-mail]:

Is it possible to check a datetime value as in which culture format?

No. A DateTime is just a point in time (well, nearly - there are
timezone issues too).

My program is written for international customers. I have a function
which converts the date and time to en-US format and is working. But I
want to check before converting to see if the date and time is already
in en-US format? Can I do this without using Try and catch?

That's like saying:

double x = 10.5;

Is that double in European format ("10,5") or English format ("10.5")?
The answer is neither - the number is just a number. It's only when
you format it that it takes on any cultural significance.

Jon

Hi Jon,

Thanks and I understand your point. In my case, the data is stored in
a XML file created by another process that I don't have control over.
So I want to read the data correct.
The reason for my questions is, in production I ran into a situation,
where one element was stored in de-DE (local culture, without am/pm
and 24 hour clock) format and another element was stored in en-US
format as strings. Now when I read the data, I want to make sure I am
not blindly convert all the datetime string from current culture to US
since, some of them are already in US format.
So I thought I will put a check first before converting.

[Jon Skeet [C# MVP]]

On Mar 30, 2:44 pm, "DBC User" <[e-mail]:

Thanks and I understand your point. In my case, the data is stored in
a XML file created by another process that I don't have control over.
So I want to read the data correct.

Ah, in that case you don't have a DateTime to start with - you have a
String. That's a completely different matter :)

Rather than checking for different formats in your code, I'd find out
(for sure) what the other process will create - and try it in
different cultures. If it's sensible, it'll stick to one format. Then
again, there's plenty of code around which isn't sensible...

Jon

[DBC User]

On Mar 30, 8:46 am, "Jon Skeet [C# MVP]" <[e-mail]:

On Mar 30, 2:44 pm, "DBC User" <[e-mail]:

Thanks and I understand your point. In my case, the data is stored in
a XML file created by another process that I don't have control over.
So I want to read the data correct.

Ah, in that case you don't have a DateTime to start with - you have a
String. That's a completely different matter :)

Rather than checking for different formats in your code, I'd find out
(for sure) what the other process will create - and try it in
different cultures. If it's sensible, it'll stick to one format. Then
again, there's plenty of code around which isn't sensible...

Jon

I agree with your last part and the 3rd party group will not release
fix for this issue for another couple of months and that also I am not
sure. (one of the reason is, their product is supposed to be the end
product, but I am scaling it and that they don't like).
So I thought, all I have to do is check and see if the string is in US
format by forcing a datetime pharse on US and if it fails (with try
and catch), then try to pharse it in native format. But woundering if
there is a better way.

[Mythran]

"DBC User" <db*****@gmail.comwrote in message
news:11**********************@o5g2000hsb.googlegro ups.com...

On Mar 30, 8:46 am, "Jon Skeet [C# MVP]" <[e-mail]:

>On Mar 30, 2:44 pm, "DBC User" <[e-mail]:

Thanks and I understand your point. In my case, the data is stored in
a XML file created by another process that I don't have control over.
So I want to read the data correct.

Ah, in that case you don't have a DateTime to start with - you have a
String. That's a completely different matter :)

Rather than checking for different formats in your code, I'd find out
(for sure) what the other process will create - and try it in
different cultures. If it's sensible, it'll stick to one format. Then
again, there's plenty of code around which isn't sensible...

Jon

I agree with your last part and the 3rd party group will not release
fix for this issue for another couple of months and that also I am not
sure. (one of the reason is, their product is supposed to be the end
product, but I am scaling it and that they don't like).
So I thought, all I have to do is check and see if the string is in US
format by forcing a datetime pharse on US and if it fails (with try
and catch), then try to pharse it in native format. But woundering if
there is a better way.

How can you be sure that it is in en-us?

10-11-2007 could be oct 11th, 2007 or Nov 10th, 2007...

HTH,
Mythran

[DBC User]

On Mar 30, 10:51 am, "Mythran" <[e-mail]:

"DBC User" <[e-mail] in message

news:11**********************@o5g2000hsb.googlegro ups.com...

On Mar 30, 8:46 am, "Jon Skeet [C# MVP]" <[e-mail]:

On Mar 30, 2:44 pm, "DBC User" <[e-mail]:

Thanks and I understand your point. In my case, the data is stored in
a XML file created by another process that I don't have control over.
So I want to read the data correct.

Ah, in that case you don't have a DateTime to start with - you have a
String. That's a completely different matter :)

Rather than checking for different formats in your code, I'd find out
(for sure) what the other process will create - and try it in
different cultures. If it's sensible, it'll stick to one format. Then
again, there's plenty of code around which isn't sensible...

Jon

I agree with your last part and the 3rd party group will not release
fix for this issue for another couple of months and that also I am not
sure. (one of the reason is, their product is supposed to be the end
product, but I am scaling it and that they don't like).
So I thought, all I have to do is check and see if the string is in US
format by forcing a datetime pharse on US and if it fails (with try
and catch), then try to pharse it in native format. But woundering if
there is a better way.

How can you be sure that it is in en-us?

10-11-2007 could be oct 11th, 2007 or Nov 10th, 2007...

HTH,
Mythran- Hide quoted text -

- Show quoted text -

Good question and that I don't. I have another question, if I have the
following code, will all my pharsing and storing will be in the
culture specified?

Thread.CurrentThread.CurrentCulture = new
System.Globalization.CultureInfo("en-US");

Thanks.