Re: RFC: date parser rewrite

Branko Čibej <brane@xbc.nu> writes:
> 1. The current situation is intolerable. We nominally support date
> formats that don't warrant that name. Whatever we do to change
> that, we'll be yanking suppor for at least some of those date
> formats, and doing that after 1.0 (after we've known about this
> problem for ages) is a bad move.

I have an existence proof that the current situation is not
intolerable: we've tolerated it for years :-).

> 2. We don't support date formats that we _should_ support.

Okay. (Elsewhere in this thread there's a canonical list of those, I
think.)

> 3. Going with a limited set of supported date formats, like MBK
> suggests, isn't going to cause that many problems. The parsing
> code is a simple function that can be tested to death very easily.

The "isn't going to cause that many problems" is an assertion about
the correctness of an implementation that we don't even *have* yet,
and which when we do have it, will be far less tested than the current
date parser.

> +1 for changing the date parser before 1.0. We'll do ourselves and our
> users a favour.

I'd say it's early to +1 until there's an actual patch to evaluate! :-)

I'm not vetoing, just discussing, but so far these reasons doesn't
seem very compelling to me.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 23:07:47 2003