[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 1124 - trunk/subversion/libsvn_wc

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-02-01 02:10:18 CET

Greg, Karl ... apr_strftime? Perhaps with the format string configurable
in ~/.svnrc?
That's for keyword expansions, of course. For attributes in
.svn/entries, ISO 8601 rules.

Karl Fogel wrote:

>Greg Stein <gstein@lyra.org> writes:
>
>>Here is a valid ISO 8601 date:
>>
>> 2001-11-21T09:15:56.423888Z
>>
>>That is the ISO 8601 form for a date that I just extracted from a
>>.svn/entries file.
>>
>
><Karl waves the Big Picture at Greg>
>
>Uh, well, fine, but then ISO 8601 is not useful for the problem we're
>trying to solve, which is that Subversion's internal date
>representation is not fit for human consumption. You're not seriously
>proposing that we expand dates like this
>
> $LastChangedDate: 2001-11-21T09:15:56.423888Z $
>
>right? :-)
>
>The issue here isn't what this or that ISO standard allows. The issue
>is that the format we'd like to use for human-readable dates can't
>hold all the information that might be found in an apr_time_t.
>Therefore such a format *cannot* have a read-write invariance with
>apr_time_t, I would think.
>
>So Subversion either has to give up the read-write invariance, or do
>its own one-way date conversion at certain times. (I'm tempted to
>write "Q.E.D." now, but perhaps you have some rabbit to pull out of a
>hat?)
>
>-K
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:02 2006

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.