parsing date string

  • Thread starter Thread starter z. f.
  • Start date Start date
There are systems that do not use Dutch as system culture...

:-)))
Click to expand...
Exactly and therefore is CDate without a formatstring much better.

I am glad that you agree at the end of this thread.

Cor
 
Cor,
What happens when the date is in a file being sent between Herfried, you and
I? In an XML file for example...

Relying on globalization in this case won't work, as there are at least 2
date formats in play, if we bring Japan into the mix, then there are at
least three!


The OP indicated that he had a date in a specific format "dd/mm/yyyyy
hh:mm:ss" he also suggested that DateTime.Parse failed on it, which would
suggest to me that CDate would also fail (as they are both based on the
regional settings). Hence the need to use DateTime.ParseExact with the
specific format the OP gave.

Hope this helps
Jay
 
Cor Ligthert said:
Exactly and therefore is CDate without a formatstring much better.
Click to expand...

No, it isn't. The OP wants to parse a date in a specific format (for
example date strings are read from a file). In this case,
'DateTime.ParseExact' is the way to go.
 
Jay,

I forgot, I find the globalization one of the big benefits from dotNet and
when you agree in this as usual with Herfried and not with me, than that is
your opinion.

It is than not needed to discuss that with me where you show me that the use
of globalization in dotNet is not the right way to go.

Cor
 
when the string is 19/10/2004 00:15:51 even ParseExact can't parse it.
the SQLServer convert does recognise the string format.
how come?
 
z. f. said:
when the string is 19/10/2004 00:15:51 even ParseExact can't parse it.
Click to expand...

ParseExact certainly *can* parse it - you just need to give it the
correct format:

using System;
using System.Globalization;

class Test
{
static void Main()
{
string format = "dd/MM/yyyy HH:mm:ss";
string s = "19/10/2004 00:15:51";

Console.WriteLine (DateTime.ParseExact
(s, format, CultureInfo.InvariantCulture));
}
}
 
ZF

Did you tried my sample as well, that work forever and therefore as well
with database formats.

I am not sure if the setting in Isreal for dates in arabian figures is in
the US style or let say the European style. When it is in Isreal the US
style and you want to convert a date from let say European style you can
use.

mydatarow(0)("mydatefield") = CDate("19/10/2004
00:15:51").ToString("dd-MM-yy hh:mm:ss")

I am curious about for that used datetimeformat in Isreal, from Internet I
get the idea US style, can you tell that?

I hope this helps?

Cor
 
the addition of the CultureInfo.InvariantCulture parameter and the HH
instead of hh in the format did the difference.
it's working.
can you share more about the meaning of the CultureInfo.InvariantCulture and
why it works with it and not with null/nothing parameter?

Thanks!
z.
 
z. f. said:
the addition of the CultureInfo.InvariantCulture parameter and the HH
instead of hh in the format did the difference.
Click to expand...

More the latter than the former.
it's working.
can you share more about the meaning of the CultureInfo.InvariantCulture and
why it works with it and not with null/nothing parameter?
Click to expand...

In fact, that's a red herring - I just like to use the invariant
culture when using ParseExact because I definitely don't want any
culture-sensitive processing. When using a custom format string like
you are there, I don't think it makes any odds though.
 
Cor said:
ZF

Did you tried my sample as well, that work forever and therefore as well
with database formats.

I am not sure if the setting in Isreal for dates in arabian figures is in
the US style or let say the European style. When it is in Isreal the US
style and you want to convert a date from let say European style you can
use.
Click to expand...

So why should he try your CDate solution, if he can use
ParseExact while specifying the *expected* format???

He *knows* how the DateTime string is formatted, but he
doesn't know (and doesn't have to know) the culture, so
ParseExact is his friend.

bye
Rob
 
Robert,

Thas does CDate as good without any problem.

So why should he try your CDate solution, if he can use
ParseExact while specifying the *expected* format???

He *knows* how the DateTime string is formatted, but he
doesn't know (and doesn't have to know) the culture, so
ParseExact is his friend.

bye
Click to expand...

That does CDate as well and even in one time, without knowing anything of
globalization settings. So I do not understand your message.

Maybe a lack of knowledge from you?

Cor
 
So why should he try your CDate solution, if he can use
That does CDate as well and even in one time, without knowing anything of
globalization settings. So I do not understand your message.

Maybe a lack of knowledge from you?
Click to expand...

LOL!

bye
Rob
 
Cor Ligthert said:
That does CDate as well and even in one time, without knowing anything of
globalization settings. So I do not understand your message.
Click to expand...

No, CDate uses regional settings. The OP knows that he wants the format
to be dd/MM/yyyy, not MM/dd/yyyy whatever culture he's in. Using CDate
would give the wrong results on, say, "06/05/2004" if the program was
running in the US.

When no regional settings should be used - when the format is fixed -
DateTime.ParseExact is the right thing to use.
 
Cor,
As we pointed out yesterday, CDate fails miserably! Please read & attempt to
understand the previous posts in this thread!

It may work for you as you are in a region that allows day month year,
however every one else it fails for!

CDate is region specific, ParseExact is not.

Hope this helps
Jay
 
z.
The "hh" in your original format string "dd/mm/yyyyy hh:mm:ss" indicates an
hour between 01 & 12, the "HH" in the Jon's format string "dd/MM/yyyy
HH:mm:ss" indicates hours between 00 & 24, Hence Jon's sample worked.

As Jon suggests the CultureInfo.InvariantCulture parameter is not necessary
in this case.

Const format As String = "dd/MM/yyyy HH:mm:ss"
Dim s As String = "19/10/2004 00:15:51"
Debug.WriteLine(DateTime.ParseExact(s, format, Nothing))


For details on custom datetime formats see:

http://msdn.microsoft.com/library/d...s/cpguide/html/cpcondatetimeformatstrings.asp

For information on formatting in .NET in general see:
http://msdn.microsoft.com/library/d...y/en-us/cpguide/html/cpconformattingtypes.asp

Hope this helps
Jay

z. f. said:
the addition of the CultureInfo.InvariantCulture parameter and the HH
instead of hh in the format did the difference.
it's working.
can you share more about the meaning of the CultureInfo.InvariantCulture
and
why it works with it and not with null/nothing parameter?

Thanks!
z.
Click to expand...
 
Jay B. Harlow said:
As we pointed out yesterday, CDate fails miserably! Please read & attempt to
understand the previous posts in this thread!

It may work for you as you are in a region that allows day month year,
however every one else it fails for!

CDate is region specific, ParseExact is not.
Click to expand...

Just to be precise, ParseExact *is* region specific in general, but not
with the specific format we've given. If you give it a culture-
sensitive format specifier (such as "d") I believe it'll be culture-
sensitive - hence the last parameter.
 
Jon,
Correct, it *can be* region specific. IMHO *Is* implies that is always is,
I hope you agree its not black & white, it depends on the format string
provided.

The point I am trying to get across is that ParseExact with a custom format
is not region specific, where as CDate (& DateTime.Parse most of the time)
is always region specific. In other words if you want a regional date
conversion use CDate or DateTime.Parse, if you want a regional agnostic date
conversion use DateTime.ParseExact with a custom format.

I realize that CultureInfo.InvariantCulture is somewhat of an agnostic
region and that you can pass it to DateTime.Parse to get an regional
agnostic date...

You are correct Standard formats are based on the format info passed, if you
pass Nothing for the format as I have it uses the "current culture".

Thanks for reminding me
Jay
 
Jay B. Harlow said:
Correct, it *can be* region specific. IMHO *Is* implies that is always is,
I hope you agree its not black & white, it depends on the format string
provided.

The point I am trying to get across is that ParseExact with a custom format
is not region specific, where as CDate (& DateTime.Parse most of the time)
is always region specific. In other words if you want a regional date
conversion use CDate or DateTime.Parse, if you want a regional agnostic date
conversion use DateTime.ParseExact with a custom format.
Click to expand...

Absolutely. I think we agree on what's going on. I just wanted to make
the point that DateTime.ParseExact shouldn't be regarded as an entirely
culture-insensitive method.
 
I have to say that my simple short solution does not work .

So it has to be with CDate when in Israel US settings are used
\\\
Thread.CurrentThread.CurrentCulture = New CultureInfo("FR-fr")
mydatarow("dtt") = CDate("19/10/2004 0:15:51")
Thread.CurrentThread.CurrentCulture = CultureInfo.InstalledUICulture
///

Cor
 
Cor Ligthert said:
I have to say that my simple short solution does not work .

So it has to be with CDate when in Israel US settings are used
\\\
Thread.CurrentThread.CurrentCulture = New CultureInfo("FR-fr")
mydatarow("dtt") = CDate("19/10/2004 0:15:51")
Thread.CurrentThread.CurrentCulture = CultureInfo.InstalledUICulture
///
Click to expand...

So you would rather change the culture of the current thread (and not
necessarily change it back to what it was before, I note) than use
ParseExact? It seems the long way round to me.
 
Back
Top