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 <firstname.lastname@example.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.
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jul 22 13:20:11 2005