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

Re: [PATCH]: Re: Date processing should be more flexible

From: Christopher Ness <chris_at_nesser.org>
Date: 2005-07-05 17:01:45 CEST

On Tue, 2005-07-05 at 08:14 +0200, Norbert Unterberg wrote:
> 2005/7/5, Christer J. Nyfält <christer.nyfalt@welho.com>:
>
> > /* Range validation, allowing for leap seconds */
> > if (expt.tm_mon < 0 || expt.tm_mon > 11
> > || expt.tm_mday > valid_days_by_month[expt.tm_mon]
> > + || expt.tm_mday <= 0
> ...
>
> Your are stricter than ANSI-C in your date validation. The ANSI-C
> function mktime() normalizes the date/time values in a meaningful
> manner before using the fields, so a January 32 is nicely converted
> into a February 1 (the apr_time_exp_gmt_get function seems to do the
> same). This which can be quite nice when you calculate dates from a
> script ("tomorrow" is just the "day of today+1", no need to check the
> overflow).

Others on the user list talked about relative dates as well.

The old Bison parser allowed for this (same as CVS apparently) but my
search on the tracker didn't really give a good reason why the change
took place in r8327 other than to remove a dependency on Bison and Flex.

> Is this stricter-than-ANSI parsing intentional?

I believe it is.
As for why, I'm not sure - but have some opinions.
  
Maybe Branko Cibej, Karl Fogel, or Philip Martin will have something to
say about it.

The issue tracker logs this back to 2001:
http://subversion.tigris.org/issues/show_bug.cgi?id=408

Cheers,
Chris

-- 
Wireless Group,
McMaster University
finger.localdomain
10:14:37 up 12 min, 1 user, load average: 0.02, 0.08, 0.08
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 5 17:38:43 2005

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

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