Re: Millisecond precision in timestamps?

From: Jeff King <peff@peff.net>
Date: Nov 29, 2012, 20:01 UTC
Message-ID: <20121129200143.GB22084@sigill.intra.peff.net>
In-Reply-To: <CABURp0pnGYykud1xDn5T+eszQGTrzKLTp6J_O7ZrWwVd-zKpkg@mail.gmail.com>

On Thu, Nov 29, 2012 at 02:14:40PM -0500, Phil Hord wrote:

Show 8 quoted lines

> > 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.
> 
> Posix-time is signed, but I suppose the git tools do not expect/allow
> a '-' character in the stream.  Has git considered the year-2038
> problem?

Yes. The timestamp is in base-10 ASCII, so there is no Y2038 problem in the data format (it is up to the implementation to read it into a sufficiently large time_t internally, of course[1]).

But negative timestamps are a different story. We use "unsigned long" internally for timestamps, and fsck will complain about it.

-Peff

[1] We use "unsigned long", which means we are Y2038-fine on I32/LP64
    systems, but not on 32-bit or IL32/LLP64 systems. I do not use
    Windows, but my understanding is that LLP64 is the norm there, so it
    would eventually be a problem. But since we are unsigned, it is
    actually a Y2106 problem.