Re: [RFC PATCH 0/1] adding user.hideTimezone for setting UTC timezone

From: Shengfa Lin <shengfa@google.com>
Date: Oct 2, 2020, 21:42 UTC
Message-ID: <20201002214251.76114-1-shengfa@google.com>
In-Reply-To: <xmqqtuved70y.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

>> [...]

Show 10 quoted lines

> Regarding the implementation, the posted patch to "git commit" uses
> the "futz with TZ early inside the git process" approach, but I
> think we should not do so for another reason.  Our setenv() may not
> be early enough---before the code that decides to call a setenv()
> is run, there are many things that are outside your control (like
> the tracing subsystem, repository discovery, etc.) will run, and if
> any of them does something that triggers tzset() to be called, it
> will be done with the value of TZ the process started with, and our
> setenv() that happens much later won't have any effect to it.
>

Setenv for TZ early in the git process even at the beginning of cmd_main does not set TZ for things run earlier. In this sense, user setting TZ themselves would be consistent. On the other hand, we may not require "things" run earlier to have consistent TZ depending on whether user time would be exposed.

> Another thing is that setting TZ ourselves would affect hooks and
> other programs we spawn as subprocess, which may or may not be
> desired, depending on the reason why the user is forcing UTC.
>

Should not setenv for TZ bluntly because of risk of undesired side effect

Show 8 quoted lines

> All code that create object headers like committer, author and
> tagger lines use the same git_author_info() and git_committer_info()
> API, I think, which eventually goes to fmt_ident(), and they produce
> a pair <number of seconds since epoch, offset>.  This gives us an
> entirely different opening to tackle this issue from, because the
> "number of seconds since epoch" part won't change the value no
> matter what timezone you are in.
>

A good candidate for handling in a centralized and controllable manner.

> You can let the existing code produce its natural result and then
> when the "force UTC" flag is set, override the offset part to +0000
> if and only if the timezone was obtained from the current
> environment (this if-and-only-if is necessary, because you do not

I don't understand "if the timezone was obtained from the current environment. How do we tell? getenv("TZ")?

Show 6 quoted lines

> want to rewrite and force UTC when you run "git commit --amend"
> without the "--reset-author" option to update a commit that was
> created somewhere else to UTC).  That way, we do not have to futz
> with TZ environment or tzset.
> 
> Just something to think about.

Does this mean we need to make sure "git commit --amend" without the "--reset-author" will not trigger regeneration of timestamp through datestamp in "date.c" but with the "--reset-author", it will?

Preferable not to futz with TZ environment.