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: > GIT_COMMITTER_DATE="31 Dec 23:59:60 1969 +0100" git commit -m "Begs sharable holistic policy" --date "10 Apr 02:42:06 1970 +0100" 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
