For the record, I disagree with all of your reasons.
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.
2. We don't support date formats that we _should_ support.
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.
+1 for changing the date parser before 1.0. We'll do ourselves and our
users a favour.
kfogel@collab.net wrote:
>This thread's been dormant for a bit, so I'm afraid to disturb it :-).
>
>However, eventually someone's going to file it as a 1.0 candidate
>change (probably after they have a patch ready), or move issue #408 to
>be a 1.0 candidate.
>
>So, this is an anticipatory post explaining why I hope we do *not*
>tackle this problem for 1.0.
>
>Reason 1: As much as we dislike our current date parser, it hasn't
> caused us many actual problems. It's not like we had a
> bunch of defects filed about date parsing, and then realized
> that we couldn't release 1.0 without fixing them. We have
> issue #408, sure, but that's "date parser rewrite", so it
> would be circular to view it as a justification in itself :-).
>
>Reason 2: Unlike some of the simple API fixes and whatnot we've been
> bandying about, this actually has the potential to cause
> bugs. It'd need a lot of review, and even then it's still
> possible for there to be subtle misparsings that don't get
> found until after 1.0.
>
>Reason 2: There are post-1.0 compatibility strategies that make this
> change less compelling. For one thing, any new parser we
> write is going to intersect with some of what the current
> parser supports. We can then look at current side of the
> non-intersecting area and see how important some of those
> formats really are. It's not outside the bounds of
> propriety to break dates used by ~20 people in the world (if
> we can determine that with reasonable certainty).
>
> But even if we don't want to lose *any* compatibility,
> there's still a strategy available. The current date parser
> is not known to misparse anything (right?) -- it simply
> doesn't parse everything we want it to, and is hard to
> maintain. If we write a new parser, it certainly wouldn't
> differently parse any string that is correctly parsed by the
> old code. So, we can just pass input to the old code first,
> then if it fails, we try the new code. That way we don't
> have to "maintain" the old code, so much as preserve it in
> stasis until the new code matches it in sophistication -- a
> process that can take as long as we're comfortable with,
> since there's no great penalty to keeping the old code
> around.
>
>For these reasons, I think it is unnecessary (and even a bit risky) to
>futz with our date parser before 1.0. Let's leave well enough alone.
>
>-Karl
>
>
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 22:57:32 2003