Config timezone to prevent chaos when DST/changing timezone

Config timezone to prevent chaos when DST/changing timezone

[Devste Devste]

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3805 bytes --]

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@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Andreas Schwab]

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."

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

[Junio C Hamano]

Andreas Schwab <schwab@linux-m68k.org> writes:

> 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.