At the moment there's no way of reliably parsing years from human input using
string->date in SRFI 19. The programmer can use one of two wild cards, ~Y or
~y, to parse 4- or 2-digit years respectively:
(date->string (string->date "2010-03-02" "~Y-~m-~d") "~Y-~m-~d") ; ==>
"2010-03-02" - correct
(date->string (string->date "10-03-02" "~y-~m-~d") "~Y-~m-~d") ; ==>
"2010-03-02" - correct
However, if the user mistakenly enters the date in the opposite format, we get
badness:
(date->string (string->date "2010-03-02" "~y-~m-~d") "~Y-~m-~d") ; ==>
error (bad format)
(date->string (string->date "10-03-02" "~Y-~m-~d") "~Y-~m-~d") ; ==>
"0010-03-02" - "incorrect" century
This isn't really a bug in SRFI 19, but it is annoying in that it's impossible
to read date information in either format in a single call to string->date.
I discussed this with Marco Maggi in his capacity as a SRFI 19 maintainer. His
opinion was that, while any direct change to the SRFI should spawn another
SRFI, SRFI 19 states that allows implementations to add their own wildcards to
the standard set.
What are peoples' opinions on adding a PLT-specific wildcard to parse two or
four digit years? I'm more than happy to do the leg work if people think it's a
good idea. Otherwise I'll add something to Unlib to do the ~y case followed by
the ~Y case.
Cheers,
-- Dave
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
