Thomas Rast <trast@xxxxxxxxxxx> writes: > Doing this just makes me wonder how important exactly the 1970-1975 > range is. Is there a notable software history from that era that can be > recovered? That is not really a valid question. People who wrote private stuff in that era deserve to be users of Git, too. > (Your [1/2] does not seem to parse negative offsets from the unix epoch, > so anything before 1970 is still out.) Yes, pre-epoch timestamps are also useful for projects like US Constitution. http://thread.gmane.org/gmane.comp.version-control.git/152433/focus=152725 For that, we would need to use and pass around time_t (or intmax_t if we follow the reason why originally Linus chose to avoid time_t) throughout the codebase. If you actually write commit objects that record pre-epoch timestamps, however, they will become unreadable by the current versions of Git (as they would not understand such a negative raw timestamp). In any case, that is a goal for a much longer term. But even after such a change happens, you still need a way for Git to replay a raw timestamp stored in commit objects without regressing the parse_date() interface too much. These two patches show one way to do so with minimum disruption. As an added bonus, with the second patch, the way to spell a raw timestamp happens to become compatible with how GNU date accepts one, i.e. $ date -d @1000000000 even though we do not have to encourage the use of this notation by humans, tools and script writers may find it useful. -- 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