threads / discuss / 62920

Config timezone to prevent chaos when DST/changing timezone

Subject: Config timezone to prevent chaos when DST/changing timezone

## tl;dr

4 messages between Feb 7, 2025 and Feb 8, 2025.

replies: 3people: 4as markdown or json

Devste Devste· Feb 7, 2025, 22:02 UTC · lore

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.

I found the discussion about user.hideTimezone https://public-inbox.org/git/CAEOYnAQYMrNAe9s1V-0DVLdL-B_KpHMDP5e=yRnbCkMWdrvFHQ@mail.gmail.com/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

brian m. carlson· Feb 7, 2025, 22:47 UTC · re: Devste Devste · lore

Re: Config timezone to prevent chaos when DST/changing timezone

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.

Show 13 quoted lines
> I found the discussion about user.hideTimezone
> https://public-inbox.org/git/CAEOYnAQYMrNAe9s1V-0DVLdL-B_KpHMDP5e=yRnbCkMWdrvFHQ@mail.gmail.com/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
Andreas Schwab· Feb 8, 2025, 09:28 UTC · re: Devste Devste · lore

Re: Config timezone to prevent chaos when DST/changing timezone

On Feb 07 2025, Devste Devste wrote:
> 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.

The time stamps in commits are recorded in Universal Time, so neither DST nor timezone changes (both are essentially equivalent) have an influence on how the time stamp is interpreted as a point in time.

> There should be an easy way to force a specific timezone - or in
> absence of that at least force UTC - to prevent this

You can use --date=local to show all dates in your local time zone, instead of the recorded time zone of the author/committer.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Junio C Hamano· Feb 8, 2025, 21:54 UTC · re: Andreas Schwab · lore

Re: Config timezone to prevent chaos when DST/changing timezone

Andreas Schwab <schwab@linux-m68k.org> writes:
Show 9 quoted lines
> On Feb 07 2025, Devste Devste wrote:
>
>> 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.
>
> The time stamps in commits are recorded in Universal Time, so neither
> DST nor timezone changes (both are essentially equivalent) have an
> influence on how the time stamp is interpreted as a point in time.

The commits will be sorted correctly according to time, regardless of the recorded timezone. Thanks for pointing it out.

← back to recent threads