Dear SRFI 19ers,

I use string->date to parse dates in my user interfaces, and my users are always entering the year with the wrong number of digits.

string->date currently has two wildcards for years: "~y" accepts 2 digits and "~Y" accepts 4 digits. Unfortunately, each of these does the "wrong thing" if a user makes a mistake. Using PLT as an example:

#lang scheme

(require srfi/19)

(string->date "13/01/10" "~d/~m/~y") ; => 13/01/2010 - correct
(string->date "13/01/2010" "~d/~m/~y") ; => 13/01/2020 - incorrect

(string->date "13/01/10" "~d/~m/~Y") ; => 13/01/0010 - incorrect
(string->date "13/01/2010" "~d/~m/~Y") ; => 13/01/2010 - correct

It would be really cool to have a more robust option for parsing dates entered by users. I'm quite happy to produce a prototype and some test cases, but I'm not sure whether it's better to introduce a new wildcard or change the behaviour of one of the existing ones.

What do you think?

Best regards,

-- Dave