Re: RFC: date parser rewrite

mark benedetto king wrote:
> On Mon, Dec 15, 2003 at 11:39:33PM +0000, Julian Foad wrote:
>
>>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.
>
> Undocumented features have a habit of making their way into common
> practice and "insider's guides" (c.f. Google Hacks).

Indeed. As I said (below), it's not a terribly great solution. Nevertheless I thought it was worth considering as it would avoid a bunch of coding work just as we are trying to stabilise.

>>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'll mention the "svn log" case in a separate thread.

> Even documenting the existing implementation is difficult.
>
[long example snipped]

That's irrelevant. I was suggesting that we just document that the only supported format is "YYYY-MM-DD hh:mm:ss" and it means local time (and/or a very small number of other simple formats).

>>>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.
>
> Right, as long as arbitrary means "less than 7": we only store microseconds
> in the repository, we shouldn't fake finer granularity than we can provide.

OK.

>>>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.
>
> This makes the special cases below in (4) irrelevant, as those formats can
> be merged into (1) and (2). Fine by me.

i.e. add "YYYY-MM-DDTZI" to the list in (1) and "YYYYMMDDTZI" to the list in (2). That would add date-only formats with a non-empty TZI to the current proposal, but I think that makes sense and is a good thing for consistency. e.g. a GUI might allow the user to enter a date and/or time, and the program could then apend the TZI itself without knowing which format the user entered.

>>>4.) the following formats, which are presumed to reference midnight
>>> local time of the specified day.
>>>
>>> YYYY-MM-DD
>>> YYYYMMDD

>>>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
>
> What about the people who (like me) work >12 hour days? :-)

You smile, but the question is worth answering.

Well, we could make it (now - 23 hours) to (now + 1 hour). The "+" side only needs a few minutes to overcome clock skew, so "+ 1 hour" is plenty. However, we could also say that this format is only appropriate for recent times - much less than a day - and if the event was anywhere approaching a day ago, i.e. more than half a day ago, then you need to use a different format.

>>"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.
>
> While this would certainly be useful, I think it would be much simpler
> to implement and document the "current calendar day" interpretation.

Simpler, but not much so, but I won't force the issue. In that case I think we should require that the specified time be between 00:00 and "now", so that both semantics (other times meaning "later today" and other times meaning "yesterday") are reserved for a future extension.

- 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 16:55:20 2003