Jeff King <peff@xxxxxxxx> writes:
> If the former, then should the options be orthogonal? That is, should it
> be a new format combining the two, or should it be an option to show, in
> your preferred format, the time in both local and original time zones?
> E.g., something like:
>
> $ git log --date=iso --local-dates-too
> commit bf01a69ed40e1afcf56aff143f7523da2ce263ed
> Author: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
> Date: 2009-10-04 00:41:55 +0200
> Local: 2009-10-03 17:41:55 -0500
>
> And then you can use it with "normal" dates, iso dates, rfc2822 dates,
> etc.
Thanks for comments.
I think "--date=iso --local-dates-too" is still not orthogonal enough, let
alone "local_original" which invites "Why is this combination supported
and not this, that, and 47 others?" questions.
I however do not think it is so bad an idea to allow something like:
git log --date='custom:%Y-%m-%d ...'
git log --date=custom ;# looks at "date.custom" config
You (not Peff, but figuratively whoever wants to implement it) can add a
mechanism to specify in which timezone (original or local) you would want
the timestring to be given, and make what Tuomas's RFC patch does a mere
special case. For example, we could reuse 'date "+format"' string with
our own extension %{magic}, with two magic tokens initially defined:
%{local} interpret timestamp in local zone from now on
%{original} interpret timestamp in the original zone from now on
With such a mechanism Tuomas can define:
[date]
custom=%{local}%a %Y-%m-%d %H:%M:%S %{original}(%a %H:%M:%S %z)
and ask "git log --date=custom" to get what his patch does.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html