Dropping users list, this has already been discussed.
On Tue, 2005-07-05 at 14:19 -0500, kfogel@collab.net wrote:
> Christopher Ness <chris@nesser.org> writes:
> > > Is this stricter-than-ANSI parsing intentional?
> >
> > I believe it is.
> > As for why, I'm not sure - but have some opinions.
> >
> > Maybe Branko Cibej, Karl Fogel, or Philip Martin will have something to
> > say about it.
> >
> > The issue tracker logs this back to 2001:
> > http://subversion.tigris.org/issues/show_bug.cgi?id=408
>
> I don't have the mail thread handy, but what happened is that we
> decided it was better to start out conservative, and then *add* date
> formats as they were needed, than to start out parsing a huge range of
> date formats -- not all of which we even knew! -- and then have to
> support all of them, complete with bugs if any, forever and ever.
>
> So, we can add support for new date formats as we like. Is a
> particular new format being proposed here?
No, not yet. This patch adds the ability to accept -r{2005-7-1}
I didn't read up on the date ISO standard but would assume this is a
valid ISO date without the leading zeros.
There was talk of relative dates like -r{-14d} aka 2 weeks or -r{-2M}
perhaps capitol 'M' for months and lowercase 'm' for minutes leaving 'h'
for hours and 'y' for years. The only letter with a dependency on case
is 'm'.
I like the idea of a {(Quantity)(Unit)} pattern. The negative sign
could be removed, since you could never go into the future but I think
it is a good signal for a relative date.
Another question I have is where is the best place to document the date
standards and formats for online help?
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
18:44:16 up 32 min, 2 users, load average: 0.17, 0.07, 0.09
Received on Wed Jul 6 01:35:36 2005