Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Git's source code assumes that unsigned long is at least as precise as > time_t. Well, Git's source code is wrong. > ... That is correct. As people mentioned downthread already, "unsigned long" has two problems, it may not be wide enough, and it cannot represent time before the epoch. But moving the internal time representation used in various fields like commit->date to time_t is likely to be a wrong thing to do, because the first problem with "unsigned long", i.e. "may not be wide enough", is not limited to "not wide enough to hold time_t". It also includes "it may not be wide enough to hold time somebody else recorded in existing objects". Since some platforms have time_t that is not wide enough, but still have intmax_t that is wider, I think we would be better off to pick an integral type to use for the internal representation that is the widest throughout the API, and use time_t only at places that we interact with the system libraries (e.g. when we ask "what is the time now?" to time(2), when we ask "break down this timestamp" to gmtime(3)). Thanks for starting this, and from a brief read, the hotfix to skip the test downthread looked good. The places this "starting point" patch covers look like a good set that interacts with time obtained locally (e.g. prune that compares with filesystem timestamp); just make sure you don't go too far and end up shoving timestamps from other people into time_t, which may not fit. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html