Re: RFC: date parser rewrite

mark benedetto king wrote:
> The exiting bison-based date-parser suffers from several deficiencies,
> among which are the following:

Basically I agree with your proposal for change, but I offer some clarifications and suggest that it is not essential to get a code change into the 1.0 release.

> 1.) it is bison-based, which complicates the build and release processes,
> especially for Windows.
> 2.) it parses an extremely large set of possible date formats, sometimes
> in surprising and counterintuitive ways.
> 3.) it is complex enough to discourage maintainance and enhancement
> 4.) it does not support ISO 8601 date formats.

Well, it supports some of the ISO 8601 date formats, but not enough of them.

> 5.) it it not perfectly MP-safe
> 6.) it is a bit of an eyesore.
>
> If we are to replace it, we must do so before 1.0 so that its replacement
> will not be forced to support a superset of its behaviour.

Actually, if we can find a sufficient common subset of formats supported now and formats that we would like to support, then we could leave the implementation in place but _document_ that only specific formats are supported by Subversion. For example, the set of formats "YYYY-MM-DD[ HH:MM[:SS]]" is supported by both the current and the proposed schemes, although I'm not sure if it means the same in terms of UTC or local time. Note that it would be OK to find a very restrictive subset for the time being; we can expand the range of formats in a future release.

I admit that just documenting that only a few of the accepted formats are supported is not ideal, but nor is it terribly bad. (If it is terribly bad, then we should review similar cases such as "svn log" with multiple WC targets.)

> I propose the following implementation strategy (this is loosely based
> on work from C. Scott Ananian <cananian@lesser-magoo.lcs.mit.edu>, available
> at http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=6093):
>
> The current local time and current UTC time must be passed to the date
> parser.
>
> Take the first match amongst:
>
> 1.) the following ISO 8601 extended date-time formats:
>
> YYYY-MM-DDThh:mm:ss.sTZI
> YYYY-MM-DDThh:mm:ss,sTZI
> YYYY-MM-DDThh:mm:ssTZI
> YYYY-MM-DDThh:mmTZI
> YYYY-MM-DDThhTZI

... where the final "s" represents an arbitrary number of decimal digits.

[...]
> 2.) the following ISO 8601 basic date-time formats:
>
> YYYYMMDDThhmmss.sTZI
> YYYYMMDDThhmmss,sTZI
> YYYYMMDDThhmmssTZI
> YYYYMMDDThhmmTZI
> YYYYMMDDThhTZI

(For categories 1 and 2:)

> Where "TZI" stands for "Time Zone Indicator", and can be one of:
>
> Z
> +HH
> -HH
> +HH:MM
> -HH:MM

... else must be the empty string, meaning local time.

> 3.) the following formats, which will be adjusted to UTC from local time.
>
> YYYY-MM-DD HH:MI:SS
> YYYY-MM-DD HH:MI
>
> 4.) the following formats, which are presumed to reference midnight
> local time of the specified day.
>
> YYYY-MM-DD
> YYYYMMDD

... where "midnight" means 00:00 hours. (Missing hours and/or minutes and/or seconds fields mean 0 in all of these formats.)

Sometimes it would be nice to have it mean 00:00 when used as the beginning of a revision range and 24:00 when used as the end of a range, but I don't think now is the time to consider that.

> 5.) the following formats, which are presumed to reference local time
> of the current day.
>
> HH:MI:SS
> HH:MI

... where "current day" means (now +- 12 hours).

If "current day" were to mean 00:00 to 24:00 on the current date, then this would be unfriendly to people who (like me) work after midnight. Therefore "current day" should mean the period of <= 24 hours that ends at least few minutes after "now" (to allow for clock skew); e.g. "(now - 12 hours) to (now + 6 hours)" or "(now +/- 12 hours)". There is a precedent in Unix "ls" and Subversion "svn list": when printing a file date without the year we require that the date be within (now +/- 6 months), not that it be within the current calendar year.

> I believe that these formats are necessary and sufficient for the 1.0

Sufficient, yes. Necessary? No: not all of them. If you mean "desirable", then I agree that they are all reasonable although I personally don't want the formats that have hour but not minute.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 16 00:40:25 2003