Junio C Hamano <[email protected]>:
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
