Full disclosure, this is a problem I've recently encountered at work. I couldn't find a reasonable solution and ended up recommending a logistics approach rather than a full code approach to solve it. The code performs a subset of required functionality to give users more options, but doesn't account for all reported formats. If one of you manages to solve it then I'll likely contact you for permission to use the solution in production code. However, after spending quite a bit of time on this, I'm somewhat confident that it's an unsolvable problem due to ambiguity. Anyone who solves it will earn a lot of l33t points in my mind.
On to the challenge!
Users have a text box for date entry, and you have no control over this text box. The string must be converted to a DateTime object so that it's a valid date later in the process. However, users are allowed to type strings that are not parsable by the DateTime class. For example (using 01/01/2014):
There is no consistent range for valid years (noted because one of the cases practically requires verification of the year part).
The challenge is to write an interpreter that will take a valid date with any of the above formats and normalize it into a "MM/dd/yyyy" or "MM/dd/yy" format so that DateTime will parse the string correctly. For strictly ambiguous cases, note the assumption you've made, if any. For the purposes of education in this challenge, also note which cases you found to be ambiguous and why.
Extra credit for allowing strings that are already parsable and produce the correct interpretation after removing part separators. Don't assume that users won't type something like "1/1/14" or "01/01/2014".
There's no need to ensure the date itself is valid, DateTime will handle that when parsing. However, you may find that you need to do some validation to ensure a correct interpretation (I certainly did).
Be sure to show your work. And by that I mean test scaffolding that ensures all cases are tested and produce the desired result.
Edited 2 Years Ago by deceptikon