Re: orthogonal cases of log --date option
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 5, 2009, 22:21 UTC
- Message-ID
- <7vy6vjy5js.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <20090305211120.GB20157@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yep, it is more invasive. But I consider it more maintainable in the > long run.
Why do you think it is more confusing to ask "--date=local --date=iso" than asking "--local-time --date=iso"? If the patch under discussion were not mine, I would have said that --date=local that flips the "lie about timezone" bit and tells us to use the "default" format is a brilliant and elegant solution.
I honestly do not see the point of what you are proposing to make "selector" and "format" independent; unless you are shooting for "--use-tz=Indian/Christmas --date=iso", that is.
The "--use-tz=zonename" might make some sense. The required change would look more like:
(1) Introduce:
const char *force_output_tz;
that defaults to NULL;
(2) Option parser for --use-tz=Indian/Christmas would store
arg+9 to force_output_tz; (3) Option parser for --date=local would set the date format to
"default", and store "localtime" to force_output_tz. We discard
DATE_LOCAL enum.(4) In show_date(), instead of
if (mode == DATE_LOCAL) tz = local_tzoffset(time);
you'd do:
if (forced_output_tz) tz = zonename_to_tzoffset(time, force_output_tz);
zonename_to_tzoffset() would look up the zoneinfo database and
compute the offset in our internal (hour*100+min) format.But I do not think that is what you were proposing.