"Dave Gurnell" wrote:
>> (string->date "13/01/2010 " "~d/~m/~y ")
>> (string->date "13/01/10 " "~d/~m/~Y ")
>
> 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?

Or it is me using a modified version [1].

[1] <http://github.com/marcomaggi/nausicaa/blob/master/scheme/src/libraries/times-and-dates.sls>

> 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).

But  this  is  correct,  IMHO.   The purpose  of  ~Y,  as  I
understand it,  is exactly to get all  the informations from
the  string; while  ~y allows  us to  get  informations from
other context data.

> 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.

Having ~Y accept less than  4 digits is more general; it was
probably considered  a feature by the  original author.  The
documentation I have for ~Y is  just that it is a "year", it
does not specify that it  must read exactly 4 digits.  Maybe
it should,  or maybe it  should accept any number  of digits
(it  is my understanding  that year  12345 is  impossible to
read).

To have:

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

(date->string (string->date "01-01-01" "~y-~m-~d") "~Y")
=> "2001"

is correct IMHO, with the current implementation.

  In my reply I have written:

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

which  allows us  to detect  when more  than 2  digits where
given as a match for  ~y; with an end-of-string escape ~$ it
would have been:

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

saving us the append operation on the input string.

  In my reply I have written also:

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

and it is wrong, this is useless.

  In any  case any addition to  the SRFI should  spawn a new
SRFI;  but   the  document  states  that  it   is  fine  for
implementations to add new escape sequences, so you can just
go on adding whatever you need.

  This  SRFI  has  always  given  me the  feeling  of  being
somewhat unfinished;  maybe people should  have not ratified
it as it is... but let's not get into that. ;-)
--
Marco Maggi