You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Christopher Ness <ch...@nesser.org> on 2005/07/08 17:41:03 UTC
Re: Date processing should be more flexible
On Fri, 2005-07-08 at 09:46 +0200, Norbert Unterberg wrote:
> 2005/7/6, Christopher Ness <ch...@nesser.org>:
>
> > I researched the standard and feel that we should relax the requirement
> > to include all digits in the Month and Day fields in our date parser.
> > This only applies for a date with separators (currently dashes).
>
> I agree here. I should have made it more clear in my previous mail.
> ISO requires the leading zeros, so subversion should use them
> everywhere it *outpus* date and time. But I see no problem in relaxing
> the requirement on the date parser in this single respect.
Agreed, users will want the advantage of ISO8601 sortable strings in the
output from subversion.
I have a patch ready on my machine at home that implements this for
Month, Day and Hours. Minutes didn't seem to make sense to allow
omitting of leading zeros as I've never seen that. I have added some
test cases for these new parsing templates.
Before I publish my second revision of the patch I want to look into
returning more meaningful error messages back to the user upon failed
date inputs.
I'll sleep on it over the weekend and see what I can come up with.
Thanks for the input Norbert.
Chris
--
Wireless Group,
McMaster University
finger.localdomain
13:34:41 up 1:43, 1 user, load average: 0.52, 0.20, 0.08
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Sat, 2005-07-23 at 01:32 +0100, Julian Foad wrote:
> [...]
> > Having the hours, months and days without leading zeros is a valid input
> > IMHO.
>
> 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.
People _with out_ exposure to the standard see these as equivalent (they
do not understand the sorting issues described below - nor IMHO should
they as users).
The current state of the system does not see these as equivalent since
the LHS errors out.
> 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?
The deep details are that once the strings are parsed (char by char)
they are equivalent iff the LHS is accepted though the templates. It
currently is not.
The true nature of the standard appears to forbid omitting leading zeros
in the string because of this sorting case.
[nesscg@heidrun subversion]$ printf 2005-7-22\\n2005-07-22\\n2005-07-23\
\n | sort
2005-07-22
2005-07-23
2005-7-22
Obviously line 3 is out of place. But svn doesn't sort user input and I
cannot imagine why it should.
I like my bikeshed a nice ale colour.
Going to paint it at the /dev/local/pub
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
20:37:50 up 3:29, 3 users, load average: 0.54, 0.47, 0.35
Re: Date processing should be more flexible
Posted by Julian Foad <ju...@btopenworld.com>.
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
itself.
> 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
> <OMITTED>
> [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
> IMHO.
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
Re: [PATCH]: Ver 2: Re: Date processing should be more flexible
Posted by Julian Foad <ju...@btopenworld.com>.
Christopher Ness wrote:
> On Thu, 2005-07-28 at 18:15 +0100, Julian Foad wrote:
>
>>Thanks. That's fine. Committed in r15459.
>
> Thanks for walking me though the process and offering reviews Julian,
> Norbert and Greg.
>
> What is the procedure for suggesting this to be released in the next bug
> fix version? Now it modifies the UI, so would it be a candidate for
> 1.2.2?
It isn't a bug fix nor anything urgent or important (apologies if it is
important to you), so it isn't a candidate for back-porting to the next bug-fix
release; instead this enhancement will appear in the next minor release
(version 1.3).
If it were a bug fix, the procedure would be to have a committer list it as a
candidate in the "STATUS" file for the 1.2.x branch, and then other committers
vote on it; if it gets enough votes then it would be merged to that branch.
Also, as you wondered, a candidate for a bug-fix release must not change the UI
(or any interface).
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Ver 2: Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Thu, 2005-07-28 at 18:15 +0100, Julian Foad wrote:
> Thanks. That's fine. Committed in r15459.
Thanks for walking me though the process and offering reviews Julian,
Norbert and Greg.
What is the procedure for suggesting this to be released in the next bug
fix version? Now it modifies the UI, so would it be a candidate for
1.2.2?
Cheers,
Chris
--
Wireless Group
McMaster University
summer
15:49:24 up 7 days, 1:42, 2 users, load average: 0.36, 0.25, 0.17
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Ver 2: Re: Date processing should be more flexible
Posted by Julian Foad <ju...@btopenworld.com>.
Christopher Ness wrote:
> On Fri, 2005-07-22 at 19:48 -0400, Christopher Ness wrote:
>
>>I have a new patch ready since it (cat date_tests >> old_patch), if
>>there is no more discussion I'll submit it for review `ghudson`
>>convinced me it's best to separate this from the error messages in the
>>client. Which makes sense. ;)
>
> Here is the second version of the date relaxing patch. Added some tests
> in time-test.c for the changes I made.
Thanks. That's fine. Committed in r15459.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH]: Ver 2: Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Fri, 2005-07-22 at 19:48 -0400, Christopher Ness wrote:
> I have a new patch ready since it (cat date_tests >> old_patch), if
> there is no more discussion I'll submit it for review `ghudson`
> convinced me it's best to separate this from the error messages in the
> client. Which makes sense. ;)
Here is the second version of the date relaxing patch. Added some tests
in time-test.c for the changes I made.
Find attached.
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
23:17:39 up 1:08, 2 users, load average: 0.48, 0.39, 0.41
Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Fri, 2005-07-22 at 12:18 +0100, Julian Foad wrote:
> My humble opinion, for what it's worth...
Good to get some more feedback, as I find this to be a valid change to
the date input parsing. It's not overly ambitious ("one week ago") but
makes inputing dates more flexible.
> > I have a patch ready on my machine at home that implements this for
> > Month, Day and Hours. Minutes didn't seem to make sense to allow
> > omitting of leading zeros as I've never seen that.
>
> I agree that minutes (and seconds) should require a leading zero, as they are
> nearly always written so anyway.
>
> 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?
Are we talking input or output here? 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
<OMITTED>
[nesscg@heidrun subversion]$ svn log -r{9:59}
svn: Syntax error in revision argument '{9:59}'
> Basically, I am saying: If you believe the ability to omit the leading zero
> from the hour will significantly help people, then OK. If you just included
> the hour because you were doing the month and day (as per the original
> proposal) and thought, "Might as well do as many of the other fields as make
> sense, too," then I would ask you to reconsider.
When I went about making the patch I actually had all of the inputs
(minutes and seconds) as a possible single digit.
When I tested that change it "felt" wrong to type -r{9:0:0} (can
something feel wrong when typing?? because it did) so I reverted the
minutes and seconds back to full two characters.
Having the hours, months and days without leading zeros is a valid input
IMHO.
> 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}
PEBKAC is not a good enough motivation to make a change, but I feel this
patch is valid since it still supports the standard and allows more
flexibility for user input which can save a few key strokes and
headaches.
I believe it will continue to do so in the future too, beyond the cost
of maintenance.
There seems to be cleaning up a lot of these little things, with the " |
N lines" thread as well. That's good to see!
I have a new patch ready since it (cat date_tests >> old_patch), if
there is no more discussion I'll submit it for review `ghudson`
convinced me it's best to separate this from the error messages in the
client. Which makes sense. ;)
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
19:15:40 up 2:07, 1 user, load average: 0.30, 0.23, 0.18
Re: Date processing should be more flexible
Posted by Julian Foad <ju...@btopenworld.com>.
My humble opinion, for what it's worth...
Christopher Ness wrote:
> On Fri, 2005-07-08 at 09:46 +0200, Norbert Unterberg wrote:
>>2005/7/6, Christopher Ness <ch...@nesser.org>:
>>
>>>I researched the standard and feel that we should relax the requirement
>>>to include all digits in the Month and Day fields in our date parser.
>>>This only applies for a date with separators (currently dashes).
>>
>>I agree here. I should have made it more clear in my previous mail.
>>ISO requires the leading zeros, so subversion should use them
>>everywhere it *outpus* date and time. But I see no problem in relaxing
>>the requirement on the date parser in this single respect.
OK.
> Agreed, users will want the advantage of ISO8601 sortable strings in the
> output from subversion.
Yes, we definitely shouldn't change the output.
> I have a patch ready on my machine at home that implements this for
> Month, Day and Hours. Minutes didn't seem to make sense to allow
> omitting of leading zeros as I've never seen that.
I agree that minutes (and seconds) should require a leading zero, as they are
nearly always written so anyway.
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.
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?
Basically, I am saying: If you believe the ability to omit the leading zero
from the hour will significantly help people, then OK. If you just included
the hour because you were doing the month and day (as per the original
proposal) and thought, "Might as well do as many of the other fields as make
sense, too," then I would ask you to reconsider.
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.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org