Re: Millisecond precision in timestamps?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 28, 2012, 07:29 UTC
Message-ID: <7v7gp6i3rx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20121128011750.GA23498@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

> There is room for new headers, and older versions of git will ignore
> them. You could add a new "committer-timestamp" field that elaborates on
> the timestamp included on the committer line. Newer versions of git
> would respect it, and older versions would fall back to using the
> committer timestamp.
>
> But I really wonder if anybody actually cares about adding sub-second
> timestamp support, or if it is merely "because SVN has it".

Roundtrip conversions may benefit from sub-second timestamps, but personally I think negative timestamps are more interesting and of practical use. Prehistoric projects need them even if they intend to switch to Git, never to go back to their original tarballs and collection of RCS ,v files.

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.

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.