Re: New year wildcard for string->date

Hi Marco,

Thanks very much for your email. Responses below:

Marco Maggi wrote:

If I am not mistaken, this specific cases can be fixed doing:

(string->date "13/01/2010 " "~d/~m/~y ")
(string->date "13/01/10 " "~d/~m/~Y ")

that is: appending a white space to both the strings, which
force the termination of the escape sequence match. It is
not much beautiful but it is ready now.

In the latest PLT, the first of these gives an error and the second gives the year 0010. I guess this means we're missing a patch from the reference implementation?

I'll test things out with the reference implementation to be sure. I'm out in meetings all today and tomorrow but I'll have a go on Friday and see what happens.

The only clean alternative I see is to introduce an end-of-string escape sequence, analogous to "$" for regexps.

Could you explain that further? I'm probably just not seeing it, but I'm not sure how that would help. The behaviour is the same when the year is not at the end of the date string:

(date->string (string->date "01-01-01" "~Y-~m-~d") "~Y-~m-~d") ; ==> "0001-01-01"

In summary, my problem is that the parsing of ~y and ~Y is inconsistent:

~y raises an error on 1 digit, and expands 2 digits to 4 using tm:natural-year (which guesses the century based on the current year);

~Y pads to 4 digits using zeroes (not tm:natural-year).

My view is that the expansion of a <4 digit year using ~Y should either raise an error or use tm:natural-year to infer the century. The critical case is two digits, as users routinely make the mistake of entering fewer digits than requested.

I understand that changing the behaviour of an existing year wildcard is a dangerous proposition. A new wildcard (or another means of getting a more natural expansion) would be equally great.

Best regards,

-- Dave