By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,905 Members | 1,630 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,905 IT Pros & Developers. It's quick & easy.

parsing date string

P: n/a
HI,
i have string in format
dd/mm/yyyyy hh:mm:ss
and giving this as an input to DateTime.Parse gives a string was not
recognized as a valid date time format string error.
how do i make the parse method to accept formating that i need.
if i do console.writeLine DateTime.Now.ToString it gives the format:
YYYY-MM-DD HH:MM:SS

TIA, Z.
Nov 21 '05 #1
Share this Question
Share on Google+
50 Replies


P: n/a
Did you try DateTime.ParseExact()?

"z. f." <zi**@info-scopeREMSPAM.co.il> wrote in message
news:uW**************@TK2MSFTNGP10.phx.gbl...
HI,
i have string in format
dd/mm/yyyyy hh:mm:ss
and giving this as an input to DateTime.Parse gives a string was not
recognized as a valid date time format string error.
how do i make the parse method to accept formating that i need.
if i do console.writeLine DateTime.Now.ToString it gives the format:
YYYY-MM-DD HH:MM:SS

TIA, Z.

Nov 21 '05 #2

P: n/a
ZF

dim mydate as DateTime = CDate(mydatestring)

I hope this helps

Cor
Nov 21 '05 #3

P: n/a
isn't there a simple function that can accept the format i'm using
(dd/mm/yyyy )
i saw in MSDN some complex objects for managing the culture and format but
didnn't see a simple way to parse using a format like sql convert function
allows.
i hope somene posts here a sample of parsing date and stating which format
to use.

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uF**************@TK2MSFTNGP10.phx.gbl...
ZF

dim mydate as DateTime = CDate(mydatestring)

I hope this helps

Cor

Nov 21 '05 #4

P: n/a
"z. f." <zi**@info-scopeREMSPAM.co.il> schrieb:
i have string in format
dd/mm/yyyyy hh:mm:ss
and giving this as an input to DateTime.Parse gives a string was not
recognized as a valid date time format string error.
how do i make the parse method to accept formating that i need.
if i do console.writeLine DateTime.Now.ToString it gives the format:
YYYY-MM-DD HH:MM:SS


Take a look at 'DateTime.ParseExact'. There you can specify the format of
the date you want to parse. Notice that your format string is invalid.

Date and Time Format Strings
<URL:http://msdn.microsoft.com/library/en-us/cpguide/html/cpconDateTimeFormatStrings.asp>

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 21 '05 #5

P: n/a
I thought I showed you that what you want more simple?

Cor
isn't there a simple function that can accept the format i'm using
dim mydate as DateTime = CDate(mydatestring)

Nov 21 '05 #6

P: n/a
>> dd/mm/yyyyy hh:mm:ss

Where in Austria, here in Holland goes this very well?

MessageBox.Show(CDate("18/10/2004 15:40:00").ToString())

I am really curious what time system they use in Austria?

Cor
Nov 21 '05 #7

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb:
dd/mm/yyyyy hh:mm:ss

Where in Austria, here in Holland goes this very well?


There is a difference between "mm" and "MM"...
MessageBox.Show(CDate("18/10/2004 15:40:00").ToString())

I am really curious what time system they use in Austria?


It works in Austria, but not in the US:

\\\
System.Threading.Thread.CurrentThread.CurrentCultu re = _
New System.Globalization.CultureInfo("en-US")
MessageBox.Show(CDate("18/10/2004 15:40:00").ToString())
///

.... throws an 'InvalidCastException'.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #8

P: n/a
Herfried,

It works in Austria, but not in the US:


I am glad that you tell me that, you could not know that I knew that
already.

However z.f. is has a mail extention IL so probably he is from Isreal, I do
not know those settings, however I find it again clever from you that you
even knows those culture settings exactly.

:-)))

Cor.

Nov 21 '05 #9

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb:
However z.f. is has a mail extention IL so probably he is from Isreal, I
do not know those settings, however I find it again clever from you that
you even knows those culture settings exactly.


That's the reason why I prefer 'ParseExact' -- it doesn't require specific
culture settings...

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 21 '05 #10

P: n/a
> That's the reason why I prefer 'ParseExact' -- it doesn't require specific
culture settings...

You will say that with ParseExact it is forever working whatever
culturesettings your computer has?

So when somebody uses the program in the US and types in 01-11-2004 and
somebody uses it in Austria 11-01-2004 the computer knows with your sample
exactly that it has to be the 11th of november 2004.

Strange I thought that for that you needed CDate.

But when you say that this is working everywhere on the earth who am I that
I will not believe you.

Cor
Nov 21 '05 #11

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb:
That's the reason why I prefer 'ParseExact' -- it doesn't require
specific culture settings...

You will say that with ParseExact it is forever working whatever
culturesettings your computer has?

So when somebody uses the program in the US and types in 01-11-2004 and
somebody uses it in Austria 11-01-2004 the computer knows with your sample
exactly that it has to be the 11th of november 2004.

Strange I thought that for that you needed CDate.

But when you say that this is working everywhere on the earth who am I
that I will not believe you.


Yes, it will work on every machine that supports the .NET Framework, if you
specify the date format in 'ParseExact' correctly.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 21 '05 #12

P: n/a
Yes, it will work on every machine that supports the .NET Framework, if
you
specify the date format in 'ParseExact' correctly.

Can you give me an example that will work in the same program in the US and
Austria.

Because I become completly confused about this, maybe is it to difficult for
me and will a little sample make it more clear for me.

Cor
Nov 21 '05 #13

P: n/a
>>>
Can you give me an example that will work in the same
program in the US and Austria.


\\\
MsgBox( _
Date.ParseExact( _
"01-11-2000", _
"dd-MM-yyyy", _
Nothing _
).ToString() _
)
///

Does that give the right date in the US notation, I thought you wrote it was
something else in this thread, this is the Dutch notation. However much
shorter with CDate.

:-))))))
Cor
Nov 21 '05 #14

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb:
Can you give me an example that will work in the same
program in the US and Austria.


\\\
MsgBox( _
Date.ParseExact( _
"01-11-2000", _
"dd-MM-yyyy", _
Nothing _
).ToString() _
)
///

Does that give the right date in the US notation, I thought
you wrote it was something else in this thread, this is the
Dutch notation. However much shorter with CDate.


?!?

There are systems that do not use Dutch as system culture...

:-)))

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #15

P: n/a
After everything I have read, the real problem or difference rather is not
that the code works in one place and does not in the other, the thing is the
regional settings of windows. as long as that is set to the date format
required everything should work, the thing is that in the US the normal date
format is mm/dd/yyyy while in a lot of other places here included its
dd/mm/yyyy.
Nov 21 '05 #16

P: n/a
Cor,
The point is that ParseExact parses the date exactly in the format given,
CDate & DateTime.Parse parse the date based on the current region/local...

To better see what is happening use DateTime.ToLongDateString instead of
DateTime.ToString:

Const s1 As String = "01-11-2000"
Const s2 As String = "11-01-2000"

Const mdy As String = "MM-dd-yyyy"
Const dmy As String = "dd-MM-yyyy"

Debug.WriteLine(Date.ParseExact(s1, mdy,
Nothing).ToLongDateString(), "s1 mdy")
Debug.WriteLine(Date.ParseExact(s1, dmy,
Nothing).ToLongDateString(), "s1 dmy")
Debug.WriteLine(Date.ParseExact(s2, mdy,
Nothing).ToLongDateString(), "s2 mdy")
Debug.WriteLine(Date.ParseExact(s2, dmy,
Nothing).ToLongDateString(), "s2 dmy")

Hope this helps
Jay
"Cor Ligthert" <no************@planet.nl> wrote in message
news:OJ***************@TK2MSFTNGP15.phx.gbl...

Can you give me an example that will work in the same
program in the US and Austria.


\\\
MsgBox( _
Date.ParseExact( _
"01-11-2000", _
"dd-MM-yyyy", _
Nothing _
).ToString() _
)
///

Does that give the right date in the US notation, I thought you wrote it
was something else in this thread, this is the Dutch notation. However
much shorter with CDate.

:-))))))
Cor

Nov 21 '05 #17

P: n/a
Jay,

I know that however I try to tell everytime "use the globalization and do
not use fixed dateformatstrings for the right date" and Herfried comes
everytime with those fixed date setting.

Therefore my messages about this.

Cor
Nov 21 '05 #18

P: n/a
Alvaro,

I know that very well, this thread has a predecessor at the end I showed
this to Herfried, when it was really needed in a non US Anglo Canadian
setting to use such a date in another culture.

\\\
Public Class Example
Public Shared Sub Main()
Threading.Thread.CurrentThread.CurrentCulture = _
New Globalization.CultureInfo("en-US")
Dim mydate As DateTime = CDate("10/16/2004")
Threading.Thread.CurrentThread.CurrentCulture = _
Globalization.CultureInfo.InstalledUICulture
MessageBox.Show(mydate.ToString)
End Sub
End Class
//

This is crazy code, however it was to show how many possibilities there are
with globalization setting to do it better.

And than Herfrieds answer was.
Well, this should work, and that's what I missed in your post, but I think
that 'DateTime.ParseExact' is much faster to type...


So therefore this long thread to get the change when he had given a complete
answer (what he did not) to write

"This goes much shorter with CDate".

:-)

Cor
Nov 21 '05 #19

P: n/a
>
There are systems that do not use Dutch as system culture...

:-)))

Exactly and therefore is CDate without a formatstring much better.

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

Cor
Nov 21 '05 #20

P: n/a
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" <no************@planet.nl> wrote in message
news:O$**************@TK2MSFTNGP12.phx.gbl...
Jay,

I know that however I try to tell everytime "use the globalization and do
not use fixed dateformatstrings for the right date" and Herfried comes
everytime with those fixed date setting.

Therefore my messages about this.

Cor

Nov 21 '05 #21

P: n/a
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
Nov 21 '05 #22

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb:
There are systems that do not use Dutch as system culture...

Exactly and therefore is CDate without a formatstring much better.


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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 21 '05 #23

P: n/a
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?
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Cor,
The point is that ParseExact parses the date exactly in the format given,
CDate & DateTime.Parse parse the date based on the current region/local...

To better see what is happening use DateTime.ToLongDateString instead of
DateTime.ToString:

Const s1 As String = "01-11-2000"
Const s2 As String = "11-01-2000"

Const mdy As String = "MM-dd-yyyy"
Const dmy As String = "dd-MM-yyyy"

Debug.WriteLine(Date.ParseExact(s1, mdy,
Nothing).ToLongDateString(), "s1 mdy")
Debug.WriteLine(Date.ParseExact(s1, dmy,
Nothing).ToLongDateString(), "s1 dmy")
Debug.WriteLine(Date.ParseExact(s2, mdy,
Nothing).ToLongDateString(), "s2 mdy")
Debug.WriteLine(Date.ParseExact(s2, dmy,
Nothing).ToLongDateString(), "s2 dmy")

Hope this helps
Jay
"Cor Ligthert" <no************@planet.nl> wrote in message
news:OJ***************@TK2MSFTNGP15.phx.gbl...
>
Can you give me an example that will work in the same
program in the US and Austria.

\\\
MsgBox( _
Date.ParseExact( _
"01-11-2000", _
"dd-MM-yyyy", _
Nothing _
).ToString() _
)
///

Does that give the right date in the US notation, I thought you wrote it
was something else in this thread, this is the Dutch notation. However
much shorter with CDate.

:-))))))
Cor


Nov 21 '05 #24

P: n/a
z. f. <zi**@info-scopeREMSPAM.co.il> wrote:
when the string is 19/10/2004 00:15:51 even ParseExact can't parse it.


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));
}
}

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #25

P: n/a
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

"z. f." <zi**@info-scopeREMSPAM.co.il>
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?
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Cor,
The point is that ParseExact parses the date exactly in the format given,
CDate & DateTime.Parse parse the date based on the current
region/local...

To better see what is happening use DateTime.ToLongDateString instead of
DateTime.ToString:

Const s1 As String = "01-11-2000"
Const s2 As String = "11-01-2000"

Const mdy As String = "MM-dd-yyyy"
Const dmy As String = "dd-MM-yyyy"

Debug.WriteLine(Date.ParseExact(s1, mdy,
Nothing).ToLongDateString(), "s1 mdy")
Debug.WriteLine(Date.ParseExact(s1, dmy,
Nothing).ToLongDateString(), "s1 dmy")
Debug.WriteLine(Date.ParseExact(s2, mdy,
Nothing).ToLongDateString(), "s2 mdy")
Debug.WriteLine(Date.ParseExact(s2, dmy,
Nothing).ToLongDateString(), "s2 dmy")

Hope this helps
Jay
"Cor Ligthert" <no************@planet.nl> wrote in message
news:OJ***************@TK2MSFTNGP15.phx.gbl...
>>>>
>>> Can you give me an example that will work in the same
>>> program in the US and Austria.
>>
>> \\\
>> MsgBox( _
>> Date.ParseExact( _
>> "01-11-2000", _
>> "dd-MM-yyyy", _
>> Nothing _
>> ).ToString() _
>> )
>> ///
>>
> Does that give the right date in the US notation, I thought you wrote
> it
> was something else in this thread, this is the Dutch notation. However
> much shorter with CDate.
>
> :-))))))
>
>
> Cor
>



Nov 21 '05 #26

P: n/a
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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
z. f. <zi**@info-scopeREMSPAM.co.il> wrote:
when the string is 19/10/2004 00:15:51 even ParseExact can't parse it.


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));
}
}

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 21 '05 #27

P: n/a
z. f. <zi**@info-scopeREMSPAM.co.il> wrote:
the addition of the CultureInfo.InvariantCulture parameter and the HH
instead of hh in the format did the difference.
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?


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #28

P: n/a
Cor Ligthert wrote:
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.


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
Nov 21 '05 #29

P: n/a
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


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
Nov 21 '05 #30

P: n/a
>>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

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?


LOL!

bye
Rob
Nov 21 '05 #31

P: n/a
Cor Ligthert <no************@planet.nl> wrote:
That does CDate as well and even in one time, without knowing anything of
globalization settings. So I do not understand your message.


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #32

P: n/a
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


"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
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

"z. f." <zi**@info-scopeREMSPAM.co.il>
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?
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Cor,
The point is that ParseExact parses the date exactly in the format
given,
CDate & DateTime.Parse parse the date based on the current
region/local...

To better see what is happening use DateTime.ToLongDateString instead of
DateTime.ToString:

Const s1 As String = "01-11-2000"
Const s2 As String = "11-01-2000"

Const mdy As String = "MM-dd-yyyy"
Const dmy As String = "dd-MM-yyyy"

Debug.WriteLine(Date.ParseExact(s1, mdy,
Nothing).ToLongDateString(), "s1 mdy")
Debug.WriteLine(Date.ParseExact(s1, dmy,
Nothing).ToLongDateString(), "s1 dmy")
Debug.WriteLine(Date.ParseExact(s2, mdy,
Nothing).ToLongDateString(), "s2 mdy")
Debug.WriteLine(Date.ParseExact(s2, dmy,
Nothing).ToLongDateString(), "s2 dmy")

Hope this helps
Jay
"Cor Ligthert" <no************@planet.nl> wrote in message
news:OJ***************@TK2MSFTNGP15.phx.gbl...
>>>>
>>> Can you give me an example that will work in the same
>>> program in the US and Austria.
>>
>> \\\
>> MsgBox( _
>> Date.ParseExact( _
>> "01-11-2000", _
>> "dd-MM-yyyy", _
>> Nothing _
>> ).ToString() _
>> )
>> ///
>>
> Does that give the right date in the US notation, I thought you wrote
> it
> was something else in this thread, this is the Dutch notation.
> However
> much shorter with CDate.
>
> :-))))))
>
>
> Cor
>



Nov 21 '05 #33

P: n/a
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/de...matstrings.asp

For information on formatting in .NET in general see:
http://msdn.microsoft.com/library/de...ttingtypes.asp

Hope this helps
Jay

"z. f." <zi**@info-scopeREMSPAM.co.il> wrote in message
news:uB**************@TK2MSFTNGP10.phx.gbl...
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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
z. f. <zi**@info-scopeREMSPAM.co.il> wrote:
> when the string is 19/10/2004 00:15:51 even ParseExact can't parse it.


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));
}
}

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too


Nov 21 '05 #34

P: n/a
Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> wrote:
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.


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 Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #35

P: n/a
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


"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> wrote:
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.


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 Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 21 '05 #36

P: n/a
Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> wrote:
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.


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #37

P: n/a
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
Nov 21 '05 #38

P: n/a
Cor Ligthert <no************@planet.nl> wrote:
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
///


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #39

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb:
Thas does CDate as good without any problem.


It doesn't.
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.


That does CDate as well and even in one time, without knowing anything of
globalization settings.


That's wrong.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 21 '05 #40

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb:
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
///


In addition to the other replies: Why play around with cultures, if the OP
wants to solve a culture-invariant problem?

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 21 '05 #41

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:
I just wanted to make the point that DateTime.ParseExact
shouldn't be regarded as an entirely culture-insensitive method.


ACK. That's what the documentation on this method says too...

:-)

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #42

P: n/a
Herfried,
That does CDate as well and even in one time, without knowing anything of
globalization settings.


That's wrong.

Did you read that in my message, I have told that already 2 hours ago.

Cor
Nov 21 '05 #43

P: n/a
.....But lets take a look at exactly HOW CDate works under the hood.

The CDate keyword ends up compiling into this (I'll translate it into VB):

Public Shared Function CDate(value as String) as DateTime

Return
Microsoft.VisualBasic.CompilerServices.DateType.Fr omString(value,
Thread.CurrentThread.CurrentCulture)

End Function

(Yeah, I know.... DateType.FromString implementation ends up delegating the
actual parsing to the DateTime.Parse(string, provider, styles) method. The
important thing here is where the culture information is derived)

So, if I'm writing a web application where the aspnet process, on my US
computer is parsing a string date that a person in another culture entered,
CDate would parse that text using the executing thread's culture
settings...which might be bad, so doing a ParseExact, using the client's
culture settings would be appropriate in that case.

"Cor Ligthert" wrote:
ZF

dim mydate as DateTime = CDate(mydatestring)

I hope this helps

Cor

Nov 21 '05 #44

P: n/a
David,

See my sample what I made today and is in the top of the thread, your
example is exactly why I think setting the culturesetting is better.

While I started for this thread with the idea that it was not needed because
it is Isreal which culture is very much binded with Europe (For world sport
and cultural organisations is Isreal the same as Turkey and Russia a part of
Europe while the biggest part and Isreal complete of those countries are in
Asia).

The problem could be that I was wrong in that idea, therefore I asked the OP
for that.

In the first situation he was needing to set the right culture datetime
setting from his system.

In the second situation that datetime.parseexact with globalization setting
or whatever way to convert however not only the Cdate, in what I made a
stuppid mistake.

Cor



Cor
"David Jessee" <David Je****@discussions.microsoft.com> schreef in bericht
news:EB**********************************@microsof t.com...
....But lets take a look at exactly HOW CDate works under the hood.

The CDate keyword ends up compiling into this (I'll translate it into VB):

Public Shared Function CDate(value as String) as DateTime

Return
Microsoft.VisualBasic.CompilerServices.DateType.Fr omString(value,
Thread.CurrentThread.CurrentCulture)

End Function

(Yeah, I know.... DateType.FromString implementation ends up delegating
the
actual parsing to the DateTime.Parse(string, provider, styles) method.
The
important thing here is where the culture information is derived)

So, if I'm writing a web application where the aspnet process, on my US
computer is parsing a string date that a person in another culture
entered,
CDate would parse that text using the executing thread's culture
settings...which might be bad, so doing a ParseExact, using the client's
culture settings would be appropriate in that case.

"Cor Ligthert" wrote:
ZF

dim mydate as DateTime = CDate(mydatestring)

I hope this helps

Cor

Nov 21 '05 #45

P: n/a
Correction, Top of the newsgroup microsoft.public.dotnet.languages.vb
Nov 21 '05 #46

P: n/a
Have you tried the following? It works great.

DateTime.Today.ToString("MM/dd/yyyy hh:mm:ss");

Thanks
Nital

"Herfried K. Wagner [MVP]" wrote:
"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:
I just wanted to make the point that DateTime.ParseExact
shouldn't be regarded as an entirely culture-insensitive method.


ACK. That's what the documentation on this method says too...

:-)

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

Nov 21 '05 #47

P: n/a
Nital <Ni***@discussions.microsoft.com> wrote:
Have you tried the following? It works great.

DateTime.Today.ToString("MM/dd/yyyy hh:mm:ss");


That converts from a DateTime to a string, rather than the other way
round. (It also has the month and day the wrong way round as far as the
OP's original format is concerned, and doesn't use 24 hour format for
the hours.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #48

P: n/a
Hi
Try to use system.globalization (IFormatter) to suite your date string format.
I had the same problem with yyyy/mm/dd string which is in Japnese format.
I used the IFormatter to set the locale and then my strig was recognized in
the Convert.DateString(String) function.
Let me know if this works
"z. f." wrote:
HI,
i have string in format
dd/mm/yyyyy hh:mm:ss
and giving this as an input to DateTime.Parse gives a string was not
recognized as a valid date time format string error.
how do i make the parse method to accept formating that i need.
if i do console.writeLine DateTime.Now.ToString it gives the format:
YYYY-MM-DD HH:MM:SS

TIA, Z.

Nov 21 '05 #49

P: n/a
HI,

I also had a problem with datetime. Searched a lot on the net. Read through
a lot of articles. But, none was of any help.

At Last i found an MSDN article which explains the datetime class. it solved
my problem. its a very good article.

The link of this article is
http://msdn.microsoft.com/netframewo...ndTimeFAQ.aspx.

After going through the article i found that the best way is the following :

Date.Today.ToString( System.Globalization.CultureInfo.InvariantCulture )

Hope it solves all of your problems and help you in understanding the
DateTime class.
Nov 21 '05 #50

50 Replies

This discussion thread is closed

Replies have been disabled for this discussion.