[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: Christopher Ness <chris_at_nesser.org>
Date: 2005-07-23 01:48:40 CEST

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
[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

> 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
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. ;)


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

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.