On 2025-02-07 at 22:02:19, Devste Devste wrote: > Issue: > With DST or manual timezone changes (e.g. travelling) you can end up > with commits that are illogically sorted - newer commits have an > author/committer date that is older than older commits. First of all, if the date and time displayed as local, it is very easy already, without traveling, to end up with one time of a later commit before the other (ignoring the time zone) simply because different people are in different time zones. I'm sure I could give you a large number of examples in a variety of projects. Second, Git doesn't guarantee a strict ordering of author or committer date in timestamps. It is very possible with a rebase to place commits with newer author timestamps before ones with older timestamps because they logically go in that order. And we don't force users to contact an NTP server or other reliable time source, so some people just have bad timestamps altogether. > I found the discussion about user.hideTimezone > https://public-inbox.org/git/CAEOYnAQYMrNAe9s1V-0DVLdL-B_KpHMDP5e=yRnbCkMWdrvFHQ@xxxxxxxxxxxxxx/T/#u > and > https://git.github.io/rev_news/2023/08/31/edition-102/ > > While there are workarounds, these aren't possible in all cases (e.g. > "export TZ=UTC0" won't work with many IDEs since they run git in a > separate shell and has side-effects on non-git commands. Using > pre/post-commit/rewrite/merge hooks won't guarantee it's correct e.g. > if bypassing them if there checks in there that should be skipped) > > There should be an easy way to force a specific timezone - or in > absence of that at least force UTC - to prevent this The standard way to set the timezone is setting `TZ`. You can set it in your `GIT_EDITOR` environment variable, which will be passed to the shell, like so: export GIT_EDITOR="TZ=UTC vi" (or the `core.editor` value, or any other approach). This will invoke the editor with the appropriate value so it works correctly. Part of the problem with setting it in Git is that Git doesn't actually have a way to set the timezone other than the `TZ` environment variable because POSIX doesn't offer other approaches for doing so (or, for that matter, enumerating valid values or verifying a value). In addition, Windows uses a different, completely incompatible set of time zone names from everyone else on the planet, so such a setting would not work gracefully in a cross-platform way for arbitrary time zones. For these reasons, reading an arbitrary time zone from the configuration would require setting `TZ` internally and then calling `tzset`, but that function is not thread safe, which substantially restricts the places configuration parsing and handling can be done in our code. It would also create a bunch of headaches if we tried to load submodules repository data in the same process (which is an eventual goal), leading to hard-to-reproduce problems. In my case, I always set `TZ=UTC` in my `.zshenv` and I specifically invoke my shell in `~/.Xsession` before starting the session manager. For instance: zsh -c 'mate-session' This ensures that all programs are started with the `PATH`, `TZ`, and locale values I want for them, including graphical programs. If you don't do that, then graphical programs you start outside of a terminal also don't honor `PATH` or locale settings (for instance, I always force `LC_TIME=en_DK.UTF_8`, which I want for graphical programs as well). As for hooks not working, if you have a policy requirement to use UTC, then check for that in your server `pre-receive` hook or CI system, where those can be used as an effective control, as the Git FAQ mentions. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
