Simple String To Date Time

[Ross Presser]

Could you give an example where you'd *want* the specified format to
give different results in different cultures?

The only one I can think of involves a different calendar, as I said.

For instance, in the Hebrew calendar, there are frequently leap months (7
out of every 19 years), so

DateTime dt = DateTime.ParseExact(
"13075765","MMddyyyy", new CultureInfo("he-IL"))

might *not* return an error, but

DateTime dt = DateTime.ParseExact(
"13072005","MMddyyyy", CultureInfo.InvariantCulture)

definitely should. Likewise, a

I don't know if this is actually the case, however. I know the .net
framework does have support for other calendars (see
CultureInfo.OptionalCalendars), but I don't know if it extends to
ParseExact, nor how it would work there.

 

[Ross Presser]

The only one I can think of involves a different calendar, as I said.

For instance, in the Hebrew calendar, there are frequently leap months (7
out of every 19 years), so

DateTime dt = DateTime.ParseExact(
"13075765","MMddyyyy", new CultureInfo("he-IL"))

might *not* return an error, but

DateTime dt = DateTime.ParseExact(
"13072005","MMddyyyy", CultureInfo.InvariantCulture)

definitely should. Likewise, a

I don't know if this is actually the case, however. I know the .net
framework does have support for other calendars (see
CultureInfo.OptionalCalendars), but I don't know if it extends to
ParseExact, nor how it would work there.

Did some more testing, and here's what you need to do to parse Hebrew
calendar dates:

Dim cal As New System.Globalization.HebrewCalendar()
Dim heb As New System.Globalization.CultureInfo("he-IL")
heb.DateTimeFormat.Calendar = cal

Dim dt As DateTime = DateTime.ParseExact("13075765", "MMddyyyy", heb)
' throws no error

Debug.WriteLine(dt.ToString("MMM dd, yyyy", _
System.Globalization.CultureInfo.InvariantCulture))
' Displays "Sep 11, 2005"

Debug.WriteLine(dt.ToString("MMM dd, yyyy", heb))
' Displays àìåì æ', úùñ"ä

if the above doesn't come through on Usenet, it is the hebrew
representation (using hebrew text) of "Elul zayin, tav shin samech hay"
which basically means "Seventh of Elul, year 765" (+5000 is assumed)

 

[Guest]

Jon I agree with example string "11111" which will be confusing.I wanted to
convey that in general practise we represent year as either 2 or 4 digits and
date,month as either 1 or 2 digits.

To avoid this "11111" confusion,we should do some formatting while storing
itself.

 

[Cor Ligthert [MVP]]

Jon,

And that makes perfect sense with what I did - I don't see that this
conversion *should* be dependent on the culture of the system.

Could you give an example where you'd *want* the specified format to
give different results in different cultures?

The problem for me is that I don't understand the text (not yours) above,
maybe is the answer from Ross one, I did not start a debat, I was asking it
to you if you knew it.

I don't see the function from this one. The DateTime is forever in ticks
while the string is fixed by the mask.

Cor

 

[Cor Ligthert [MVP]]

Ross,

Can you tell me what you wrote in your reply on this one, probably you have
a test in it with Hebrew characters, however I am to lazy to install those.

I thought by the way that it was called in the Hebrew calandar a leap year,
which has leap months, am I wrong in that?

Cor

 

[Cor Ligthert [MVP]]

Doh,

Forgot my last sentence it is completely wrong, I don't know why I wrote it
like this. It is the leap month.

Cor

 

[Cor Ligthert [MVP]]

Ross,

Thanks a lot, very interesting,

Cor

 

[Jon Skeet [C# MVP]]

The only one I can think of involves a different calendar, as I said.

But I *suspect* that the OP is likely to want to use the value in the
Gregorian calendar, whether or not the default CultureInfo gives a
Hebrew calendar. I could be wrong, of course, but it seems unlikely to
me.

 

[Cor Ligthert [MVP]]

Jon,

I tried it, in VB Net I can say

dim mydate as datetime = datetime.parseexact("211105","ddMMyy",Nothing)

The equivalent statement won't go in C#

Therefore you need a thirth parameter, whatever you use there is not
important as long as it is valid. (The currentculure goes as well fine).

Cor

 

[Ross Presser]

But I *suspect* that the OP is likely to want to use the value in the
Gregorian calendar, whether or not the default CultureInfo gives a
Hebrew calendar. I could be wrong, of course, but it seems unlikely to
me.

I agree... the different calendar possibility is a remote one.

 

[Jon Skeet [C# MVP]]

I tried it, in VB Net I can say

dim mydate as datetime = datetime.parseexact("211105","ddMMyy",Nothing)

The equivalent statement won't go in C#

Um, yes it will:

using System;

public class Test
{
static void Main()
{
DateTime date = DateTime.ParseExact("211105",
"ddMMyy",
null);

Console.WriteLine (date);
}
}

Therefore you need a thirth parameter, whatever you use there is not
important as long as it is valid. (The currentculure goes as well fine).

Using the current culture is equivalent to providing null:

<quote>
If provider is a null reference (Nothing in Visual Basic), the current
culture is used.
</quote>

However, I'd still prefer to use CultureInfo.InvariantCulture, as:

1) That shows in the code that I'm *not* trying to do anything that
relies on the current culture
2) If the current culture *does* do anything strange with numbers, it
won't interfere

What do you see as the *disadvantages* of using
CultureInfo.InvariantCulture?

 

[Cor Ligthert [MVP]]

Jon,

Strange, I tested it exactly as you did, however I can use this so will try
it again.

Thanks,

Cor

 

[Cor Ligthert [MVP]]

Jon,

I found where the IFormatProvider is needed by the parseExact, and it is
quite simple, it is where the month is used in characters and not in digits.
(patterns MMM and MMMM)

Therefore for you the invariantculture goes mostly right, for me it will
then mostly fail.



Cor

 

[Jon Skeet [C# MVP]]

I found where the IFormatProvider is needed by the parseExact, and it is
quite simple, it is where the month is used in characters and not in digits.
(patterns MMM and MMMM)

Well, that's certainly *a* place it's used. Are you absolutely sure
that it's not used (and will never be used in future versions) to work
out whether or not to accept digits from other cultures?

Therefore for you the invariantculture goes mostly right, for me it will
then mostly fail.

And if the pattern specified by the OP had included the month as a
word, I would have asked for further information - namely which culture
the name of the month was expected in.

As the pattern didn't include that, I believe it's reasonable to treat
it as a culturally-invariant one, or if there *are* cultural
differences, I suspect they *aren't* desirable in this case - hence the
specification of CultureInfo.InvariantCulture.

 

[Cor Ligthert [MVP]]

Jon,

I tried it with the Chinese Culture, in the culture and (West)Arabian))
digits as fixed datestring.



I did not see any change in the result of the representation in DateTime
than that it was accoording the Georgian Calendar.

I did not try the invariant with Dutch month names by the way, however did
it with the US setting and Dutch. Probably the invariant will work in the
Dutch setting in April, September, October, November and December. Now I
think about that, I think that the invariant means allowing with the English
Month names as well the day parts before the month as after that.

I did not try that yet. If you want to try it, in Dutch June is Juni.
(nl-NL or nl-BE)

Cor

 

[Jon Skeet [C# MVP]]

I tried it with the Chinese Culture, in the culture and (West)Arabian))
digits as fixed datestring.



I did not see any change in the result of the representation in DateTime
than that it was accoording the Georgian Calendar.

Right. That's reasonable, and hopeful - but I personally would rather
stick to the invariant culture when I actually *want* cultural
invariance, as I believe the OP did in this case.

When I specifically want the result to vary by culture, *then* I'll
specify the current cultuure, or null, or whatever.

I don't see why you object (assuming you do) to using the invariant
culture when no cultural variance is desired.

 

[Cor Ligthert [MVP]]

Jon,

It works as I suspected in my previous reply.
DateTime mijnDatum1 = DateTime.ParseExact("11 November 2005", "dd MMMM
yyyy", CultureInfo.InvariantCulture);

DateTime mijnDatum2 = DateTime.ParseExact("11 Juni 2005", "dd MMMM yyyy",
CultureInfo.InvariantCulture);

The second row gives an error.

I think that it is now at least clear for me.

Cor

 

[Jon Skeet [C# MVP]]

It works as I suspected in my previous reply.
DateTime mijnDatum1 = DateTime.ParseExact("11 November 2005", "dd MMMM
yyyy", CultureInfo.InvariantCulture);

DateTime mijnDatum2 = DateTime.ParseExact("11 Juni 2005", "dd MMMM yyyy",
CultureInfo.InvariantCulture);

The second row gives an error.

As I'd expect it to.

I think that it is now at least clear for me.

But in that case, you desire a culture-sensitive parse - so you should
use the appropriate culture. Does it not make sense to you to specify
the invariant culture when you want to parse using a format which does
not vary by culture?

 

[Cor Ligthert [MVP]]

Jon,

But in that case, you desire a culture-sensitive parse - so you should
use the appropriate culture. Does it not make sense to you to specify
the invariant culture when you want to parse using a format which does
not vary by culture?

No I want a culture independent parse, which will as far I tested works,
with ParseExact and the patern as long and as third parameter null/nothing,
as there are no months given in words. (No MMM and MMMM paterns).

The CultureInvariant is in fact culture dependent it is the Culture "en-*",
in words all cultures where as first language is spoken English.

Cor

 

[Cor Ligthert [MVP]]

Jon,

To do it culture independent without months, than this is for me the way.

Dim myDate As DateTime = DateTime.ParseExact("11 05 2001", "dd MM yyyy",
Nothing)
DateTime mijDate = DateTime.ParseExact("11 05 2005", "dd MM yyyy", null);

It tells exact that as culture nothing is used, which will not work as I
wrote before if the month is written in a culture dependent way (in words).

CultureInvariant means in fact nothing else than Culture 'en-*'. The
culture of all countries where English is spoken as first language.

Cor