As a bonus, this one attempted to backdate the commits in a cyphered way (git dates are unix timestamps so the author needed to get clever to do anything before t=0 in 1970).
As a bonus, this one attempted to backdate the commits in a cyphered way (git dates are unix timestamps so the author needed to get clever to do anything before t=0 in 1970).
How would you even do authorship? These amendments are basically institutional works, with sometimes convoluted histories (e.g. https://en.wikipedia.org/wiki/Twenty-seventh_Amendment_to_th...).
More specifically, git dates are unsigned timestamps with an epoch in common with Unix timestamps.
The big difference is that Unix timestamps are signed and have no problem whatsoever backdating to 1776.
Any fixed-with type is going to have a lower- and upper-bound; whether it has a sign or not doesn't change that.
If git was trying to choose a bound for a 32 bit timestamp, I think 1970 is a reasonable starting point; doubling your future space is more important than covering space in the past. If it's 64-bit, though, then it's kind of silly to not just envelop the entirety of human history with all the room you've got (as a 64 bit signed integer with 0=year 1970 does).
You are thinking of the in-memory representation of the (main) implementation, not the git format itself.
The on-disk/wire format is text representation, encoded in decimal. You can add a minus sign in front of it, git won't crash when parsing it. The implementation will, however, display the wrong date on git log, but it's a bug that git developers are working on.
For example (coincidentally, it is also a constitution):
$ git init
$ curl https://archive.softwareheritage.org/api/1/vault/revision/5e8f80061263d818ae3fc6c8d2086b5278f271ea/gitfast/raw/ | gunzip | git fast-import > /dev/null
$ git show 5e8f80061263d818ae3fc6c8d2086b5278f271e | grep Date
Date: Thu Jan 1 00:00:00 1970 +0000
$ git cat-file -p 5e8f80061263d818ae3fc6c8d2086b5278f271e | grep author
author State Constitutional Conventions <> -5706313200 -0455