[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-07-04 19:07:42 CEST

Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:

> * Even ignoring the warnings you mentioned, the code isn't APRized,
> and I don't think it can be, if we keep generating the C file with
> yacc/byacc/bison.

APRized? It only makes system calls to <time.h>, which is part of the
ISO C library. Nothing un-portable going on.

> * Every one of these parser generators has its own quirks, and works
> a bit differently. Do we want to be tied to a particular version
> of a particular generator?

This parser comes from CVS, which compiles on every OS in the
universe, including my toaster. I'm sure they've fixed all the .y
portability problems. It probably compiles with every version of
bison and yacc that has ever existed.

> * The parser tries to recognize notations that are ambiguous, like
> the famous x/y/z: it'll parse that either as y/m/d or m/d/y, but
> what if, being from Europe, I write d/m/y? Or more likely, d.m.y,
> which isn't supported at all. On top of that, it doesn't support
> ISO 8601 format -- only the date notation.

It *does* support ISO 8601 date formats, as well as email dates (RFC
822). Look at this description from CVS:


Are you saying that it's leaving out a part of the ISO 8601 time
format? I have to go look it up...

> * Which brings up my last (but not least) objection: the parser is
> not localizable. L10n is more than just providing translations for
> messages.

Good point.

> I don't think we should support any notation that's ambiguous. I'd even
> say it's enough to support ISO 8601 [...]

I certainly wouldn't object if we told subversion users, "you must use
*only* this format to specify times".

But now subversion is exactly as good as CVS in this arena, which is
what we want for 1.0. Rewriting a date parser should probably become
a low-priority post-1.0 task, if anyone wants to bother.

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.