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).
> 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.)
Even documenting the existing implementation is difficult.
For example: let's assume we have documented how the parser extracts
the year from the provided string, if present. In order to determine
the actual year, the following logic is applied:
Take the absolute value of the parsed year. Just in case.
If it's less than 69 add 2000 to it (assume that it's a two digit
reference to a 21st century year), otherwise, if it's less than
100, assume that it's a two digit reference to a 20th century year
and add 1900. If the new value is before 1970, this must be an
invalid date. Similarly, if it's after 2038, it must also be
an invalid date.
And that's just to handle how to interpret the year, presuming that
we've carefully and accurately documented how the year might be
extracted! Like how, for example, "(bork)10101(bork)" is parsed
as the date "2001-01-01" (in local time, of course).
> >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.
> >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.
> >
> >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.)
Right. I should have been more specific.
>
> 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.
>
Yes, but for that people can just use the next day.
> >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? :-)
> "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.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 16 04:43:57 2003