Jonathan Nieder <jrnieder@xxxxxxxxx> 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?
