Date and time processing issue

Hi all,

Context: 

I’m preparing an example repo to be used as an example and for exercises for a tutorial I’m preparing set in time travel story, which should explain why I’m doing what I’m doing).

For this I am using the environement variable 'GIT_COMMITTER_DATE' and the '—date’ option to set these time stamps.

Observartion: 

When attempting to commit changes in some cases the following error is reported:

fatal: invalid date format: 31 Dec 23:59:60 1969 +0100

A second later, thigs work as I expect:

 > GIT_COMMITTER_DATE="01 Jan 00:00:00 1970 +0100" git commit -m "Begs sharable holistic policy" --date "10 Apr 02:42:06 1970 +0100"

[main 4fc6ea0] Begs sharable holistic policy

How to reproduce:

$ mkdir tmp
$ cd tmp
$ git init
Initialized empty Git repository in …/tmp/.git/
$ echo "Some content" > non-empty-file.txt
$ git add .
$ GIT_COMMITTER_DATE="31 Dec 23:59:60 1969 +0100" git commit -m "Demo commit" --date "12 Dec 23:59:60 1969 +0100"
fatal: invalid date format: 31 Dec 23:59:60 1969 +0100
$ GIT_COMMITTER_DATE="01 Jan 00:00:00 1970 +0100" git commit -m "Demo commit" --date "01 Jan 00:00:00 1970 +0100"
[main (root-commit) a5c7d72] Demo commit
 Date: Thu Jan 1 00:00:00 1970 +0000
 1 file changed, 1 insertion(+)
 create mode 100644 non-empty-file.txt

The same lines from a short shell script:

$ cat reproduction_sctipt.sh mkdir tmp cd tmp git init echo "Some content" > non-empty-file.txt git add . GIT_COMMITTER_DATE="31 Dec 23:59:60 1969 +0100" git commit -m "Demo commit" --date "12 Dec 23:59:60 1969 +0100" GIT_COMMITTER_DATE="01 Jan 00:00:00 1970 +0100" git commit -m "Demo commit" --date "01 Jan 00:00:00 1970 +0100"

System & version info:

Git version: 2.45.2
OS: macOS Sonoma 14.6 x86_64
Shell: zsh 5.9

(My) Interpretation:

To me, the error message is at least misleading. It also seem to be hidin the underlying issue that git (commit) doesn’t accept time stamps before the epoch.

Given that 1970-01-01 00:00:00 seems to be the lower boundary, I expected some time in 2038-01-19 to be the corresponding upper boundary. However the same error message is given when the date is >= 2100-01-01 00:00:00.

Personally, I think that at least the error message is misleading. (I’d say it’s a bug, if one that’s not particularly likely to run into). I expect the error message to point to the real problem, which is not a wrong date format, but the value the timestamp represents.

I’d also expect that correctly formatted time stamps containing valid date & time information should be processed correctly. (at least for dates after Friday 15 October 1582 (as the day before was Thursday 4 October 1582)

Am I doing it wrong? Is it a bug? Am I expecting too much? Can I do anything to make a wider date range available?

Best regards

Stephan