Re: Back-dating commits--way back--for constitution.git

On Aug 3, 2010, at 1:55 AM, Michael J Gruber wrote:

Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:

quoted

The headers inside commit (and tag) objects are stored in text form,
so they are not limited to 32-bit value.  You would have to use  
system
that has 64-bit time_t, or patch git.

64-bit time_t would be enough for everyone (sic!).

time_t is signed on most systems. Using unsigned long buys us a few
years as long as we don't go through any system routine nor conversion
to time_t. So maybe we should:

- check to make sure we use time_t and system routines only when  
getting
the current time
- use signed long long as our git_time_t (I think long is less system
dependent then long but I could be wrong)

Obviously you mean "I think long long is less system dependent than  
long".

Does any system exist where long long is not 64 bits?  In any case,  
you can future-proof it by spelling it "int64_t".  That symbol is not  
guaranteed to exist (nor is <stdint.h>), but neither is the long long  
type in the first place.

- make our own algorithms work for the extended format

This would enable systems with 32-bit time_t to deal with pre-1901  
commit timestamps in Git.[1]  Hopefully such systems will become  
increasingly rare.

Josh

[1] Or post-2038 timestamps, but any use case for such is dubious.