You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nuutti Kotivuori <na...@iki.fi> on 2002/06/22 10:08:37 UTC
[PATCH] Unify human represented timestamp formats.
I made a patch which adds a new function, svn_time_to_human_nts, and
then uses it for the places where the date format is mangled for user
display.
The actual format of the date stamps is:
2002-06-22 11:14:42 +03:00
The format can - and should - be changed if a real consensus is gotten
for the format.
The dubious part is 'svnlook'. Should that use this same function?
This means that TZ needs to be set very carefully for it. I'd want
some input on this.
I'll probably work a bit more on the patch - and then commit it if it
is deemed as a good thing. But, without further ado, on to examples
and the patch.
Examples:
naked@oro:~/src/subversion/svn$ svn log -r2307
------------------------------------------------------------------------
rev 2307: brane | 2002-06-21 23:39:28 +03:00 | 1 line
* subversion_client.dsp: Removed trace-update.c.
------------------------------------------------------------------------
naked@oro:~/src/subversion/svn$ TZ= svn log -r2307
------------------------------------------------------------------------
rev 2307: brane | 2002-06-21 20:39:28 +00:00 | 1 line
* subversion_client.dsp: Removed trace-update.c.
------------------------------------------------------------------------
naked@oro:~/src/subversion/svn$ TZ=MST svn log -r2307
------------------------------------------------------------------------
rev 2307: brane | 2002-06-21 13:39:28 -07:00 | 1 line
* subversion_client.dsp: Removed trace-update.c.
------------------------------------------------------------------------
naked@oro:~/src/subversion/svn$ svn info
Path: .
Url: http://svn.collab.net/repos/svn/trunk
Revision: 2308
Node Kind: directory
Schedule: normal
Last Changed Author: naked
Last Changed Rev: 2308
Last Changed Date: 2002-06-22 11:14:42 +03:00
Properties Last Updated: 2002-06-09 14:35:13 +03:00
naked@oro:/tmp/repostemp$ svnlook foorepos
2002-06-22 12:14:58 +03:00
0
/
Log message:
Added a new function, svn_time_to_human_nts, that handles converting
apr_time_t into a human representable time format. Then made 'svn log',
'svn info' and 'svnlook' use it.
* subversion/include/svn_time.h
(svn_time_to_human_nts): New prototype.
* subversion/libsvn_subr/time.c
(human_timestamp_format): New variable.
(svn_time_to_human_nts): New function.
* subversion/svnlook/main.c
(do_date): Use svn_time_to_human_nts.
* subversion/clients/cmdline/log-cmd.c: Include svn_time.h.
(humanize_date): Remove function.
(log_message_receiver): Use svn_time_to_human_nts.
* subversion/clients/cmdline/info-cmd.c: Include svn_time.h.
(svn_cl__info_print_time): Add pool argument.
(svn_cl__info_print_time): Use svn_time_to_human_nts.
(svn_cl__info): Give pool to svn_cl__info_print_time.
Patch:
Index: ./subversion/include/svn_time.h
===================================================================
--- ./subversion/include/svn_time.h
+++ ./subversion/include/svn_time.h Sat Jun 22 11:44:59 2002
@@ -39,6 +39,11 @@
svn_error_t *svn_time_from_nts(apr_time_t *when, const char *data,
apr_pool_t *pool);
+/* Convert WHEN to a const char * representation allocated in POOL,
+ suitable for human display. */
+const char *svn_time_to_human_nts (apr_time_t when, apr_pool_t *pool);
+
+
/* Needed by getdate.y parser */
struct getdate_time {
time_t time;
Index: ./subversion/libsvn_subr/time.c
===================================================================
--- ./subversion/libsvn_subr/time.c
+++ ./subversion/libsvn_subr/time.c Sat Jun 22 12:48:28 2002
@@ -55,6 +55,16 @@
static const char * const old_timestamp_format =
"%s %d %s %d %02d:%02d:%02d.%06d (day %03d, dst %d, gmt_off %06d)";
+/* Our human representation of dates look like this:
+ *
+ * "2002-05-07 12:34:56 +03:00"
+ *
+ * This format is used whenever time is shown to the user
+ * directly.
+ */
+static const char * const human_timestamp_format =
+"%.4d-%.2d-%.2d %.2d:%.2d:%.2d %+.2d:%.2d";
+
const char *
svn_time_to_nts (apr_time_t t, apr_pool_t *pool)
@@ -193,6 +203,26 @@
return svn_error_createf(SVN_ERR_BAD_DATE, 0, NULL, pool,
"Date parsing failed.");
}
+}
+
+
+const char *
+svn_time_to_human_nts (apr_time_t t, apr_pool_t *pool)
+{
+ apr_time_exp_t exploded_time;
+
+ apr_time_exp_lt (&exploded_time, t);
+
+ return apr_psprintf (pool,
+ human_timestamp_format,
+ exploded_time.tm_year + 1900,
+ exploded_time.tm_mon + 1,
+ exploded_time.tm_mday,
+ exploded_time.tm_hour,
+ exploded_time.tm_min,
+ exploded_time.tm_sec,
+ exploded_time.tm_gmtoff / (60 * 60),
+ (exploded_time.tm_gmtoff / 60) % 60);
}
Index: ./subversion/svnlook/main.c
===================================================================
--- ./subversion/svnlook/main.c
+++ ./subversion/svnlook/main.c Sat Jun 22 12:13:14 2002
@@ -736,28 +736,11 @@
if (prop_value && prop_value->data)
{
- /* The date stored in the repository is in a really complex
- and precise format...and we don't care. Let's convert
- that to just "YYYY-MM-DD hh:mm".
-
- ### todo: Right now, "svn dates" are not GMT, but the
- results of svn_time_from_string are. This sucks. */
- apr_time_exp_t extime;
+ /* Convert the date for humans. */
apr_time_t aprtime;
- apr_status_t apr_err;
SVN_ERR (svn_time_from_nts (&aprtime, prop_value->data, pool));
- apr_err = apr_time_exp_tz (&extime, aprtime, 0);
- if (apr_err)
- return svn_error_create (apr_err, 0, NULL, pool,
- "do_date: error exploding time");
-
- printf ("%04lu-%02lu-%02lu %02lu:%02lu GMT",
- (unsigned long)(extime.tm_year + 1900),
- (unsigned long)(extime.tm_mon + 1),
- (unsigned long)(extime.tm_mday),
- (unsigned long)(extime.tm_hour),
- (unsigned long)(extime.tm_min));
+ printf ("%s", svn_time_to_human_nts (aprtime, pool));
}
}
Index: ./subversion/clients/cmdline/log-cmd.c
===================================================================
--- ./subversion/clients/cmdline/log-cmd.c
+++ ./subversion/clients/cmdline/log-cmd.c Sat Jun 22 12:07:30 2002
@@ -34,6 +34,7 @@
#include "svn_pools.h"
#include "svn_sorts.h"
#include "svn_xml.h"
+#include "svn_time.h"
#include "cl.h"
@@ -79,47 +80,6 @@
};
-/* Maximum length of a human-readable date string, including final '\0'. */
-#define SVN_LOG__DATE_MAX 38
-
-
-/* Format an svn_time_to_string()-created date for human consumption,
- * store the result in RESULT, which is at least SVN_LOG__DATE_MAX
- * bytes long.
- *
- * Why do this? The problem is that svn_time_to_string() returns a
- * date like this:
- *
- * "Sat 2 Mar 2002 20:41:01.695108 (day 061, dst 0, gmt_off -21600)"
- *
- * but humans only want to see:
- *
- * "Sat 2 Mar 2002 20:41:01"
- *
- * You would think the part before the dot would be constant length,
- * but it's not, because the day-of-month can be one or two digits.
- * Also, we want to get the right result unconditionally, even when
- * handed an already-truncated date. So, we have this function to
- * sort it all out and Do The Right Thing.
- */
-static void
-humanize_date (char *result, const char *date)
-{
- const char *p = strchr (date, '.');
-
- if (p && ((p - date) < SVN_LOG__DATE_MAX))
- {
- strncpy (result, date, (p - date));
- result[p - date] = '\0';
- }
- else /* hmmm, not the format we expected, so use as much as can */
- {
- strncpy (result, date, (SVN_LOG__DATE_MAX - 1));
- result[SVN_LOG__DATE_MAX - 1] = '\0';
- }
-}
-
-
/* This implements `svn_log_message_receiver_t', printing the logs in
* a human-readable and machine-parseable format. BATON is of type
* `struct log_message_receiver_baton *'.
@@ -159,8 +119,8 @@
/* Number of lines in the msg. */
int lines;
- /* As much date as we ever want to see. */
- char dbuf[SVN_LOG__DATE_MAX];
+ /* Date string for humans. */
+ const char *dbuf;
if (rev == 0)
{
@@ -168,7 +128,13 @@
return SVN_NO_ERROR;
}
- humanize_date (dbuf, date);
+ {
+ /* Convert date to a format for humans. */
+ apr_time_t time_temp;
+
+ SVN_ERR (svn_time_from_nts (&time_temp, date, pool));
+ dbuf = svn_time_to_human_nts(time_temp, pool);
+ }
#define SEP_STRING \
"------------------------------------------------------------------------\n"
Index: ./subversion/clients/cmdline/info-cmd.c
===================================================================
--- ./subversion/clients/cmdline/info-cmd.c
+++ ./subversion/clients/cmdline/info-cmd.c Sat Jun 22 12:10:50 2002
@@ -26,26 +26,18 @@
#include "svn_string.h"
#include "svn_error.h"
#include "svn_path.h"
+#include "svn_time.h"
#include "cl.h"
/*** Code. ***/
static void
-svn_cl__info_print_time (apr_time_t atime, const char * desc)
+svn_cl__info_print_time (apr_time_t atime,
+ const char *desc,
+ apr_pool_t *pool)
{
- apr_time_exp_t extime;
- apr_status_t apr_err;
-
- /* if this returns an error, just don't print anything out */
- apr_err = apr_time_exp_tz (&extime, atime, 0);
- if (! apr_err)
- printf ("%s: %04lu-%02lu-%02lu %02lu:%02lu GMT\n", desc,
- (unsigned long)(extime.tm_year + 1900),
- (unsigned long)(extime.tm_mon + 1),
- (unsigned long)(extime.tm_mday),
- (unsigned long)(extime.tm_hour),
- (unsigned long)(extime.tm_min));
+ printf ("%s: %s\n", desc, svn_time_to_human_nts (atime,pool));
}
svn_error_t *
@@ -161,13 +153,14 @@
printf ("Last Changed Rev: %" SVN_REVNUM_T_FMT "\n", entry->cmt_rev);
if (entry->cmt_date)
- svn_cl__info_print_time (entry->cmt_date, "Last Changed Date");
+ svn_cl__info_print_time (entry->cmt_date, "Last Changed Date", pool);
if (entry->text_time)
- svn_cl__info_print_time (entry->text_time, "Text Last Updated");
+ svn_cl__info_print_time (entry->text_time, "Text Last Updated", pool);
if (entry->prop_time)
- svn_cl__info_print_time (entry->prop_time, "Properties Last Updated");
+ svn_cl__info_print_time (entry->prop_time, "Properties Last Updated",
+ pool);
if (entry->checksum)
printf ("Checksum: %s\n", entry->checksum);
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Nuutti Kotivuori <na...@iki.fi>.
Justin Erenkrantz wrote:
> On Sat, Jun 22, 2002 at 01:08:37PM +0300, Nuutti Kotivuori wrote:
>> I made a patch which adds a new function, svn_time_to_human_nts,
>> and then uses it for the places where the date format is mangled
>> for user display.
>>
>> The actual format of the date stamps is:
>> 2002-06-22 11:14:42 +03:00
>
> If you are going to insist on this format, I would greatly prefer
> removing the colon from the TZ. -- justin
I am not insisting on anything, really. I just thought I got a bit
more wishes for derivatives of this format - I really don't know. I
thought I'd solve the problem by committing something and then just
waiting until I get a clear request from someone to change it to
something else. So I'd like a clear comment from you or someone else
that how should I proceed.
But on the format itself, actually the ISO-8601 standard implies that
the TZ should have a colon if the time format has colons - and not
have a colon if the time format doesn't have them. The usage of space
instead of 'T' as the middle delimiter is something one can get away
with - but the addition of space between the time and the timezone
does violate the standard I believe. I do not have the standard
accessible, so I really can't say anything definite. And this is
ofcourse very much irrelevant for dates that are just displayed to the
user.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Justin Erenkrantz <je...@apache.org>.
On Sat, Jun 22, 2002 at 01:08:37PM +0300, Nuutti Kotivuori wrote:
> I made a patch which adds a new function, svn_time_to_human_nts, and
> then uses it for the places where the date format is mangled for user
> display.
>
> The actual format of the date stamps is:
> 2002-06-22 11:14:42 +03:00
If you are going to insist on this format, I would greatly prefer
removing the colon from the TZ. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Hontvari Jozsef <ho...@solware.com>.
> Karl Fogel wrote:
"Sat 22 Jun 2002-06-22 11:14:42 +03:00"
That is really ugly for me :-) But the important point I think is that the
iso format is the one which is intended for everyone. So if you add
non-standard elements then at least you should add them at the end of the
iso date and not before it. Then those who already natively read iso dates
can simply stop "parsing" after the time zone.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Nuutti Kotivuori <na...@iki.fi> writes:
> And btw, if you didn't notice - neither 'svnlook' or 'svn info' prints
> the weekday nor the month name.
I don't debug the fs nearly as often as I use "svn log", that's all.
> > I can tell you right now that if the human-presentation date strings
> > do not include the month name, then this becomes a pre-1.0 issue for
> > me personally :-).
>
> Wellll, maybe we can squeeze it in ;)
Whatever you have time for; you're doing plenty already!
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
svnlook/info times (was: [PATCH] Unify human represented timestamp formats.)
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Jun 22, 2002 at 11:41:26PM +0300, Nuutti Kotivuori wrote:
> Karl Fogel wrote:
> > Nuutti Kotivuori <na...@iki.fi> writes:
> >> The repository timestamps are GMT, if they were to be let out to
> >> the user as is, which is not going to happen.
> >
> > So what exactly is the "dubious part" about svnlook, then?
>
> Because we are converting the timestamps from the repository format to
> human display in 'svnlook' - we do it right now and we do it with the
> patch I sent. Right now, 'svnlook' always generates the timestamps in
> GMT - but for example 'svn info' claims it has GMT timestamps, but in
> actuality they are localtime and it just doesn't print the timezone.
svnlook and 'svn info' should output human timestamps, which also implies
local timezone and printing the timezone.
svnadmin dump is not about 'human' stuff, so it is fine to stick to 8601.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Nuutti Kotivuori <na...@iki.fi>.
Karl Fogel wrote:
> Nuutti Kotivuori <na...@iki.fi> writes:
>> The repository timestamps are GMT, if they were to be let out to
>> the user as is, which is not going to happen.
>
> So what exactly is the "dubious part" about svnlook, then?
Because we are converting the timestamps from the repository format to
human display in 'svnlook' - we do it right now and we do it with the
patch I sent. Right now, 'svnlook' always generates the timestamps in
GMT - but for example 'svn info' claims it has GMT timestamps, but in
actuality they are localtime and it just doesn't print the timezone.
And btw, if you didn't notice - neither 'svnlook' or 'svn info' prints
the weekday nor the month name.
>> That was the discussion sometime back. There's the problem that if
>> the date format is customizable, then the machine parsability of
>> any output which contains dates goes down a bit. But anyway, I'd
>> suppose that's a post-1.0 issue.
>
> I can tell you right now that if the human-presentation date strings
> do not include the month name, then this becomes a pre-1.0 issue for
> me personally :-).
Wellll, maybe we can squeeze it in ;)
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Nuutti Kotivuori <na...@iki.fi> writes:
> > Okay, I'd like to propose:
> >
> > Sat 2002-06-22 11:14:42 +03:00
>
> I can do that. But ask everybody else for the consensus on using that.
That's what I'm doing :-).
> >> The dubious part is 'svnlook'. Should that use this same function?
> >> This means that TZ needs to be set very carefully for it. I'd want
> >> some input on this.
> >
> > Oh, the question is, should it print dates in the server's local
> > timezone, or should it print exactly what is stored in the
> > repository (which is probably GMT, or maybe some other non-local
> > timezone)?
>
> The repository timestamps are GMT, if they were to be let out to the
> user as is, which is not going to happen.
So what exactly is the "dubious part" about svnlook, then?
> That was the discussion sometime back. There's the problem that if the
> date format is customizable, then the machine parsability of any
> output which contains dates goes down a bit. But anyway, I'd suppose
> that's a post-1.0 issue.
I can tell you right now that if the human-presentation date strings
do not include the month name, then this becomes a pre-1.0 issue for
me personally :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Nuutti Kotivuori <na...@iki.fi>.
Karl Fogel wrote:
> Nuutti Kotivuori <na...@iki.fi> writes:
>> I made a patch which adds a new function, svn_time_to_human_nts,
>> and then uses it for the places where the date format is mangled
>> for user display.
>>
>> The actual format of the date stamps is:
>> 2002-06-22 11:14:42 +03:00
>
> I'd add weekday in there, it's very important, IMHO (I'm sorry if I
> didn't say that when you were earlier soliciting comments on date
> formats, it was just an oversight.)
You did, I just ignored it :)
> Yes, I know this theoretically opens up a whole can of worms about
> non-English day and month names. But, intercultural offensiveness
> aside, it's *really convenient* to have even just the English, and a
> lot of people in the world understand the short English
> abbreviations "Mon", "Tue", etc.
I must say that I personally hate seeing english weekday or month
names. But I can see how convenient that can be, if weekdays matter.
>> The format can - and should - be changed if a real consensus is
>> gotten for the format.
>
> Okay, I'd like to propose:
>
> Sat 2002-06-22 11:14:42 +03:00
I can do that. But ask everybody else for the consensus on using that.
> Personal aside: I suspect this might be hard to get consensus on,
> but really the ideal thing for human readability (or at least
> English-reader readability) would be to use the month name as well,
> as in:
>
> Sat 22 Jun 2002 11:14:42 +03:00
Well if that's the way one goes, "Sat, 08 Jan 2000 18:31:41 GMT" is
the RFC822 date format. Or, the ctime() format "Sat Jun 22 23:19:29
EEST 2002". There were other, similar, but standardized formats
suggested as well.
> That's _slightly_ more complicated for automated parsers, though, so
> personally I'd have no problem with a redundant format like:
>
> Sat 22 Jun 2002-06-22 11:14:42 +03:00
>
> ...but I suppose that would cause much gnashing of teeth and hurling
> of sticks and stones, right?
Well... yes, from me atleast :)
>> The dubious part is 'svnlook'. Should that use this same function?
>> This means that TZ needs to be set very carefully for it. I'd want
>> some input on this.
>
> Oh, the question is, should it print dates in the server's local
> timezone, or should it print exactly what is stored in the
> repository (which is probably GMT, or maybe some other non-local
> timezone)?
The repository timestamps are GMT, if they were to be let out to the
user as is, which is not going to happen.
> <thinks>
>
> You know, I think we need both options. I'm not sure which should
> be the default, though.
Well, TZ can set these for now.
> Hmmm. I'm beginning to wonder if we don't really need a date format
> string with %-codes, settable from .subversion/config or
> something...
That was the discussion sometime back. There's the problem that if the
date format is customizable, then the machine parsability of any
output which contains dates goes down a bit. But anyway, I'd suppose
that's a post-1.0 issue.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Nuutti Kotivuori <na...@iki.fi>.
Bill Tutt wrote:
> Certainly to store the data this way in BDB makes eminent sense.
Storing data in BDB doesn't enter into it, it's a different
format. This format is _purely_ for user display.
> What needs to happen later is that SVN needs to suck in as many OS
> specific data about what the end user's date/time formatting
> preferences are and use those. Sounds like a job for APR if you ask
> me.
But is the output machine parsable then anymore?
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: customization (was: [PATCH] Unify human represented timestamp
formats.)
Posted by Nuutti Kotivuori <na...@iki.fi>.
Greg Stein wrote:
> IMO, Nutti should just commit the 'human' patch, but leave the
> string the same for now. That will get the structural changes in
> there, and then the format can be tweaked after the discussion is
> done.
Well, I just sent a mail suggesting two small differences from the
previous format. First, there's a comma after the weekday name - and
secondly there's a numeric timezone in the end.
But "Nutty" will commit soon anyway with the structural changes.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
customization (was: [PATCH] Unify human represented timestamp formats.)
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Jun 22, 2002 at 02:44:26PM -0500, Karl Fogel wrote:
> "Bill Tutt" <ra...@lyra.org> writes:
>...
> > What needs to happen later is that SVN needs to suck in as many OS
> > specific data about what the end user's date/time formatting preferences
> > are and use those. Sounds like a job for APR if you ask me.
>
> Yes, we should do that. But in the absence of environmental clues, we
> should default to the most useable possible format.
>
> <mantra>
> Giving the user the ability to customize doesn't absolve us from
> the responsibility of choosing good defaults for the non-customized
> case.
> </mantra>
>
> :-)
Heh. Actually, there are very good arguments for *not* allowing
customization. There are quite a few studies that show that customizable UIs
can be quite troublesome.
> If it's a matter of disagreement over whether the weekday name and/or
> month name makes the format more useable, that's fine. But I don't
> know (or don't *think* I know) anyone who prefers not to have those
> words when eye-parsing a date. They're so dang helpful. If we lose
> them, we're simply getting worse, IMHO.
IMO, Nutti should just commit the 'human' patch, but leave the string the
same for now. That will get the structural changes in there, and then the
format can be tweaked after the discussion is done.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Nuutti Kotivuori <na...@iki.fi> writes:
> I'll count that as a -1 on anything that doesn't have a weekday
> name. So I won't commit until this is resolved.
Thanks. Count it as a -1 in the absence of lots of input from others;
that is, if the whole list said "we think the weekday name is useless"
and I was the only one who cared, I wouldn't be -1. I just doubt
that's what people are going to say :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Nuutti Kotivuori <na...@iki.fi>.
Karl Fogel wrote:
> "Bill Tutt" <ra...@lyra.org> writes:
>> Err, (IIRC) the reason Nuutti's suggesting one and only one format
>> is because this realease (1.0) isn't focused on il8n. The format he
>> suggested isn't going to make everybody happy, but it's (IIRC)
>> better than what we have.
>
> I certainly don't think it's better than what we have -- it's worse.
>
> "svn log" used to print the weekday name; with this change, it
> doesn't. That's bad. I depend on that weekday name all the time,
> surely I can't be the only one. That output is substantially less
> useable without the name.
I'll count that as a -1 on anything that doesn't have a weekday
name. So I won't commit until this is resolved.
>> Certainly to store the data this way in BDB makes eminent
>> sense. Storing weekday information is useless, that can be easily
>> calculated. (Esp. if the weekday needs to get converted into a
>> non-Gregorian calendar like the Hebrew calendar.)
>
> Sure, there's no need to store the weekday name, completely agree.
That format is separate, no worries there.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Bill Tutt" <ra...@lyra.org> writes:
> Err, (IIRC) the reason Nuutti's suggesting one and only one format is
> because this realease (1.0) isn't focused on il8n. The format he
> suggested isn't going to make everybody happy, but it's (IIRC) better
> than what we have.
I certainly don't think it's better than what we have -- it's worse.
"svn log" used to print the weekday name; with this change, it
doesn't. That's bad. I depend on that weekday name all the time,
surely I can't be the only one. That output is substantially less
useable without the name.
> Certainly to store the data this way in BDB makes
> eminent sense. Storing weekday information is useless, that can be
> easily calculated. (Esp. if the weekday needs to get converted into a
> non-Gregorian calendar like the Hebrew calendar.)
Sure, there's no need to store the weekday name, completely agree.
> What needs to happen later is that SVN needs to suck in as many OS
> specific data about what the end user's date/time formatting preferences
> are and use those. Sounds like a job for APR if you ask me.
Yes, we should do that. But in the absence of environmental clues, we
should default to the most useable possible format.
<mantra>
Giving the user the ability to customize doesn't absolve us from
the responsibility of choosing good defaults for the non-customized
case.
</mantra>
:-)
If it's a matter of disagreement over whether the weekday name and/or
month name makes the format more useable, that's fine. But I don't
know (or don't *think* I know) anyone who prefers not to have those
words when eye-parsing a date. They're so dang helpful. If we lose
them, we're simply getting worse, IMHO.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: [PATCH] Unify human represented timestamp formats.
Posted by Bill Tutt <ra...@lyra.org>.
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
>
> Hmmm. I'm beginning to wonder if we don't really need a date format
> string with %-codes, settable from .subversion/config or
> something...
Err, (IIRC) the reason Nuutti's suggesting one and only one format is
because this realease (1.0) isn't focused on il8n. The format he
suggested isn't going to make everybody happy, but it's (IIRC) better
than what we have. Certainly to store the data this way in BDB makes
eminent sense. Storing weekday information is useless, that can be
easily calculated. (Esp. if the weekday needs to get converted into a
non-Gregorian calendar like the Hebrew calendar.)
What needs to happen later is that SVN needs to suck in as many OS
specific data about what the end user's date/time formatting preferences
are and use those. Sounds like a job for APR if you ask me.
FYI,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Unify human represented timestamp formats.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Nuutti Kotivuori <na...@iki.fi> writes:
> I made a patch which adds a new function, svn_time_to_human_nts, and
> then uses it for the places where the date format is mangled for user
> display.
>
> The actual format of the date stamps is:
> 2002-06-22 11:14:42 +03:00
I'd add weekday in there, it's very important, IMHO (I'm sorry if I
didn't say that when you were earlier soliciting comments on date
formats, it was just an oversight.)
Yes, I know this theoretically opens up a whole can of worms about
non-English day and month names. But, intercultural offensiveness
aside, it's *really convenient* to have even just the English, and a
lot of people in the world understand the short English abbreviations
"Mon", "Tue", etc.
> The format can - and should - be changed if a real consensus is gotten
> for the format.
Okay, I'd like to propose:
Sat 2002-06-22 11:14:42 +03:00
Personal aside: I suspect this might be hard to get consensus on, but
really the ideal thing for human readability (or at least
English-reader readability) would be to use the month name as well, as
in:
Sat 22 Jun 2002 11:14:42 +03:00
That's _slightly_ more complicated for automated parsers, though, so
personally I'd have no problem with a redundant format like:
Sat 22 Jun 2002-06-22 11:14:42 +03:00
...but I suppose that would cause much gnashing of teeth and hurling
of sticks and stones, right?
> The dubious part is 'svnlook'. Should that use this same function?
> This means that TZ needs to be set very carefully for it. I'd want
> some input on this.
Oh, the question is, should it print dates in the server's local
timezone, or should it print exactly what is stored in the repository
(which is probably GMT, or maybe some other non-local timezone)?
<thinks>
You know, I think we need both options. I'm not sure which should be
the default, though.
Hmmm. I'm beginning to wonder if we don't really need a date format
string with %-codes, settable from .subversion/config or
something...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org