Subject: Re: [PATCH v2 0/6] Make "local" orthogonal to date format

From: John Keeping <[email-masked]>
Date: Wed, 2 Sep 2015 20:49:46 +0100

On Wed, Sep 02, 2015 at 08:16:59AM -0700, Junio C Hamano wrote:
> Jeff King <[email-masked]> writes:
> 
> > On Wed, Sep 02, 2015 at 08:48:26AM +0100, John Keeping wrote:
> >
> >> On Tue, Sep 01, 2015 at 06:44:31PM -0400, Jeff King wrote:
> >> > [1] I do think the error message for "relative-local is nonsense" could
> >> >     perhaps be more explanatory, but I couldn't come up with any better
> >> >     wording. But if you have ideas, feel free to switch it.
> >> 
> >> My only suggestion would be to reuse the "unknown date format: %s"
> >> message and avoid having a special message in this case.
> >
> > Heh, that was what I was trying to avoid. I wanted to avoid "I do not
> > understand our request" and have it more like "I understand what you're
> > _trying_ to do, but it doesn't make sense".
> >
> > I guess "relative dates do not depend on timezones, so -local is
> > meaningless" would be the closest thing.
> >
> > I don't think it is that big a deal whichever way we go, though.
> 
> I somehow thought that the discussion was about raw-local, not
> relative-local, but anyway, I think it would make more sense to
> allow both of them.  If you define the meaning of "-local" as:
> 
>     Pretend that the event in question was recorded with your
>     timezone, and show the timestamp using the specified format sans
>     -local suffix.
> 
> that explains what happens for all the other formats well, and it
> also makes sense for what would happen to raw and even relative, I
> think.

The discussion about "raw-local" was in a separate subthread, I think
we're just bikeshedding the particular error message here.

OTOH, I don't think there's any disagreement about what "relative-local"
and "raw-local" would output were they supported, just whether they are
useful.  There doesn't seem to be any harm in supporting them;
"relative-local" will be identical to "relative" and "raw-local" will
require preparatory code movement for the raw output.