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
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:
>>... 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.
>>>Where "TZI" stands for "Time Zone Indicator", and can be one of:
>>... 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.
>>>5.) the following formats, which are presumed to reference local time
>>> of the current day.
>>... 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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Dec 16 16:55:20 2003