Re: [PATCH 0/3] fix local_tzoffset with far-in-future dates

[Jeff King <peff@peff.net>]

On Mon, Jun 20, 2016 at 11:37:50PM -0700, Norbert Kiesel wrote:

> There are more strange things happening with dates.  One example is
> that `git commit --date=@4102444799` produces a commit with the
> correct author date "Thu Dec 31 15:59:59 2099 -0800" (for my local
> timezone which is Americas/Los_Angeles), while `git commit
> --date=@4102444800` produces a commit with "now" as author date, as
> does any other larger number. `date --date=@4102444800` results in
> "Thu Dec 31 16:00:00 PST 2099". So seems 2100-01-01T00:00:00Z is a
> hard limit for git when using this format.

Yes, I noticed that, too. I suspect it comes from the same source; the
date parser calls tm_to_time_t at some point which will refuse to handle
the date, and we fallback to something else. So certainly there is room
for improvement:

  1. We could handle a wider range of dates in tm_to_time_t(). This is
     essentially mktime(), but notice that mktime() was avoided for good
     reasons long ago, so any proposal to just move to that would need
     to figure out all those reasons and whether they are still valid.

  2. We should perhaps be flagging an error here instead of falling back
     to the current time. I suspect this is happening because --date
     falls back to approxidate() when we fail to parse the date (so you
     can say things like "--date=last.friday". Especially for cases with
     "@", which indicate that no approximate parsing is really required.

     Note that using GIT_AUTHOR_DATE _doesn't_ go through the date
     parser, but expects a raw time_t. So that does work for these
     far-future dates.

I'm not planning on working on either of these in the near term, but I'd
be happy to review patches if somebody else wants to.

-Peff