You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/06/24 17:17:38 UTC
RFC: a human-eye date format everyone can love
Please read "RFC" as "Request For Consensus"... :-)
Now that Hadaka has committed the bulk of the new date output code, we
should decide on a human-output date format. Currently, svn is
printing:
"Mon, 24 Jun 2002 10:36:04 -0500"
...but we all know this is just a placeholder until we figure out what
we really want. On IRC just now, Hadaka came up with a neat solution,
which we'd like to propose together:
"2002-06-24 10:36:04 -0500 (Mon 24 Jun)"
The goal of this format is to start with an ISO-8601 section (and
perhaps compliant with some other standards as well), followed by a
clearly delimited second section intended for human consumption.
Automatic parsers will only read as many chars as they need, since
they know the width of the standard-compliant date. Meanwhile,
English-reading humans can look at the second section to do faster
mental processing. Everybody wins.
Furthermore, since the second section is ignored by automatic
processors, we can make it locale-sensitive, so non-English-readers
can get friendly output too.
The main disadvantage here is that this format is slightly longer than
the old one. We don't see a big problem, though; it's still short
enough that it keeps log output well within an 80-column line. IOHO
the extra information is worth it.
NOTE: If I made any errors in formatting the first part of the date
above, please point them out. We certainly intend to propose
standards-compliance in that portion. Hadaka points out that the
space before the "-0500" might be illegal; in that case, I'm +1 on
keeping the space anyway for readability, also +1 on eliminating it
for compliance :-) ).
Thoughts?,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> +1, perhaps this discussion will finally end.
>
> I find it most amusing that the display date format is *the* most
> controversial subject in Subversion. Talk about bikesheds ... :-)
:-)
Seriously: I don't think "bikeshed" is synonymous with "unimportant".
What makes this a bikeshed is that many people have enough background
to post a opinion with confidence. It doesn't mean the issue isn't
important. In general, the length of the thread has no correlation
with the importance of the issue, as far as I can tell, because the
*complexity* of an issue has no correlation with its importance.
Bikesheds are a slippery thing, more deep than amusing IMHO. If you
think you know a good solution to problem X, but you find that many
other people also think they have good solutions, you have two
choices: you can either participate in a long discussion, or default
to allowing all controversial issues like X to be decided by those who
are willing to discuss them the longest. Thus you can end up with all
the trivial and/or comprehensible issues (two unrelated categories)
being decided by a rather random process.
So I try not to "time out" just because I'm tired, and hope others
will do the same. These threads can get long, but they usually lead
to good results. Certainly did in this case, I think.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a human-eye date format everyone can love
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>Please read "RFC" as "Request For Consensus"... :-)
>
>Now that Hadaka has committed the bulk of the new date output code, we
>should decide on a human-output date format. Currently, svn is
>printing:
>
> "Mon, 24 Jun 2002 10:36:04 -0500"
>
>...but we all know this is just a placeholder until we figure out what
>we really want. On IRC just now, Hadaka came up with a neat solution,
>which we'd like to propose together:
>
> "2002-06-24 10:36:04 -0500 (Mon 24 Jun)"
>
>The goal of this format is to start with an ISO-8601 section (and
>perhaps compliant with some other standards as well), followed by a
>clearly delimited second section intended for human consumption.
>
+1, perhaps this discussion will finally end.
I find it most amusing that the display date format is *the* most
controversial subject in Subversion. Talk about bikesheds ... :-)
--
Brane Čibej <br...@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
Re: RFC: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > "2002-06-24 10:36:04 -0500 (Mon 24 Jun, 2002)"
> >
> > Otherwise +1.
> +1 on adding the year (could live without the comma, but whatever).
Sure, +1 with or without the year (I don't feel strongly either way).
Agree about the comma.
It's getting a bit long, though. Here's some sample log output:
------------------------------------------------------------------------
rev 2322: sussman | 2002-06-24 10:36:04 -0500 (Mon 24 Jun 2002) | 5 lines
* CHANGES: reformatting so that each change is one line. No offense
to gstein -- he did a great job of summarizing -- I'm just trying to
keep this changelog consistent. :-)
------------------------------------------------------------------------
Do you _still_ want the year in the second portion? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a human-eye date format everyone can love
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Mon, Jun 24, 2002 at 10:52:37AM -0700, Blair Zajac wrote:
> Karl Fogel wrote:
> >
> > Please read "RFC" as "Request For Consensus"... :-)
> >
> > Now that Hadaka has committed the bulk of the new date output code, we
> > should decide on a human-output date format. Currently, svn is
> > printing:
> >
> > "Mon, 24 Jun 2002 10:36:04 -0500"
> >
> > ...but we all know this is just a placeholder until we figure out what
> > we really want. On IRC just now, Hadaka came up with a neat solution,
> > which we'd like to propose together:
> >
> > "2002-06-24 10:36:04 -0500 (Mon 24 Jun)"
>
> I'd like the year in the second human section. My eye now reads the
> year from the first section and then jumps to the second section to
> pick up the day and month.
>
> "2002-06-24 10:36:04 -0500 (Mon 24 Jun, 2002)"
>
> Otherwise +1.
+1 on adding the year (could live without the comma, but whatever).
>
> Blair
>
> --
> Blair Zajac <bl...@orcaware.com>
> Web and OS performance plots - http://www.orcaware.com/orca/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: RFC: a human-eye date format everyone can love
Posted by Blair Zajac <bl...@orcaware.com>.
Karl Fogel wrote:
>
> Please read "RFC" as "Request For Consensus"... :-)
>
> Now that Hadaka has committed the bulk of the new date output code, we
> should decide on a human-output date format. Currently, svn is
> printing:
>
> "Mon, 24 Jun 2002 10:36:04 -0500"
>
> ...but we all know this is just a placeholder until we figure out what
> we really want. On IRC just now, Hadaka came up with a neat solution,
> which we'd like to propose together:
>
> "2002-06-24 10:36:04 -0500 (Mon 24 Jun)"
I'd like the year in the second human section. My eye now reads the
year from the first section and then jumps to the second section to
pick up the day and month.
"2002-06-24 10:36:04 -0500 (Mon 24 Jun, 2002)"
Otherwise +1.
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a human-eye date format everyone can love
Posted by Nuutti Kotivuori <na...@iki.fi>.
> I think the preference must go to the humans not to the computer.
Well, that is an altogether different argument, which I will not touch
here.
But! I must say that I consider "Mon, 24 Jun 2002 10:36:04" a _lot_
less readable than "2002-06-24 10:36:04". And since some people want
the day of week there, we are back at the same suggestion again. So
that argument, in my opinion, does not matter the time format argument
really - it's more relevant to the question that do we want
_customizable_ time formats (in the future) or not (because those
would break machine readibility big time)?
> 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.
It is translated to the local timezone. The timestamps in the
repository are all UTC. The local timezone is displayed just there so
it is explicit what is meant.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a human-eye date format everyone can love
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 24, 2002 at 12:39:28PM -0700, Justin Erenkrantz wrote:
>...
> Pardon me, but why do we care about producing ISO-8601 dates in
> the human-readable sections?
Because we need to choose a format. And the ISO 8601 format is actually
defined as the European standard (dunno about US). Maybe as a US guy, you
might want alphanumeric day/month in there, but that isn't going to work
well in a universal context.
In short, we need a format that works "everywhere" and ISO 8601 is the best.
The particular format Karl has proposed *is* compatible with ISO 8601 up to
the parenthesized portion.
> 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.
/bin/bash has a very hard time accessing those libraries. A *lot* of
scripting is going to be by invoking the command-line client. As much as I
would agree with you on "use the libraries", I just don't think they'll be
used as often as I'd like.
Yes, we'll have bindings for Perl and Python and others. But will everybody
have those bindings installed? I'd posit a much lower percentage than those
who have the cmdline client. Thus, script writers will tend towards wrapping
the client.
>...
> 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.
The TZ must be appended. Without it, the user doesn't know if the displayed
time is local time, or UTC.
> 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?
They get stored into the repos in UTC. When Sander runs 'svn log', he gets
all the times displayed in +0100 (or whatever his TZ is). That is, they are
adjusted to his local time.
> 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
Nope. See above. It is needed to say, "I've translated this to your time."
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: RFC: a human-eye date format everyone can love
Posted by mark benedetto king <bk...@inquira.com>.
On Mon, Jun 24, 2002 at 02:40:07PM -0500, Karl Fogel wrote:
> 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.
Maybe this is too high a bar to set; the XML output provides a
machine parseable format.
> 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/.
>
This is true, but many programs are probably buggy because they
attempt to parse CVS log output. They'd be a lot more reliable
if they used an XML parser.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
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 <je...@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
Re: RFC: a human-eye date format everyone can love
Posted by Justin Erenkrantz <je...@apache.org>.
On Mon, Jun 24, 2002 at 12:17:38PM -0500, Karl Fogel wrote:
> Please read "RFC" as "Request For Consensus"... :-)
>
> Now that Hadaka has committed the bulk of the new date output code, we
> should decide on a human-output date format. Currently, svn is
> printing:
>
> "Mon, 24 Jun 2002 10:36:04 -0500"
>
> ...but we all know this is just a placeholder until we figure out what
> we really want. On IRC just now, Hadaka came up with a neat solution,
> which we'd like to propose together:
>
> "2002-06-24 10:36:04 -0500 (Mon 24 Jun)"
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
Re: a human-eye date format everyone can love
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 24, 2002 at 04:07:10PM -0500, B. W. Fitzpatrick wrote:
> > gstein@lyra.org wrote:
> > Thus, the format would be (with my suggestion for the paren part):
> >
> > 2002-06-24 13:31:19-0700 (Mon, 24 Jun 2002)
>
> I like that, but it's kind of long. How about
>
> Default:
>
> Mon, 24 Jun 2002
Unfortunately, this doesn't meet the need for a single, universal format.
The non-US people are going to be peeved with this format :-) ISO 8601 is
universal.
> Verbose:
>
> 2002-06-24 13:31:19-0700 (Mon, 24 Jun 2002)
>
> We've got the verbose flag, let's use it!
Unfortunately, "verbose" for 'svn log' means to print out the paths that
were affected in each commit.
To get what you what, you'd need --verbose-log and --verbose-date-format.
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: time format wrap-up? (was: a human-eye date format everyone can love)
Posted by Josef Wolf <jw...@raven.inka.de>.
On Tue, Jun 25, 2002 at 02:09:32AM -0700, Greg Stein wrote:
> Okay. I count four +1 votes on this customizibility: Kirby, myself, Justin,
> and Karl. Nobody has provided any "less than 1" votes. Sounds like a plan :-)
+1 from me, too.
> IMO, one small consideration is whether a user-format will screw up the
> parsing of stuff *after* the date. For example:
>
> rev 2200: gstein | 2002-06-13 19:08:43-0700 | Thursday | 39 lines
Why not put the date at end of the line? Or even on its own line?
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: time format wrap-up?
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 25, 2002 at 07:52:26PM +0300, Nuutti Kotivuori wrote:
>...
> I'll be coding the change right now to that format - and I'll
> hopefully use apr_strftime to implement the latter part, so once the
> config file works, customization is a breeze!
Note that libsvn_subr probably can't just grab the extra format out of thin
air. You will probably need another param to the _human_nts() function, and
callers can supply it (pulling it from the config) or just pass NULL if they
don't have it.
It might mean some propagation of formats thru a few APIs, but hopefully
that can be minimized.
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: time format wrap-up? (was: a human-eye date format everyone can love)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 25, 2002 at 12:37:19PM +0200, Gerald Richter - ecos gmbh wrote:
>...
> For human readability I find it really hard to read with the timezone append
> directly to the time:
>
> 2002-06-13 19:08:43-0700
>
> I personaly find it much better with an extra space
>
> 2002-06-13 19:08:43 -0700
>
> Gerald
>
> P.S. Forget about it in case I missed something in this long thread and this
> was discussed earlier...
ISO 8601 forbids the space in there.
Of course, we can still choose whatever we want:
1) ISO 8601 compat. no space.
2) ISO 8601 tweaked. include a space.
Personally, I'm in favor of compatibility.
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: time format wrap-up? (was: a human-eye date format everyone can love)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Discussion *always* remains open, so if you have further comments or
> concerns, then bring them up. I would recommend that Nuutti proceed along
> this plan because it is (at least) a bit closer to consensus than the
> current code.
+1, thanks for the wrap-up Greg.
(I also think ISO compatibility is the way to go in the first portion;
that is, no space before the timezone.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: time format wrap-up? (was: a human-eye date format everyone can love)
Posted by Gerald Richter - ecos gmbh <ri...@ecos.de>.
>
> Discussion *always* remains open, so if you have further comments or
> concerns, then bring them up. I would recommend that Nuutti proceed along
> this plan because it is (at least) a bit closer to consensus than the
> current code.
>
For human readability I find it really hard to read with the timezone append
directly to the time:
2002-06-13 19:08:43-0700
I personaly find it much better with an extra space
2002-06-13 19:08:43 -0700
Gerald
P.S. Forget about it in case I missed something in this long thread and this
was discussed earlier...
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: time format wrap-up? (was: a human-eye date format everyone can love)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Nuutti Kotivuori <na...@iki.fi> writes:
> I'll be coding the change right now to that format - and I'll
> hopefully use apr_strftime to implement the latter part, so once the
> config file works, customization is a breeze!
I've added a note about that to issue #668.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: time format wrap-up? (was: a human-eye date format everyone can
love)
Posted by Nuutti Kotivuori <na...@iki.fi>.
Greg Stein wrote:
> Discussion *always* remains open, so if you have further comments or
> concerns, then bring them up. I would recommend that Nuutti proceed
> along this plan because it is (at least) a bit closer to consensus
> than the current code.
Yes, definitely sounds good.
I'll be coding the change right now to that format - and I'll
hopefully use apr_strftime to implement the latter part, so once the
config file works, customization is a breeze!
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: time format wrap-up? (was: a human-eye date format everyone can love)
Posted by Sander Striker <st...@apache.org>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: 25 June 2002 11:10
> On Mon, Jun 24, 2002 at 10:48:04PM -0500, Karl Fogel wrote:
>> Justin Erenkrantz <je...@apache.org> writes:
>>> On Mon, Jun 24, 2002 at 07:23:08PM -0700, Greg Stein wrote:
>>>> The next question is what to default for time_fmt if it isn't present in the
>>>> configuration file. :-)
>>>
>>> My vote is for nothing to be printed out in this case. As I pointed
>>> out before, this matches CVS's behavior. My biggest problem with
>>> CVS is that the TZ is that of the server or GMT. -- justin
>>
>> Definitely +1 on doing customizability this way,
>
> Okay. I count four +1 votes on this customizibility: Kirby, myself, Justin,
> and Karl. Nobody has provided any "less than 1" votes. Sounds like a plan :-)
Add my +1 to that aswell.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
time format wrap-up? (was: a human-eye date format everyone can love)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 24, 2002 at 10:48:04PM -0500, Karl Fogel wrote:
> Justin Erenkrantz <je...@apache.org> writes:
> > On Mon, Jun 24, 2002 at 07:23:08PM -0700, Greg Stein wrote:
> > > The next question is what to default for time_fmt if it isn't present in the
> > > configuration file. :-)
> >
> > My vote is for nothing to be printed out in this case. As I pointed
> > out before, this matches CVS's behavior. My biggest problem with
> > CVS is that the TZ is that of the server or GMT. -- justin
>
> Definitely +1 on doing customizability this way,
Okay. I count four +1 votes on this customizibility: Kirby, myself, Justin,
and Karl. Nobody has provided any "less than 1" votes. Sounds like a plan :-)
> and I'm even neutral
> on the question of printing out nothing if the user doesn't specify an
> "extra" format.
Step 2 :-) but noted.
> I would only ask that we print out the extra stuff by default until
> this customizability is implemented, just to humor those who really
> depend on it :-).
Yes.
> (Btw, I think it's fine to change that default output once we *do*
> have the customizability. That would be incompatible only in an
> overly literal sense; the part of the date that is important for
> compatibility purposes -- the first part -- wouldn't be changing.)
Right.
IMO, one small consideration is whether a user-format will screw up the
parsing of stuff *after* the date. For example:
rev 2200: gstein | 2002-06-13 19:08:43-0700 | Thursday | 39 lines
Eek! :-)
But that's a question for later.
Regarding the *temporary* "extra" format (until we get customizability),
I've counted seven emails: myself, Karl, Sander, Blair, cmpilato, Fitz, and
David Mankin. By far, the best support was for:
Mon, 24 Jun 2002
It got 5 +1 votes, a +0, and a -0. Nothing else was even close.
Discussion *always* remains open, so if you have further comments or
concerns, then bring them up. I would recommend that Nuutti proceed along
this plan because it is (at least) a bit closer to consensus than the
current code.
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: a human-eye date format everyone can love
Posted by David Mankin <ma...@ants.com>.
-0 for: 2002-06-26 13:31:19-0700 (Wednesday)
+1 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
+0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
+1 for: 2002-06-26 13:31:19 -0700 (Mon, 26 Jun)
+0 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002, 1:31 pm)
-0 for all others
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Justin Erenkrantz <je...@apache.org> writes:
> On Mon, Jun 24, 2002 at 07:23:08PM -0700, Greg Stein wrote:
> > The next question is what to default for time_fmt if it isn't present in the
> > configuration file. :-)
>
> My vote is for nothing to be printed out in this case. As I pointed
> out before, this matches CVS's behavior. My biggest problem with
> CVS is that the TZ is that of the server or GMT. -- justin
Definitely +1 on doing customizability this way, and I'm even neutral
on the question of printing out nothing if the user doesn't specify an
"extra" format.
I would only ask that we print out the extra stuff by default until
this customizability is implemented, just to humor those who really
depend on it :-).
(Btw, I think it's fine to change that default output once we *do*
have the customizability. That would be incompatible only in an
overly literal sense; the part of the date that is important for
compatibility purposes -- the first part -- wouldn't be changing.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Justin Erenkrantz <je...@apache.org>.
On Mon, Jun 24, 2002 at 07:23:08PM -0700, Greg Stein wrote:
> The next question is what to default for time_fmt if it isn't present in the
> configuration file. :-)
My vote is for nothing to be printed out in this case. As I pointed
out before, this matches CVS's behavior. My biggest problem with
CVS is that the TZ is that of the server or GMT. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 24, 2002 at 06:25:22PM -0500, Kirby C. Bohling wrote:
>...
> My suggestion isn't terribly different then the current one, except that
> instead of using "()", use the field delimiter for the current output
> stream. Rather then try and pick for everyone on the plant what goes in
> the the ()'s just let them specify it thru some controlled manner.
Actually... this is quite nice. Imagine something like this:
std = strftime(standard_fmt, time_data)
extra_fmt = config.get("options", "time_fmt")
if not extra_fmt:
return std
extra = strftime(extra_fmt, time_data)
return apr_pstrcat(pool, std, " ", extra, NULL)
Then a person could do something like:
[options]
# append (Wednesday) to my output dates
time_fmt = (%A)
Another alternative:
# append [Wed, 26 Jun 2002]
time_fmt = [%a, %m %b %Y]
The next question is what to default for time_fmt if it isn't present in the
configuration file. :-)
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: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Kirby C. Bohling" <kb...@birddog.com> writes:
> If you really want to make everybody happy, don't bother with
> consensus, just give everybody personal control and then you don't
> need consensus.
This doesn't really address the issue. It gives people a choice, yes,
but thus it forces them to either make a choice, or live with the
default... In which case our task is the same: to choose a good
default :-).
And as Greg Stein pointed out earlier:
> 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.
I'll happily add "personal experience" to "quite a few studies".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by "Kirby C. Bohling" <kb...@birddog.com>.
Karl,
No panicing... The set with items that have only +0 and +1 is currently
empty. See Sander's and Fitz's mail (I didn't see any single person who
voted -0 on all of them). Nobody voted -1 on anything that I spotted in
a quick review of the thread.
I honestly couldn't care less. I'll only panic if it doesn't have hour,
minute, second, day, month, and a 4 digit year, nearly any sane order
with or without delimiters of any kind. Either spelled out, or
numerical for any of the various values. It just isn't that big a deal
to me personally.
If you really want to make everybody happy, don't bother with consensus,
just give everybody personal control and then you don't need consensus.
My suggestion isn't terribly different then the current one, except that
instead of using "()", use the field delimiter for the current output
stream. Rather then try and pick for everyone on the plant what goes in
the the ()'s just let them specify it thru some controlled manner. Then
people in India, China, Zimbabwa and the aliens from Mar's get to pick
what they want not what the original developers decided was best on a
mailing list w/ several hundred people on it (granted SVN has a very
diverse group from all over the globe, and several people who are
international issue oriented). If you are happy with the ISO format
pick SVN_DATE_FORMAT="", and then the field is blank.
It's merely a suggestion, I'll be more then happy with any of the 3
listed, and I'll be happy with absolutely anything you're +1 or +0 with
Karl. You're lots more particular on this issue then I am. Just
pointing out an alternative is all.
Kirby
Karl Fogel wrote:
> Huh? There's not nearly that much disagreement here :-).
>
> Pretty much everyone has indicated a willingness to live with any of
> four or so variations of the initially proposed format. Now we're
> just counting preferences to see which one to choose. We *already*
> have a highly non-empty set, it's just a matter of narrowing it down
> to a set with one element.
>
> "Don't panic"
>
> :-),
> -K
>
> "Kirby C. Bohling" <kb...@birddog.com> writes:
>
>> Oh well, I might be all wet on this one, as it will be weird
>>to get duplicate dates all the time. If everybody is serious about
>>how much they really need feature "X" in a date give the control to
>>them. It sure seems that the intersection of the +0 +1 set is going
>>to be the empty set.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Huh? There's not nearly that much disagreement here :-).
Pretty much everyone has indicated a willingness to live with any of
four or so variations of the initially proposed format. Now we're
just counting preferences to see which one to choose. We *already*
have a highly non-empty set, it's just a matter of narrowing it down
to a set with one element.
"Don't panic"
:-),
-K
"Kirby C. Bohling" <kb...@birddog.com> writes:
> Oh well, I might be all wet on this one, as it will be weird
> to get duplicate dates all the time. If everybody is serious about
> how much they really need feature "X" in a date give the control to
> them. It sure seems that the intersection of the +0 +1 set is going
> to be the empty set.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by "Kirby C. Bohling" <kb...@birddog.com>.
It would seem easier to just duplicate all dates. Use you're favorite
ISO standard date for one (make it as absolutely short as you can
stand), then allow you to pick your absolute favorite date format for
the other one. For SVN log just print them both in different fields.
Use an enviornment variable, or a config entry for it, and then
everybody gets their very own bikeshed to paint their favorite color.
Sometimes its simpilest to agree to disagree. Pick a sane default for
the human parseable one, people with strong feelings can change it w/ a
strftime complaint string.
In the XML in .svn/entries just have two fields. The second field is
never computer parsed for input, it's only for output. The ISO date is
authoratitive. It's sorta like the whole (), but it is more machine
parsable and you don't have to pick the one true color for the bikeshed.
Oh well, I might be all wet on this one, as it will be weird to get
duplicate dates all the time. If everybody is serious about how much
they really need feature "X" in a date give the control to them. It
sure seems that the intersection of the +0 +1 set is going to be the
empty set.
Thanks,
Kirby
cmpilato@collab.net wrote:
> Greg Stein <gs...@lyra.org> writes:
>
>
>> +1 for: 2002-06-26 13:31:19-0700 (Wednesday)
>> +0 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
>> -0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
>> -0 for all others
>
>
> -0 for: 2002-06-26 13:31:19-0700 (Wednesday)
> +1 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
> +0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
> -0 for all others
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by cm...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> +1 for: 2002-06-26 13:31:19-0700 (Wednesday)
> +0 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
> -0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
> -0 for all others
-0 for: 2002-06-26 13:31:19-0700 (Wednesday)
+1 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
+0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
-0 for all others
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Blair Zajac <bl...@orcaware.com>.
> So. Let's clarify the forms I'm interested in:
>
> +1 for: 2002-06-26 13:31:19-0700 (Wednesday)
> +0 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
> -0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
> -0 for all others
+0 for: 2002-06-26 13:31:19-0700 (Wednesday)
+1 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
-0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: a human-eye date format everyone can love
Posted by Sander Striker <st...@apache.org>.
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: 24 June 2002 23:07
> Greg Stein <gs...@lyra.org> writes:
>> +1 for: 2002-06-26 13:31:19-0700 (Wednesday)
+1
>> +0 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
>> -0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
>> -0 for all others
-0 for the rest.
> Okay, great. Looks like we're narrowing down here.
>
> Let's wait for other responses to trickle in; we should be able to
> commit a format sometime tomorrow.
>
> (I'm +1 on either of of the middle two formats above, as do strongly
> like that month name).
Sander
PS. Greg: +0100 is almost spot on. However, since we are on daylight savings
time it is now +0200.... /me hates timezones...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> +1 for: 2002-06-26 13:31:19-0700 (Wednesday)
> +0 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
> -0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
> -0 for all others
Okay, great. Looks like we're narrowing down here.
Let's wait for other responses to trickle in; we should be able to
commit a format sometime tomorrow.
(I'm +1 on either of of the middle two formats above, as do strongly
like that month name).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 24, 2002 at 03:43:33PM -0500, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
> > 2002-06-24 13:31:19-0700 (Mon, 24 Jun 2002)
>
> +1 on this too.
>
> (Do you feel strongly about the comma? It'd be nice to squeeze as
> much length out as possible, if we're going to include the year
> there.)
I feel pretty strong about that comma, if a date is appended. If it read:
Mon 24 Jun 2002
The eyeball sees alpha-alpha-alpha space num-num space alpha-alpha-alpha.
Those two alpha groups are each three letters, and hard to distinguish
between month and day-of-week. You have to *read* them to really sort it
out. However, with the comma, you've got two distinct groups, and the
eyeball parses it much more easily.
Some test cases:
Wed 20 Nov 2002
Fri 07 Mar 2003
vs
Wed, 20 Nov 2002
Fri, 07 Mar 2003
Which set were easier to read? When my brain reads that, it goes "some word.
pause. day of week. more stuff. parse. date" Without the comma, it goes
"bunch of stuff. parse. parse. parse. day. date." :-)
That said, if we're shooting for shorter, then I'd suggest dropping the
date. I'm quite fine with the date up front, so I don't need it at the end.
However, a three-letter day of week is insufficient to quickly recognize
what is happening there. Thus, we'd need a full day name:
2002-06-24 13:31:19-0700 (Monday)
Wednesday is the longest day, at 9 characters which is shorter than any of
the formats with a date in them.
So. Let's clarify the forms I'm interested in:
+1 for: 2002-06-26 13:31:19-0700 (Wednesday)
+0 for: 2002-06-26 13:31:19-0700 (Mon, 26 Jun 2002)
-0 for: 2002-06-26 13:31:19-0700 (Mon 26 Jun 2002)
-0 for all others
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: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> 2002-06-24 13:31:19-0700 (Mon, 24 Jun 2002)
+1 on this too.
(Do you feel strongly about the comma? It'd be nice to squeeze as
much length out as possible, if we're going to include the year
there.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 24, 2002 at 02:11:57PM -0500, Karl Fogel wrote:
> Hontvari Jozsef <ho...@solware.com> writes:
> > > There are timezones which are on a half-hour alignment, not
> > > whole-hour. (Australian central time, for example.)
> >
> > Yes, in those cases we have to use four digits. But use the shorter form
> > when possible.
>
> But isn't it important to be fixed-width, for the standards-compliant
> portion?
Agreed.
And personally, I find the -0500 to be much more legible. The -05 doesn't
look like a timezone to me. Heck, just look at what my mailer did with the
quoting of Karl's mail above.
Hmm. That raises a point. All the software that I've seen that deals with
timezones will always use 0-padded 4-digit values. While somebody could
certainly find something that shortens to two digits, I'll argue that it is
not "typical".
Let's keep the four digit timezones.
For the () part, I'd suggest the following form:
(Mon, 24 Jun 2002)
i.e. separate the day name from the date; don't embed the comma within the
date portion
Note: the space before the timezone is illegal. According to section 5.3.4.2
of ISO 8601:2000(E), "... shall be appended to the representation of the
local time following immediately, with space, ..."
Thus, the format would be (with my suggestion for the paren part):
2002-06-24 13:31:19-0700 (Mon, 24 Jun 2002)
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: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Hontvari Jozsef <ho...@solware.com> writes:
> > There are timezones which are on a half-hour alignment, not
> > whole-hour. (Australian central time, for example.)
>
> Yes, in those cases we have to use four digits. But use the shorter form
> when possible.
But isn't it important to be fixed-width, for the standards-compliant
portion?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Hontvari Jozsef <ho...@solware.com>.
From: "Stephen Tweedie" <sc...@redhat.com>
> There are timezones which are on a half-hour alignment, not
> whole-hour. (Australian central time, for example.)
Yes, in those cases we have to use four digits. But use the shorter form
when possible.
----- Original Message -----
From: "Stephen Tweedie" <sc...@redhat.com>
To: "Hontvari Jozsef" <ho...@solware.com>
Cc: "Karl Fogel" <kf...@newton.ch.collab.net>; <de...@subversion.tigris.org>
Sent: Monday, June 24, 2002 7:27 PM
Subject: Re: a human-eye date format everyone can love
> Hi,
>
> On Mon, Jun 24, 2002 at 08:06:55PM +0200, Hontvari Jozsef
<ho...@solware.com> wrote:
> > I would shorten the time zone. As we have discussed -05 and -0500 are
> > equivalents.
>
> There are timezones which are on a half-hour alignment, not
> whole-hour. (Australian central time, for example.)
>
> Cheers,
> Stephen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Mon, Jun 24, 2002 at 06:27:30PM +0100, Stephen Tweedie wrote:
> Hi,
>
> On Mon, Jun 24, 2002 at 08:06:55PM +0200, Hontvari Jozsef <ho...@solware.com> wrote:
> > I would shorten the time zone. As we have discussed -05 and -0500 are
> > equivalents.
>
> There are timezones which are on a half-hour alignment, not
> whole-hour. (Australian central time, for example.)
>
Newfoundland time up here in Canada too.
Reminds me of the joke: "The world will end at midnight tonight. (12:30 in
Newfoundland.)" Based on a bunch of TV ads for when shows will be on...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: a human-eye date format everyone can love
Posted by Branko Čibej <br...@xbc.nu>.
Stephen Tweedie wrote:
>Hi,
>
>On Mon, Jun 24, 2002 at 08:06:55PM +0200, Hontvari Jozsef <ho...@solware.com> wrote:
>
>
>>I would shorten the time zone. As we have discussed -05 and -0500 are
>>equivalents.
>>
>>
>
>There are timezones which are on a half-hour alignment, not
>whole-hour. (Australian central time, for example.)
>
Not to mention all of India, which happens to cover 1/4 of the world's
population. :-)
But that's beside the point -- I disagree about shortening the timezone
because the shorter version is harder to parse visually. The time is
laid out in chunks of 2 digits, separated by a colon. If you have
another 2 digits, instead of 4, for the timezone, then I for one will
regolarly read the TZ as the seconds in the time, and shift the other
fields accordingly. Very confusing.
Besides, my understanding is that we want to keep the first,
ISO-compliant part of the timestamp a fxied-width format, to ease parsing.
--
Brane Čibej <br...@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
Re: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Stephen Tweedie <sc...@redhat.com> writes:
> There are timezones which are on a half-hour alignment, not
> whole-hour. (Australian central time, for example.)
This is totally beside the point, but I'd just like to say that I have
been to this zone (Melbourne is in it, right?).
:-),
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Stephen Tweedie <sc...@redhat.com>.
Hi,
On Mon, Jun 24, 2002 at 08:06:55PM +0200, Hontvari Jozsef <ho...@solware.com> wrote:
> I would shorten the time zone. As we have discussed -05 and -0500 are
> equivalents.
There are timezones which are on a half-hour alignment, not
whole-hour. (Australian central time, for example.)
Cheers,
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: a human-eye date format everyone can love
Posted by Hontvari Jozsef <ho...@solware.com>.
I would shorten the time zone. As we have discussed -05 and -0500 are
equivalents.
About the space before the time zone: When I first wrote code which
generates readable iso dates I thought that putting a space before Z makes
the date more readable. But when I started regularly *using* iso dates the
space became inconvenient.
2002-06-24 10:36:04 Z
2002-06-24 10:36:04Z
So I recommend to use the shorter
2002-06-24 10:36:04-05 (Mon 24 Jun)
instead of the longer
2002-06-24 10:36:04 -0500 (Mon 24 Jun)
Anyhow, IMO the new "rfc" is far better then the current format, the
parantheses was a very nice idea.
----- Original Message -----
From: "Karl Fogel" <kf...@newton.ch.collab.net>
To: <de...@subversion.tigris.org>
Sent: Monday, June 24, 2002 7:17 PM
Subject: RFC: a human-eye date format everyone can love
> Please read "RFC" as "Request For Consensus"... :-)
>
> Now that Hadaka has committed the bulk of the new date output code, we
> should decide on a human-output date format. Currently, svn is
> printing:
>
> "Mon, 24 Jun 2002 10:36:04 -0500"
>
> ...but we all know this is just a placeholder until we figure out what
> we really want. On IRC just now, Hadaka came up with a neat solution,
> which we'd like to propose together:
>
> "2002-06-24 10:36:04 -0500 (Mon 24 Jun)"
>
> The goal of this format is to start with an ISO-8601 section (and
> perhaps compliant with some other standards as well), followed by a
> clearly delimited second section intended for human consumption.
>
> Automatic parsers will only read as many chars as they need, since
> they know the width of the standard-compliant date. Meanwhile,
> English-reading humans can look at the second section to do faster
> mental processing. Everybody wins.
>
> Furthermore, since the second section is ignored by automatic
> processors, we can make it locale-sensitive, so non-English-readers
> can get friendly output too.
>
> The main disadvantage here is that this format is slightly longer than
> the old one. We don't see a big problem, though; it's still short
> enough that it keeps log output well within an 80-column line. IOHO
> the extra information is worth it.
>
> NOTE: If I made any errors in formatting the first part of the date
> above, please point them out. We certainly intend to propose
> standards-compliance in that portion. Hadaka points out that the
> space before the "-0500" might be illegal; in that case, I'm +1 on
> keeping the space anyway for readability, also +1 on eliminating it
> for compliance :-) ).
>
> Thoughts?,
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a human-eye date format everyone can love
Posted by Roman Neuhauser <ne...@bellavista.cz>.
> Date: Mon, 24 Jun 2002 12:17:38 -0500 (CDT)
> From: Karl Fogel <kf...@newton.ch.collab.net>
> To: dev@subversion.tigris.org
> Subject: RFC: a human-eye date format everyone can love
>
> Please read "RFC" as "Request For Consensus"... :-)
>
> Now that Hadaka has committed the bulk of the new date output code, we
> should decide on a human-output date format. Currently, svn is
> printing:
>
> "Mon, 24 Jun 2002 10:36:04 -0500"
>
> ..but we all know this is just a placeholder until we figure out what
> we really want. On IRC just now, Hadaka came up with a neat solution,
> which we'd like to propose together:
>
> "2002-06-24 10:36:04 -0500 (Mon 24 Jun)"
>
> The goal of this format is to start with an ISO-8601 section (and
> perhaps compliant with some other standards as well), followed by a
> clearly delimited second section intended for human consumption.
does the first (current) form follow any standard? if so, I'd
prefer that. otherwise, the latter, minus the parenthesized part.
yes, I'm strange (mind you, I have clock on my desktop set up like
so: %Y-%m-%d %H:%M %a), so you can probably ignore me on this. :)
--
FreeBSD 4.6-STABLE
8:06PM up 17:06, 6 users, load averages: 0.06, 0.04, 0.01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a human-eye date format everyone can love
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
David Summers <da...@summersoft.fay.ar.us> writes:
> That seems like a great compromise. If I can vote, I vote +1 on this.
We'd like everyone's opinion, yes!
(Anyway, consensus is different from a vote -- different processes for
different situations. If we can't get a consensus here, then we'll
have to go to a vote, but I have a feeling that won't be necessary in
this case.)
> On Mon, 24 Jun 2002, Karl Fogel wrote:
>
> > Please read "RFC" as "Request For Consensus"... :-)
> >
> > Now that Hadaka has committed the bulk of the new date output code, we
> > should decide on a human-output date format. Currently, svn is
> > printing:
> >
> > "Mon, 24 Jun 2002 10:36:04 -0500"
> >
> > ...but we all know this is just a placeholder until we figure out what
> > we really want. On IRC just now, Hadaka came up with a neat solution,
> > which we'd like to propose together:
> >
> > "2002-06-24 10:36:04 -0500 (Mon 24 Jun)"
> >
> > The goal of this format is to start with an ISO-8601 section (and
> > perhaps compliant with some other standards as well), followed by a
> > clearly delimited second section intended for human consumption.
> >
> > Automatic parsers will only read as many chars as they need, since
> > they know the width of the standard-compliant date. Meanwhile,
> > English-reading humans can look at the second section to do faster
> > mental processing. Everybody wins.
> >
> > Furthermore, since the second section is ignored by automatic
> > processors, we can make it locale-sensitive, so non-English-readers
> > can get friendly output too.
> >
> > The main disadvantage here is that this format is slightly longer than
> > the old one. We don't see a big problem, though; it's still short
> > enough that it keeps log output well within an 80-column line. IOHO
> > the extra information is worth it.
> >
> > NOTE: If I made any errors in formatting the first part of the date
> > above, please point them out. We certainly intend to propose
> > standards-compliance in that portion. Hadaka points out that the
> > space before the "-0500" might be illegal; in that case, I'm +1 on
> > keeping the space anyway for readability, also +1 on eliminating it
> > for compliance :-) ).
> >
> > Thoughts?,
> > -Karl
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
>
> --
> David Wayne Summers "Linux: Because reboots are for upgrades!"
> david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
> PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: a human-eye date format everyone can love
Posted by David Summers <da...@summersoft.fay.ar.us>.
That seems like a great compromise. If I can vote, I vote +1 on this.
- David Summers
On Mon, 24 Jun 2002, Karl Fogel wrote:
> Please read "RFC" as "Request For Consensus"... :-)
>
> Now that Hadaka has committed the bulk of the new date output code, we
> should decide on a human-output date format. Currently, svn is
> printing:
>
> "Mon, 24 Jun 2002 10:36:04 -0500"
>
> ...but we all know this is just a placeholder until we figure out what
> we really want. On IRC just now, Hadaka came up with a neat solution,
> which we'd like to propose together:
>
> "2002-06-24 10:36:04 -0500 (Mon 24 Jun)"
>
> The goal of this format is to start with an ISO-8601 section (and
> perhaps compliant with some other standards as well), followed by a
> clearly delimited second section intended for human consumption.
>
> Automatic parsers will only read as many chars as they need, since
> they know the width of the standard-compliant date. Meanwhile,
> English-reading humans can look at the second section to do faster
> mental processing. Everybody wins.
>
> Furthermore, since the second section is ignored by automatic
> processors, we can make it locale-sensitive, so non-English-readers
> can get friendly output too.
>
> The main disadvantage here is that this format is slightly longer than
> the old one. We don't see a big problem, though; it's still short
> enough that it keeps log output well within an 80-column line. IOHO
> the extra information is worth it.
>
> NOTE: If I made any errors in formatting the first part of the date
> above, please point them out. We certainly intend to propose
> standards-compliance in that portion. Hadaka points out that the
> space before the "-0500" might be illegal; in that case, I'm +1 on
> keeping the space anyway for readability, also +1 on eliminating it
> for compliance :-) ).
>
> Thoughts?,
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
David Wayne Summers "Linux: Because reboots are for upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org