# [BUG] internal date format does not accept small unix timestamps 6 messages from 2026-05-29 to 2026-05-31. Participants: Luna Schwalbe, Kristoffer Haugsbakk, Junio C Hamano. Thread: https://gitlist.dev/t/65713 ## Luna Schwalbe, 2026-05-29 11:51 Subject: [BUG] internal date format does not accept small unix timestamps Message-ID: ``` 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 ``` ## Kristoffer Haugsbakk, 2026-05-29 12:50 Subject: Re: [BUG] internal date format does not accept small unix timestamps Message-ID: In-Reply-To: ``` 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` ``` ## Luna Schwalbe, 2026-05-29 14:52 Subject: Re: [BUG] internal date format does not accept small unix timestamps Message-ID: <08a04d91-af90-44dd-b28f-f3d5b9e77413@luna.gl> In-Reply-To: ``` > 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 ``` ## Junio C Hamano, 2026-05-29 22:52 Subject: Re: [BUG] internal date format does not accept small unix timestamps Message-ID: In-Reply-To: <08a04d91-af90-44dd-b28f-f3d5b9e77413@luna.gl> ``` Luna Schwalbe 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. ``` ## Junio C Hamano, 2026-05-30 07:43 Subject: doc: document '@' prefix for raw timestamps Message-ID: In-Reply-To: ``` Junio C Hamano 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 ` ` 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:: `` is the number of seconds since the UNIX epoch. `` 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 `` 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' ``` ## Luna Schwalbe, 2026-05-31 08:29 Subject: Re: doc: document '@' prefix for raw timestamps Message-ID: In-Reply-To: ``` >> 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. ```