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
Received on Sat Jul 23 01:48:31 2005