Re: [PATCH/RFC] New date format: local_original

Jeff King [off-list ref] 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 [off-list ref]
  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.