What is the format for --date parameter of git commit

I need to overwrite the date of the commit of git, all the documentation points to --date parameter, but then leaves one without a clue to the appropriate format. I've tried every permutation i can think of, and i'm getting "fatal: invalid date format:" error for each and every one.

Git 2.6+ (Q3 2015) add a new option.

See commit e4f031e (30 Jun 2015), and commit aa1462c, commit a5481a6, commit b7c1e11 (25 Jun 2015) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit d939af1, 03 Aug 2015)}

> introduce "format" date-mode

> This feeds the format directly to strftime.
Besides being a little more flexible, the main advantage is that your system strftime may know more about your locale's preferred format (e.g., how to spell the days of the week).

> --date=format:... feeds the format ... to your system strftime.
Use --date=format:%c to show the date in your system locale's preferred format.
See the strftime manual for a complete list of format placeholders.

Davide Cavestro proposes in the comments the example:

git commit -m "Test" --date=format:relative:5.hours.ago 

---

Original answer (mid 2014)

The --date option (introduced in commit 02b47cd in Dec. 2009, for git1.7.0) uses the same format than for GIT_AUTHOR_DATE, with date formats tested in commit 96b2d4f:

There you can see the various format accepted:

• rfc2822: Mon, 3 Jul 2006 17:18:43 +0200

• iso8601: 2006-07-03 17:18:43 +0200

• local: Mon Jul 3 15:18:43 2006

• short: 2006-07-03 (not in 1.9.1, works in 2.3.0)

• relative: see commit 34dc6e7:

    5.seconds.ago, 
    2.years.3.months.ago, 
    '6am yesterday'
  

• raw: see commit 7dff9b3 (git 1.6.2, March 2009)
  internal raw git format - seconds since epoch plus timezone
  (put another way: 'date +"%s %z"' format)

• default: Mon Jul 3 17:18:43 2006 +0200

---

ADTC asks and answers in the comments:

> Does it accept 2006-07-03 15:18:43 for local?

> Yes it does work and it takes the local time zone automatically.
With that format I don't need to bother which day of the week it is (Sun, Mon, etc).

The date format is underdocumented at Documentation/date-formats.txt (man git commit), and very "humanishely" parsed.

The only thing that works is reading the source under date.c and trying it out.

Points not mentioned by VonC on 2.3.0:

• digits only are parsed depending on the number of digits:

  • 2 digits: 19YY , for YY >= 73, current month, day and time. Errors or current date otherwise.

  • 4 digits: YYYY , for YYYY >= 1973, <= 2099

  • > 8 digits up to some small limit (TODO which?): UNIX time (seconds since 1970)

• @<digits> +0000: UNIX time.

  This seems like the best way to enter UNIX times directly.

  2**64 - 2 (TODO why not -1 ?) was the maximum value that does not lead to a commit error. The stamp is stored in a C long.

  git log shows very large values (somewhere around 2^55 TODO where?) as 1970, even though git cat-file -p HEAD shows that the right number was stored, so it seems like a limitation of the date conversion.

  For anything larger than 2**63 - 1, the largest positive signed long, trying to push to GitHub fails with date causes integer overflow. A commit at that date on GitHub (GitHub cannot show really large dates for some reason)

  VonC pointed that this is a shame as it blocks negative dates https://stackoverflow.com/questions/21787872/is-it-possible-to-set-a-git-commit-to-have-a-timestamp-prior-to-1970/24977895 which could be used to migrate older software to Git.

• tea: today at 17h :-)

Simple example:

GIT_AUTHOR_DATE='2015-04-19 17:18:43 +0200' GIT_COMMITTER_DATE='2015-04-19 17:18:43 +0200' git commit -m 'Commit message'

The abbreviated forms below would all work:

1. <month>/<day>
2. <month>-<day>
3. <day>.<month>

When there's no ambiguity, namely <day> is greater than 12, the order of <month> <day> doesn't matter, and the separator could be any of '/', '-', or '.'.

Otherwise, use '.' as separator for <day>.<month>, and '/' or '-' for <month>-<day>.

So "1.7" would be treated as "July 1st", and "1/7" would be "January 7th".

See the related commit from v1.3.0:

> We learned from our European friends on the #git channel that dd.mm.yyyy is the norm there. > > When the separator is '.', we prefer dd.mm.yyyy over mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over dd/mm/yy[yy].

This also applies to other commands accepting date input, e.g.: to show log since Feb 4th:

git log --since 2/4