471,357 Members | 1,086 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,357 software developers and data experts.

DateTime.ParseExact format issue

Hi all,
Any idea why this code results in a FormatException?

DateTime.ParseExact("40708", "dMMyy", CultureInfo.CurrentCulture)
If I use "040708" with the same format string it works and it parses all
double digit days fine.

TIA

JB

-- Posted on news://freenews.netfront.net - Complaints to ne**@netfront.net --
Sep 1 '08 #1
5 5383
On Sun, 31 Aug 2008 22:01:56 -0700, John B <jb******@yahoo.comwrote:
Hi all,
Any idea why this code results in a FormatException?

DateTime.ParseExact("40708", "dMMyy", CultureInfo.CurrentCulture)
If I use "040708" with the same format string it works and it parses all
double digit days fine.
I don't know for sure. But it doesn't surprise me that much that it
doesn't work. The degree of analysis that would be required for the
parser to successfully figure deal with variable-length parameters is
non-trivial. The parser is probably trying to parse "40" as a day value
and of course failing.

Your specific example is simpler, but if it's to work, then the parser
would be required to handle all of the variable-length fields as well.
Suppose your format was "dMyy". How does the parser know the difference
between a valid string "41208" (where the day is "4" and the month is
"12") and an invalid string "41208" (where the day is "41" and the month
is "2")? You can't allow the parser to be lenient, because then bad data
could wind up parsed successfully without any indication of an error.

I think the lesson is that if you want to use ParseExact(), your format
string needs to be unambiguous about each character position, which means
the variable-length fields like "d" and "M" are just not a good idea.

Pete
Sep 1 '08 #2
Peter Duniho wrote:
On Sun, 31 Aug 2008 22:01:56 -0700, John B <jb******@yahoo.comwrote:
>Hi all,
Any idea why this code results in a FormatException?

DateTime.ParseExact("40708", "dMMyy", CultureInfo.CurrentCulture)
If I use "040708" with the same format string it works and it parses
all double digit days fine.

I don't know for sure. But it doesn't surprise me that much that it
doesn't work. The degree of analysis that would be required for the
parser to successfully figure deal with variable-length parameters is
non-trivial. The parser is probably trying to parse "40" as a day value
and of course failing.

Your specific example is simpler, but if it's to work, then the parser
would be required to handle all of the variable-length fields as well.
Suppose your format was "dMyy". How does the parser know the difference
between a valid string "41208" (where the day is "4" and the month is
"12") and an invalid string "41208" (where the day is "41" and the month
is "2")? You can't allow the parser to be lenient, because then bad
data could wind up parsed successfully without any indication of an error.

I think the lesson is that if you want to use ParseExact(), your format
string needs to be unambiguous about each character position, which
means the variable-length fields like "d" and "M" are just not a good idea.

Pete
Thanks for your thoughts Peter, you're correct in a way.
The problem is though that it's data taken out of MS Excel and therefore
any leading zero is stripped.

Cheers,

JB

-- Posted on news://freenews.netfront.net - Complaints to ne**@netfront.net --
Sep 1 '08 #3
On Sun, 31 Aug 2008 22:32:42 -0700, John B <jb******@yahoo.comwrote:
Thanks for your thoughts Peter, you're correct in a way.
The problem is though that it's data taken out of MS Excel and therefore
any leading zero is stripped.
The fact that the data comes from Excel doesn't change anything about what
I wrote. I'm not aware of any requirement that the .NET Framework provide
for built-in processing of data emitted by Excel.

You may well have to do some pre-processing of the data before parsing,
such as adding a leading '0' when the string length is less then 6.
Alternatively, depending on how much control you have over the Excel
worksheet that's providing the data, have Excel emit data that is better
suited to .NET's built-in parsing capabilities.

Pete
Sep 1 '08 #4
Peter Duniho wrote:
On Sun, 31 Aug 2008 22:32:42 -0700, John B <jb******@yahoo.comwrote:
>Thanks for your thoughts Peter, you're correct in a way.
The problem is though that it's data taken out of MS Excel and
therefore any leading zero is stripped.

The fact that the data comes from Excel doesn't change anything about
what I wrote. I'm not aware of any requirement that the .NET Framework
provide for built-in processing of data emitted by Excel.

You may well have to do some pre-processing of the data before parsing,
such as adding a leading '0' when the string length is less then 6.
Alternatively, depending on how much control you have over the Excel
worksheet that's providing the data, have Excel emit data that is better
suited to .NET's built-in parsing capabilities.

Pete
Thanks for your response.

JB

-- Posted on news://freenews.netfront.net - Complaints to ne**@netfront.net --
Sep 1 '08 #5
Peter Duniho wrote:
On Sun, 31 Aug 2008 22:32:42 -0700, John B <jb******@yahoo.comwrote:
>Thanks for your thoughts Peter, you're correct in a way.
The problem is though that it's data taken out of MS Excel and
therefore any leading zero is stripped.

The fact that the data comes from Excel doesn't change anything about
what I wrote. I'm not aware of any requirement that the .NET Framework
provide for built-in processing of data emitted by Excel.

You may well have to do some pre-processing of the data before parsing,
such as adding a leading '0' when the string length is less then 6.
It should be rather simple. Based on the description it is only
the first zero that disappears so replacing:

DateTime.ParseExact(s, "ddMMyy", CultureInfo.CurrentCulture)

with:

DateTime.ParseExact(s.PadLeft(6, '0'), "ddMMyy", CultureInfo.CurrentCulture)

should fix it.

Arne
Sep 7 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

15 posts views Thread by Dan S | last post: by
2 posts views Thread by Sterling Ledet | last post: by
4 posts views Thread by Hans Merkl | last post: by
38 posts views Thread by nobody | last post: by
26 posts views Thread by Reny J Joseph Thuthikattu | last post: by
11 posts views Thread by Cor Ligthert | last post: by
1 post views Thread by Erica | last post: by
11 posts views Thread by Peter Holschbach | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.