Re: Millisecond precision in timestamps?

[Andreas Ericsson <ae@op5.se>]

On 11/28/2012 08:29 AM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
>> 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.
> 

If we're going to support pre-epoch timestamps, we'll have to do that
for 2.0 anyway, since we'll otherwise have two conflicting dates in
the commit object.

Adding support for parsing them now and start writing them in 2.0
would make sense.

In that case, we'd have to print timestamps as
printf("%lu.%06lu", tv.tv_sec, tv.tv_usec);

I'm unsure how useful it is to support pre-epoch dates though. It's
hard to find software where anyone really cares about the code from
43 years ago with anything but historical interest, and for those
who take the museum road, I'm betting it's more interesting to see
how people worked back then than it is to see what they wrote.

Aside from that, it would be trivial to support museum style history
viewing with a special flag that treats the timestamps as minutes
since 1900-01-01 or some such, giving us plenty of time before even
the first punch-card was invented. It wouldn't be much harder to
let the user specify the timeunit and the start-point either, and
then we could store the history of carbon-based lifeforms on earth
in git.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.