On Wed, Sep 02, 2015 at 08:16:59AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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. -- 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