[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: ADDED: subversion/libsvn_subr getdate.y

From: Branko Čibej <brane_at_xbc.nu>
Date: 2001-07-05 11:08:20 CEST

Karl Fogel wrote:

>Branko �ibej <brane@xbc.nu> writes:
>>I think you may be taking the "supports all CVS features" promise a
>>bit too far here. By all means, let's support the features, but not
>>the misfeatures, please. When was the last time you told CVS to up -r
>>'last friday'?
>-1. I don't think Ben has taken CVS compatibility too far at all --
>this is the sort of CVS feature we should continue to support.
>I have done "last friday" type queries more than once before. I know
>that Brian Fitzpatrick also has, suspect others have also enjoyed the
Hum. I stand corrected. People will do the weirdest things. :-)

>>I don't think we should support any notation that's ambiguous. I'd
>>even say it's enough to support ISO 8601
>>http://ano2000.kpnqwest.pt/gen_8601.htm), including interval
>>notation. Things like "today" and "yesterday" are nice, but if we
>>support "last friday," we might as well know when "granny's birthday"
>+1 on the general principle you propose, we simply aren't reaching it
>in one step.
>Ideally, we would support nothing ambiguous. However, "last friday"
>is not ambiguous, whereas "xx/xx/xx" is. Now come on, "Granny's
>birthday" is not a fair example -- how is Subversion supposed to know
>who Granny is? :-)
O.K., how about "easter sunday" then? That's nice and deterministic. :-)

>As far as attaining the ideal goes, here is our situation right now:
> 1. Before Ben's change, we didn't have any date parsing at all.
> 2. After Ben's change, we have the date-parsing functionality that
> CVS has, which, though it certainly has its warts, is familiar
> to many people and does the right thing most of the time.
> 3. We do not currently have any code that satisfies the principle of
> supporting various unambiguous date formats, localizably.
>Granted that (3) is the ideal, I don't see why we should drop back to
>(1) just because (2) isn't absolute perfection. Let's support what we
>can right away, and feel free to improve it when we are able.
Could we at least remove support for ambiguous notations from the parser?

I'm inclined to agree with Greg Hudson: It's not a good idea to plan on
removing functionality.

Brane �ibej
    home:    <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:    <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
      ACM:   <brane_at_acm.org>            http://www.acm.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006

This is an archived mail posted to the Subversion Dev mailing list.