From: Shengfa Lin <shengfa@google.com>
To: jrnieder@gmail.com
Cc: git@vger.kernel.org, gitster@pobox.com, nathaniel@google.com,
rsbecker@nexbridge.com, santiago@nyu.edu, shengfa@google.com
Subject: Re: [RFC PATCH 0/1] adding user.hideTimezone for setting UTC timezone
Date: Fri, 2 Oct 2020 21:56:56 +0000 [thread overview]
Message-ID: <20201002215656.80643-1-shengfa@google.com> (raw)
In-Reply-To: <20201001034350.GB2930867@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> 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.
>
> I thought about this before, but in fact it's okay: when calling a
> function like localtime() (though not localetime_r() --- see my other
> reply), tzset() is called each time so it is able to reflect any
> updates to the TZ envvar from the interim.
>
My understanding is that it's concerning that setenv may not be early
enough that not all things have the same TZ; thus, it's still possible
to expose the user timezone.
> [....]
>
> In addition to not having to futz with TZ, I think I like the
> semantics better. The motivation that started this thread was not so
> much "I want to set a custom timezone to blend in" but rather "why are
> we recording the timezone at all here?" In that context, it makes
> sense to me to have a setting such as
>
> core.recordTimeZone
>
> that I can turn *off* to say that I don't think datestamp() callers
> should consider the timezone to be information worth recording (and
> instead they should write +0000). To me that seems a little simpler
> to understand than user.hideTimezone since this focuses on turning
> some functionality off (recording of the time zone) instead of turning
> on a new stealth mode.
>
> Thanks,
> Jonathan
+1, simpler to understand.
Using user.hideTimezone because user is
trying to hide timezone sounds a little off; directly instructing the
system is more straight forward.
If we have a setting of "core.recordTimeZone", do we need to make it
as a command option as Junio suggested earlier?
next prev parent reply other threads:[~2020-10-02 21:57 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 17:14 [ISSUE] Stop accessing, storing, and sharing the user's time zone Nathaniel Manista
2019-12-05 17:31 ` Junio C Hamano
2019-12-05 17:33 ` Randall S. Becker
2019-12-05 17:43 ` Junio C Hamano
2019-12-05 17:53 ` Santiago Torres Arias
2019-12-05 18:00 ` Randall S. Becker
2020-09-30 23:21 ` [RFC PATCH 0/1] adding user.hideTimezone for setting UTC timezone Shengfa Lin
2020-09-30 23:21 ` [RFC PATCH 1/1] hideTimezone: add a user.hideTimezone config Shengfa Lin
2020-09-30 23:41 ` Junio C Hamano
2020-10-01 0:17 ` Junio C Hamano
2020-10-02 6:07 ` Shengfa Lin
2020-10-01 0:31 ` Junio C Hamano
2020-10-01 0:35 ` Junio C Hamano
2020-10-02 6:41 ` Shengfa Lin
2020-10-02 6:46 ` Shengfa Lin
2020-10-02 6:37 ` Shengfa Lin
2020-10-02 6:02 ` Shengfa Lin
2020-10-02 6:15 ` Jonathan Nieder
2020-10-02 22:32 ` Shengfa Lin
2020-10-03 4:57 ` Junio C Hamano
2020-09-30 23:55 ` Junio C Hamano
2020-10-02 6:51 ` Shengfa Lin
2020-10-01 0:05 ` Junio C Hamano
2020-10-01 2:44 ` Jonathan Nieder
2020-10-02 21:17 ` Shengfa Lin
2020-09-30 23:53 ` [RFC PATCH 0/1] adding user.hideTimezone for setting UTC timezone Junio C Hamano
2020-10-01 2:17 ` Junio C Hamano
2020-10-01 3:43 ` Jonathan Nieder
2020-10-01 15:48 ` Junio C Hamano
2020-10-08 19:49 ` Junio C Hamano
[not found] ` <CAEOYnASgxCE5NjhoSgDwyQyAmdLhw5UyFq_Fu==8q7y6uXGz6w@mail.gmail.com>
2020-10-09 16:48 ` Junio C Hamano
2020-10-02 21:56 ` Shengfa Lin [this message]
2020-10-02 22:06 ` Junio C Hamano
2020-10-03 3:50 ` Shengfa Lin
2020-10-03 4:42 ` Junio C Hamano
2020-10-03 19:53 ` brian m. carlson
2020-10-03 22:14 ` Junio C Hamano
2020-10-02 21:42 ` Shengfa Lin
2020-10-02 21:23 ` Shengfa Lin
2020-10-13 5:28 ` [WIP v2 0/2] experiment with commit option record-time-zone Shengfa Lin
2020-10-13 5:28 ` [WIP v2 1/2] Adding a record-time-zone command option for commit Shengfa Lin
2020-10-13 20:03 ` Junio C Hamano
2020-10-21 5:01 ` Shengfa Lin
2020-10-21 18:55 ` Junio C Hamano
2020-10-22 16:27 ` Junio C Hamano
2020-10-26 4:14 ` Shengfa Lin
2020-10-13 5:28 ` [WIP v2 2/2] Demonstrate failing and passing tests Shengfa Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201002215656.80643-1-shengfa@google.com \
--to=shengfa@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=nathaniel@google.com \
--cc=rsbecker@nexbridge.com \
--cc=santiago@nyu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.