Junio C Hamano <gitster@xxxxxxxxx>: > Roundtrip conversions may benefit from sub-second timestamps, but > personally I think negative timestamps are more interesting and of > practical use. You mean, as in times before the Unix epoch 1970-01-01T00:00:00Z? Interesting. I hadn't thought of that. I've never seen a software project under version control with bits that old, which is significant because I've probably done more digging into ancient software than anybody other than a specialist historian or two. They would have to have been restrospective dates from the get-go. SCCS wasn't built until 1972. > And if we were to add "committer-timestamp" and friends to support > negative timestamps anyway (because older tools will not support > them), supporting sub-second part might be something we want to > think about at the same time. That seems eminently reasonable. > We would however need to be extra careful. How should we express > half-second past Tue Nov 27 23:24:16 2012 (US/Pacific)? Would we > spell it 1354087456.5? 1354087456.500? Would we require decimal > representation of floating point numbers to be normalized in some > way (e.g. minimum number of digits without losing precision)? The > same timestamp needs to be expressed the same way, or we will end up > with different commit objects, which defeats the whole purpose of > introducing subsecond timestamps to support round-trip conversions. > > If we were to use a separate "subsecond" fields, another thing we > need to be careful about is the order of these extra fields, exactly > for the same reason. I think minimum number of digits without losing precision is about the only alternative that is future-proof - I was going to suggest it for that reason. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> -- 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