DateTime.ParseExact format issue

[John B]

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 --

[Peter Duniho]

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

[John B]

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 --

[Peter Duniho]

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

[John B]

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 --

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

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