Re: Millisecond precision in timestamps?

From: Andreas Ericsson <ae@op5.se>
Date: Nov 28, 2012, 10:10 UTC
Message-ID: <50B5E30B.5080505@op5.se>
In-Reply-To: <7v7gp6i3rx.fsf@alter.siamese.dyndns.org>

On 11/28/2012 08:29 AM, Junio C Hamano wrote:

Show 35 quoted lines

> 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.