DateTime.ParseExact weird behavior

  • Thread starter Thread starter Nick Chakarov
  • Start date Start date
N

Nick Chakarov

Here is the problem I discovered resently. Any idea how to go around?

in order to repeat behaviour the date has to be between 1 and 9. No problem
with 2 digits date.
Let's assume it is June 6, 2006
string s = DateTime.Now.ToString("MMMdyyyyhhmmtt");
// now s looks like "Jun620061220PM"
// now trying to convert back the same string with the same format throws
exception

DateTime d = DateTime.ParseExact(s, "MMMdyyyyhhmmtt", whatever current
culture is ...)

does not make a lot of sense, does it? I mean if A=B that why B!=A
;)))))))))))))))))))))))
 
What exception is thrown?

Probably the problem is that you don't have any separator after the day
number, and as it can be either one or two digits it will read two
digits if there are two digits, and throw an exception as "62" is not a
valid day number.

Try with a date format that has a fixed number of digits: "MMMddyyyyhhmmtt".
 
Exception is "invalid format".
The problem is that I am receiving datetime in this format as a string that
I need to parse. But that is not the point.
The point is that the formatting string should work back and forth. This is
the point I am trying to make.
Try it for yourself ....
string s = DateTime.Now.ToString("MMMdyyyyhhmmtt");

System.Diagnostics.Debug.WriteLine(s);

DateTime d = DateTime.ParseExact(s,
"MMMdyyyyhhmmtt",System.Threading.Thread.CurrentThread.CurrentCulture);
 
nick said:
Exception is "invalid format".
The problem is that I am receiving datetime in this format as a
string that I need to parse. But that is not the point.
The point is that the formatting string should work back and forth.
This is the point I am trying to make.
Click to expand...

http://lab.msdn.microsoft.com/productfeedback

is where to make such points. I can easily undersstand why what you're
trying to do doesn't work, and I can easily understand why you'd want it to
work - I'd suggest reporting it as a bug. In the meantime, you'll have to
do something else - like break the string apart yourself.

-cd
 
No, it shouldn't work back and forth. You can't expect any date format
to be parsable.

If you for an example use the format "yMd", it could produce a string
that looks like this: "2006112". This is a string that is impossible to
parse as a date, as the date used to produce it could be either
2006-01-12 or 2006-11-02.

You should check the length of the string. If it contains 14 characters,
add a zero as the fourth character. Then you can use the
"MMMddyyyyhhmmtt" format to parse it.
 
Hehe ;)

That's exactly what I am doing, but it is workaround. I would have expected
more inteligent behavior from the parser in this particular case. For the
example you are giving ... I agree ... But for this particula case .. no
way ;)
 
Yes, if the parser would be a bit smarter, it would realize that there
is only one of the format specifiers that has a variable length, and
base the parsing around that specifier.

The problem is that there is probably hundreds of special cases where
some added logic would make the parser able to handle yet another situation.

If all those were implemented, the parse method would contain huge
amounts of code, and quite a few bugs. It would get pretty slow, and it
would be nearly impossible to predict how it would react in different
situations.
 
Back
Top