It's a good question, Justin, but there's a long-standing answer:
The output of the Subversion client is designed to be *both*
human-readable and machine parseable. This is true across the board.
Notice the line count in the "svn log" output; notice the careful
field delimiting in status/update/commit/checkout/etc output; notice
"svn info", and so on.
This means the date output format should match some standard and
contain enough information to be useful to programs (without imposing
too great a parsing burden, either)... And that it *also* should
provide what humans want for convenient reading.
This is not some theoretical nicety. Many programs parse CVS log
output (and the output of all other CVS commands), and we should
expect the same to be true for Subversion. Heck, it already *is*
starting to be true; look in tools/client-side/.
-K
Justin Erenkrantz <jerenkrantz@apache.org> writes:
> Pardon me, but why do we care about producing ISO-8601 dates in
> the human-readable sections? If you want the ISO-8601 dates, why
> don't you just write a client yourself? You shouldn't be parsing
> the 'svn log' output - that's what client libraries are for. The
> more complicated the human date is, the worse off *we* are. If
> you are intending the human-readable sections to be read by a
> computer, I think the preference must go to the humans not to
> the computer.
>
> I know I'm a giant stick in the mud. IMHO, this date format is
> *way* too long. And, this is essentially what CVS is printing
> with an additional TZ (and the human-friendly dates). I'm not sure
> I understand why a human cares about the TZ - the repos time should
> be translated to the timezone that the client computer is in.
> Ostensibly, that's the time that the user knows best.
>
> What TZ would we report when Karl commits in Chicago and Greg commits
> in San Fransisco? For the human on 'svn log' output, they should be
> the same, right? Or, are you suggesting that 'svn log' tells me that
> Karl commits at 5AM and a later commit from Greg comes in at 4AM?
> Or, do I get stuck with the timezone of the server? I think the best
> solution is the timezone of the client - which means that the
> timezone information in the human-readable format is
> redundant. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 24 21:49:47 2002