[BUG] internal date format does not accept small unix timestamps

[BUG] internal date format does not accept small unix timestamps

[Luna Schwalbe]

While trying to create some test commits, I noticed the following issue:

GIT_AUTHOR_DATE and GIT_COMMITTER_DATE should accept the "Git internal 
format" (displayed by git log with --date=raw), but this fails for small 
unix timestamps. A quick binary search indicates that it happens when 
the unix timestamp is below 100000000 (9 digits).

So for example, GIT_AUTHOR_DATE='99999999 +0000' fails with "fatal: 
invalid date format", while GIT_AUTHOR_DATE='100000000 +0000' works as 
expected.
It seems to be unaffected by the choice of timezone offset.
Padding the timestamp with zeroes also does not change the behavior.

The --date option does accept all the values, but interprets them 
wrongly and gives bogus results (most of them time it seems to act as if 
no date option was given, using the current system time, but with some 
inputs I've also observed things like "current date&time but set the 
year to 2000").

I tested everything with git built from commit 
2f8565e1d14d2de4cfbc9da0132131bf0d0dc087.

Luna

Re: [BUG] internal date format does not accept small unix timestamps

[Kristoffer Haugsbakk]

On Fri, May 29, 2026, at 13:51, Luna Schwalbe wrote:
> While trying to create some test commits, I noticed the following issue:
>
> GIT_AUTHOR_DATE and GIT_COMMITTER_DATE should accept the "Git internal
> format" (displayed by git log with --date=raw), but this fails for small
> unix timestamps. A quick binary search indicates that it happens when
> the unix timestamp is below 100000000 (9 digits).
>
> So for example, GIT_AUTHOR_DATE='99999999 +0000' fails with "fatal:
> invalid date format", while GIT_AUTHOR_DATE='100000000 +0000' works as
> expected.
> It seems to be unaffected by the choice of timezone offset.
> Padding the timestamp with zeroes also does not change the behavior.
>
> The --date option does accept all the values, but interprets them
> wrongly and gives bogus results (most of them time it seems to act as if
> no date option was given, using the current system time, but with some
> inputs I've also observed things like "current date&time but set the
> year to 2000").
>
> I tested everything with git built from commit
> 2f8565e1d14d2de4cfbc9da0132131bf0d0dc087.

Apparently you need `@` in front for small Unix Epoch values. `@0 +0000`

Re: [BUG] internal date format does not accept small unix timestamps

[Luna Schwalbe]

 > Apparently you need `@` in front for small Unix Epoch values. `@0 +0000`

That is wonderful, thank you so much, I somehow did not find this small 
detail anywhere.

Maybe it could be added to Documentation/date-formats.adoc?

Luna

Re: [BUG] internal date format does not accept small unix timestamps

[Junio C Hamano]

Luna Schwalbe <dev@luna.gl> writes:

>  > Apparently you need `@` in front for small Unix Epoch values. `@0 +0000`
>
> That is wonderful, thank you so much, I somehow did not find this small 
> detail anywhere.
>
> Maybe it could be added to Documentation/date-formats.adoc?
>
> Luna

Good suggestion.

This was introduced in 116eb3ab (parse_date(): allow ancient
git-timestamp, 2012-02-02) and 2c733fb2 (parse_date(): '@' prefix
forces git-timestamp, 2012-02-02) to allow specifying "ancient"
timestamps (like 0 +0000) without conflicting with YYYYMMDD date
formats.  I do not think neither commit added documentation for this
'@' prefix, and Documentation/date-formats would be an excellent
place to do so.

Care to whip up a patch?

Thanks.

doc: document '@' prefix for raw timestamps

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> This was introduced in 116eb3ab (parse_date(): allow ancient
> git-timestamp, 2012-02-02) and 2c733fb2 (parse_date(): '@' prefix
> forces git-timestamp, 2012-02-02) to allow specifying "ancient"
> timestamps (like 0 +0000) without conflicting with YYYYMMDD date
> formats.  I do not think neither commit added documentation for this
> '@' prefix, and Documentation/date-formats would be an excellent
> place to do so.
>
> Care to whip up a patch?

It might look something like this.

----- >8 -----

The Git internal date format `<unix-timestamp> <time-zone-offset>`
fails to parse when the timestamp is less than 100,000,000 (fewer
than 9 digits). This happens because the parser attempts to guess
the format, and 8-digit numbers are interpreted as YYYYMMDD dates.

To force the parser to interpret the value as a raw timestamp, it
must be prefixed with `@` (e.g., `@0 +0000`). This behavior was
introduced in 2c733fb24c (parse_date(): '@' prefix forces
git-timestamp, 2012-02-02) but was never documented.

Document the `@` prefix in `Documentation/date-formats.adoc` to
make this behavior explicit. Also add test cases to
`t/t0006-date.sh` to verify and demonstrate the difference
between prefixed and unprefixed small timestamps (e.g.,
`@20000101` vs `20000101`).
---
diff --git a/Documentation/date-formats.adoc b/Documentation/date-formats.adoc
index e24517c496..93fd36449c 100644
--- a/Documentation/date-formats.adoc
+++ b/Documentation/date-formats.adoc
@@ -9,6 +9,13 @@ Git internal format::
 	`<unix-timestamp>` is the number of seconds since the UNIX epoch.
 	`<time-zone-offset>` is a positive or negative offset from UTC.
 	For example CET (which is 1 hour ahead of UTC) is `+0100`.
++
+It is safer to prepend the `<unix-timestamp>` with `@`
+(e.g., `@0 +0000`), which forces Git to interpret it as a raw
+timestamp even if it looks like another format (like `YYYYMMDD`).
+This is required for timestamps less than 100,000,000 (which have
+fewer than 9 digits) to avoid confusion with other date formats.
+
 
 RFC 2822::
 	The standard date format as described by RFC 2822, for example
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index 53ced36df4..e11c659716 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -138,6 +138,14 @@ check_parse '1969-12-31 23:59:59 Z' bad
 check_parse '1969-12-31 23:59:59 +11' bad
 check_parse '1969-12-31 23:59:59 -11' bad
 
+# pathologically small or easily confused raw timestamps
+check_parse '@99999999 +0000' '1973-03-03 09:46:39 +0000'
+check_parse '@0 +0000' '1970-01-01 00:00:00 +0000'
+check_parse '99999999 +0000' bad
+check_parse '20000101 +0000' '2000-01-01 00:00:00 +0000'
+check_parse '@20000101 +0000' '1970-08-20 11:35:01 +0000'
+
+
 REQUIRE_64BIT_TIME=HAVE_64BIT_TIME
 check_parse '2099-12-31 23:59:59' '2099-12-31 23:59:59 +0000'
 check_parse '2099-12-31 23:59:59 +00' '2099-12-31 23:59:59 +0000'

Re: doc: document '@' prefix for raw timestamps

[Luna Schwalbe]

 >> This was introduced in 116eb3ab (parse_date(): allow ancient
>> git-timestamp, 2012-02-02) and 2c733fb2 (parse_date(): '@' prefix
>> forces git-timestamp, 2012-02-02) to allow specifying "ancient"
>> timestamps (like 0 +0000) without conflicting with YYYYMMDD date
>> formats.  I do not think neither commit added documentation for this
>> '@' prefix, and Documentation/date-formats would be an excellent
>> place to do so.
>>
>> Care to whip up a patch?
> It might look something like this.

Thanks! And sure, I'll try to submit something later; this will be my 
first time using the send-mail workflow, I hope I don't mess anything up.