[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New year wildcard for string->date
- To: Dave Gurnell <d.j.gurnell@xxxxxxxxx>
- Subject: Re: New year wildcard for string->date
- From: Marco Maggi <mrc.mgg@xxxxxxxxx>
- Date: Tue, 09 Feb 2010 21:05:25 +0100
- Cc: srfi-19@xxxxxxxxxxxxxxxxx
- Delivered-to: srfi-19@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:original-sender:x-loop :x-mailer:in-reply-to:references:to:cc:subject:from:date:message-id :lines:mime-version:content-type; bh=1Ce2tvXaabbSsYDFqq8e4VH+i0L99NkunIq54XciBxg=; b=lMXKL/hS2oP6s/OT5il3ejKCy4iNKcUFimgCUT1hByW/Pao2ghFLW7idMMzfWqeIcp e8e0xa85hmI8QRpN/r7wgDcmKLtlMX3rQi3nGK355wLmnyK7mwaAhu2+uh68eIA9kAe/ Y3Kao2SE0sVmud8m383+YtgxpZsiRWaeU5UBI=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=original-sender:x-loop:x-mailer:in-reply-to:references:to:cc :subject:from:date:message-id:lines:mime-version:content-type; b=p04Tzbe5LUZhkFpFI4c+jApknDzu4ndURGX6aBvQ0SbTsreWfCUOVlVjUPpPYpyz/T ykemE1ZZCw7g09gt3u3U5nCq53hUJrI8o3xh41tb3qqMIz1+PswO8z7g3r4TzVGlY2k0 oGm65jyOmavOGSsOG60gueJCZJ4x8I6VE2XxA=
- In-reply-to: marco@localhost "Tue\, 09 Feb 2010 15\:52\:21 +0100")
- Original-sender: marco@localhost
- References: <y9lpr4ejwbe.fsf@xxxxxxxxxxxxxxx>
"Dave Gurnell" wrote:
> 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 "13/01/2010" "~d/~m/~y") ; => 13/01/2020 - incorrect
> (string->date "13/01/10" "~d/~m/~Y") ; => 13/01/0010 - incorrect
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.
The only clean alternative I see is to introduce an
end-of-string escape sequence, analogous to "$" for regexps.
--
Marco Maggi