110

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.

Paulo Mattos
  • 18,845
  • 10
  • 77
  • 85
v010dya
  • 5,296
  • 7
  • 28
  • 48
  • 1
    That some answers to that question do partially answer mine. I've just checked and it works. Btw, you are not required to put the day of the week there (that would be painful). – v010dya Nov 02 '13 at 13:35

5 Answers5

116

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).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Does it accept `2006-07-03 15:18:43` for *local*? Also, what are *relative* and *raw* formats? – ADTC Aug 22 '14 at 09:34
  • To answer my own first question, 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). – ADTC Aug 22 '14 at 09:53
  • 1
    @ADTC I have added links and references for the relative and raw date format. I have included your comment in the answer for more visibility. – VonC Aug 22 '14 at 12:55
  • Short format `2000-01-01` not working on 1.9.1. : minutes needed. Also, why does `0000000000 +0000` not work while `1000000000 +0000` does? – Ciro Santilli OurBigBook.com Dec 12 '14 at 20:15
  • 1
    @CiroSantilli not sure: that could be a good separate question. I will test it with 1.9.4. – VonC Dec 12 '14 at 20:17
  • 1
    @CiroSantilli六四事件法轮功 Thank you for the edit, great to see that short format in 2.3.0. – VonC Mar 26 '15 at 22:12
  • 1
    So it works something like `git commit -m "Test" --date=format:relative:5.hours.ago` – Davide Cavestro Dec 12 '17 at 11:03
  • @DavideCavestro Thank you. I have included your comment in the answer for more visibility. – VonC Dec 12 '17 at 11:40
12

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'
Dmytro Melnychuk
  • 2,285
  • 21
  • 23
  • 3
    Using environment variables seems to be the only way to set the commit-date. No argument options for that. – Jarl Apr 20 '20 at 08:05
10

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 Is it possible to set a git commit to have a timestamp prior to 1970? which could be used to migrate older software to Git.

  • tea: today at 17h :-)

Community
  • 1
  • 1
Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
  • Note that with Git repos initiatives dependent on date (like this one: http://stackoverflow.com/q/29385441/6309), dates prior to 1970 would be nice: http://stackoverflow.com/a/24977895/6309 – VonC Apr 02 '15 at 06:07
  • 3
    @VonC: nice link. It hadn't crossed my mind that version control exists since 60s / 70s http://programmers.stackexchange.com/questions/184695/when-was-source-control-invented and text since year -3200. What if they want to migrate hammurabi's code to Git? :-) (ah, just found out that someone has already done so: https://github.com/elia/hammurabi/blob/master/lib/hammurabi/code.txt , but lost the timestamps) – Ciro Santilli OurBigBook.com Apr 02 '15 at 06:19
1

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
ryenus
  • 15,711
  • 5
  • 56
  • 63
1

You can write: "yesterday", "2 days ago", or "one week ago" or you can put in a specific date with dashes. You can do this in conventional order. For example, June-19-2023.

TJ Relly
  • 21
  • 3