Shengfa Lin <shengfa@xxxxxxxxxx> writes: >> 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. Yup. > If we have a setting of "core.recordTimeZone", do we need to make it > as a command option as Junio suggested earlier? Usually we add command line option --[no-]record-time-zone first without configuration option when introducing a new features like this one. Once the feature proves useful, we'd add a matching configuration variable for convenience, but leave the command line option (negative form in this case) so that a configured per-user default can be overridden as needed.
