Re: Millisecond precision in timestamps?

["Eric S. Raymond" <esr@thyrsus.com>]

Junio C Hamano <gitster@pobox.com>:
> 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>