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

Re: Date processing should be more flexible

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-07-23 02:32:38 CEST

Christopher Ness wrote:
> On Fri, 2005-07-22 at 12:18 +0100, Julian Foad wrote:
>>If people are able to write the hour without a leading zero, don't you think
>>that will make it too easy for them to accidentally think and write times
>>according to the 12-hour clock (even though an explicit "am" or "pm" would be
>>rejected)? But maybe the ability to omit the zero is more useful in practice.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> My thoughts exactly.
> Those that wish to include the zero are not inconvenienced and those
> that wish to save a few keystrokes (depending on the date of course) can
> do so.
>> In our current formats the time is only given with a date, not alone, which
>>makes it less likely that someone will mistakenly write "8:23" for "this
>>evening", but what if we later add a time-only format?

Oops, I was wrong there: our current formats do include specifying the time by

> Are we talking input or output here?

Input. I looked through our input formats and didn't spot the time-only format
that we already have.

> Are these not equivalent user
> inputs. I suppose this is the question that needs to be answered.
> [nesscg@heidrun subversion]$ svn log -r{09:59}
> ------------------------------------------------------------------------
> r15392 | maxb | 2005-07-22 09:29:30 -0400 (Fri, 22 Jul 2005) | 2 lines
> [nesscg@heidrun subversion]$ svn log -r{9:59}
> svn: Syntax error in revision argument '{9:59}'

Those two inputs ("9:59" and "09:59") would certainly be interpreted as the
same time by the software. The question is, when typing each of them, did the
person have the same intention, or is there a greater chance that he was
mistakenly thinking of the evening on a 12-hour clock when writing the former,
compared with the latter? My answer is, "Yes, there is a greater chance of
this mistake ... but not much greater." I feel that use of a leading zero
emphasizes that the 24-hour clock is meant, but that is probably mainly a
result of the way I was taught at school, and is not necessarily a very
widespread phenomenon.

> Having the hours, months and days without leading zeros is a valid input

Yup, valid. That doesn't convince me that omitting the zero from the hours
gives a significant extra usability benefit in practice, but this is rather a
lot of discussion for a rather small issue: it's become a bikeshed-painting
exercise. I'll accept your intuition and preference.

>>I'm in two minds about whether this change is a good idea in the long term.
>>Every bit of flexibility has an unquantifiable cost, and though the cost seems
>>pretty low I'm not completely convinced that the amount of added convenience is
>>worth it (it seems like a very tiny benefit to me). On the other hand I don't
>>think it's a big issue either way, so if it makes several people happy then,
>>OK, let's have it.
> For those that do not have experience with the ISO 8601 standard it is
> quite hard -- even after smashing your head off the cubical walls a few
> times -- to convince oneself that:
> -r{2005-7-22} != -r{2005-07-22}

What are you saying? Surely your patch will cause Subversion to treat those
two specifications as equal. Yet you are implying that, with experience of the
standard and some hard thought, one can understand that those specifications
are in some way unequal. In what way? If so, isn't your patch bad?

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 23 02:33:27 2005

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

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