in reply to Date String Parsing

You said:
The sparse documentation doesn't ... [explain] what it would do in the circumstance of '02/01/03'.
In the absence of more information about your intended usage, I wouldn't know what sort of advice to give. Are you processing text that has been collected "from the wild" and trying to identify/normalize all date references? (Very hard target with no complete solution -- some errors are inevitable.) Are you soliciting date strings from users via some sort of form submission and hoping to normalize their inputs? (Easily solved with appropriate design of the form.) Something else?

If a string like "02/03/04" is coming from who-knows-where, it is intrinsically ambiguous -- one can only hope that there is enough contextual information in the data surrounding it to allow a human to interpret it correctly (it might not even be a date). Asking for a perl script to get it right might be expecting too much.

Replies are listed 'Best First'.
Re^2: Date String Parsing
by Limbic~Region (Chancellor) on Nov 27, 2007 at 20:30 UTC
    graff,
    You are assuming that the code will not know how to handle that string and will fail. I am assuming it will use one of YY/MM/DD, YY/DD/MM, MM/YY/DD, MM/DD/YY, DD/MM/YY, DD/YY/MM and work. What I am asking for is that the documentation indicate which one, if any, is used. Additionally, in the cases of ambiguity, I want to be able to control which one is used.

    With regards to the data. The values are in a field designated as a date type so in fact I can be sure they are supposed to be dates. The automation need not be able to parse every string (throwing errors is fine) but when it does parse it - it should NEVER get it wrong.

    Cheers - L~R

[reply]

In Section Seekers of Perl Wisdom