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

Re: RFC: date parser rewrite

From: <kfogel_at_collab.net>
Date: 2003-12-19 21:44:21 CET

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

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.


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:34:21 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.