views:

280

answers:

4

I am curious what would be the best way to handle an ambiguous date string in any given language. When pre-validating your user input isn't an option, how should MM/dd/YYYY dates be parsed?

How would you parse the following ambiguous date and for what reason (statistical, cultural, etc)?

'1111900' as Jan 11, 1900 [M/dd/YYYY] or Nov 1, 1900 [MM/d/YYYY]?

+1  A: 

Unless you know exactly what the language/culture the format is coming from, you need to establish a common date format.

There is something called locale-neutral date format that I would recommend. (YYYY-MM-DD)

It's either use that or be clear as to what part is the year, month and day. (DD MON YYYY or 22 Apr 2003)

See: the w3's view on date formatting.

Edit: mistyped the locale-neutral date format

Nathan
why not YYYY-MM-DD as per the recommendation?
Jimmy
YYYY-MM-DD can also be easily sorted.
Gumbo
@Jimmy- mistype. fixed now.
Nathan
A: 

Depending on how important the software is, I would treat any ambiguous date entry as invalid input. You should be ensuring (at the source) that the date input you get is in a sensible, non-ambiguous format. If you still manage to get something like "1111900" then the input is not correct, someone has obviously bypassed the validity checking code somehow, and probably the most correct thing you can do is to discard the data.

Of course, if this isn't an option and getting the date spot on isn't critical, you could always guess - but it will be a guess. I would definitely avoid this if possible though. Accepting unsanitised input is not the best idea in general.

Andrzej Doyle
A: 

The only way to know the difference between Jan 11 and Nov 1 in such a system would be through context. Otherwise, you need to go through some sort of disambiguation. That particular date format would be a perfect example of pathologically destructive compression.

Jekke
A: 

My preference when the date in important is use offer drop-downs or a calendar that way it always comes in the expected format.

Unkwntech