[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: Wed, 10 Feb 2010 13:49:04 +0100
- Cc: Marco Maggi <mrc.mgg@xxxxxxxxx>, 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=gF4JAv5eM1PcyInpbvvh9lqmlwn6LTooB+A8KZgM6l8=; b=rQar7JEQy5ob72uxHd920EvsvpU4UDz5ZawzyhsRfOGj0FBbmaHBQa+mcugNtLSUYB FvX05GPfFq7CZC23vjCpbr4Ly3RIA1GRL30L2gRa+UBaFcLBCPLxeWarpxFls4DQ7f47 4Q7Ylx1bQ983AsLz83Ee1+uZsvCRxH4bbCk6M=
- 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=uZkhqep9bjbkAkhlKSBM9LIZLFlWMeNdQP7aVaadtjS73MEw5L0X4l5PtBL6C3/3i5 DBfh2Mhj+Gny6EXWmrxIzLlodWEnoUGbxLkFS36xyDOGZ7OIq8YOQyxR6RKwk3J7/6nW 3AaH/K7NRy0hHC1wUrbzl8ivVV23S4f0oqWiM=
- In-reply-to: marco@localhost message of "Wed\, 10 Feb 2010 10\:43\:17 +0000")
- Original-sender: marco@localhost
- References: <y9lpr4ejwbe.fsf@xxxxxxxxxxxxxxx> <87iqa6w4xm.fsf@xxxxxxxxxxxxx> <5FFF0B14-DC13-40A3-96A3-0D941E67B3F5@xxxxxxxxx>
"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 .
> 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
(date->string (string->date "01-01-01" "~Y-~m-~d") "~Y")
(date->string (string->date "01-01-01" "~y-~m-~d") "~Y")
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. ;-)