4 ms·

> git dates are unix timestamps so the author needed to get clever to do anything before t=0 in 1970 More specifically, git dates are unsigned timestamps with

by chungy 6y ago

> git dates are unix timestamps so the author needed to get clever to do anything before t=0 in 1970 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.

rcoveson 6y ago
I wouldn't say "no problem whatsoever." Lots of things encode Unix time as a 32 bit signed integer, which can't date back further than 1901. 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).
progval 6y ago
> git dates are unsigned timestamps 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

by chungy 6y ago

rcoveson 6y ago

I wouldn't say "no problem whatsoever." Lots of things encode Unix time as a 32 bit signed integer, which can't date back further than 1901. 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).

progval 6y ago

> git dates are unsigned timestamps 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