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

the.tester@mac.com writes:

Correct. The error message is prepared for the most common case where people ask for an invalid format, but does not pay attention to the fact that some timestamps are not out of range in the Git timescale and such an out of range timestamp can be fed to the program.

Something along the following line may be a good first step to fix it.

 builtin/commit.c | 2 +-
 ident.c          | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

Yes, that would improve the error message. Would it make sense to create a pull request for this? – If so, should I do it? Or you?, Neither or us?

(That said, I wished I were familiar enough with C, to allow Git processing of a wider range of dates, but I’m not.)

On Fri, Aug 02, 2024 at 11:46:30AM +0200, the.tester@mac.com wrote:

We use an unsigned value (hence the lower bound being at the epoch), so in a 32-bit world the high boundary would be 2106. But we actually use uintmax_t these days, so it's effectively infinite (even no 32-bit systems, there should be _some_ larger type available). But...

...the sloppy tm_to_time_t() code does not handle conversions past 2100 due to the leap year skip there. There's more discussion in:

  https://lore.kernel.org/git/20240604093345.GA1279521@coredump.intra.peff.net/

That message mentions patches to handle negative timestamps completely. You can see them here:

  https://github.com/peff/git/jk/time-negative-wip

It works fine on Linux, but IIRC I got stuck on the system time-handling functions of Windows being unhappy. Probably solvable by implementing more custom code.

If you're interested in trying to push it over the finish line, I'd be happy to discuss it.

Although...

I'm not sure how my implementation would handle this. The tm_to_time_t() fallback doesn't know anything about historical calendar shifts, and going in the reverse direction would depend on your system gmtime(). So probably:

 - if you feed a correct epoch timestamp for October 4th (e.g., "git
   commit --date=@-") you may or may not get the right result. Certainly
   on Windows if we have to use fallback code you wouldn't. But even GNU
   date doesn't seem to handle this:

     $ date --date=@-12219361438
     Thu Oct 14 00:00:00 LMT 1582

 - we'd always use custom code for going the other way. So:

     git commit --date=1582-10-04

   would give you an epoch 11 days before the 15th, not 1 day.

Even still, IMHO handling negative timestamps at all would be a huge improvement over the status quo. And we should be correct down to the second for "recent" stuff (like say, code written in the 1960's).

-Peff