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

From: Jeff King <peff@peff.net>
Date: Jun 20, 2016, 22:21 UTC
Message-ID: <20160620222112.GB6431@sigill.intra.peff.net>
In-Reply-To: <xmqqy45zse7o.fsf@gitster.mtv.corp.google.com>

On Mon, Jun 20, 2016 at 03:11:23PM -0700, Junio C Hamano wrote:

Show 13 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > I still don't know how that screwed-up timestamp got _into_
> > a commit, so perhaps there is another bug lurking.  I couldn't convince
> > git to parse anything beyond 2100, and committing with
> > GIT_AUTHOR_DATE='@5758122296 +0000' works just fine.
> 
> Interesting.  The weirdest I could come up with was with
> 
>     GIT_AUTHOR_DATE='@5758122296 -9999
> 
> which gets turned into the same timestamp but with -10039 timezone
> (simply because 99 minutes is an hour and 39 minutes).

Yeah, as weird as that is, I think it's reasonable. We _could_ turn nonsense timezones into "+0000". That doesn't necessarily help the user much, but at least it's less bizarre than making a 46-year timezone offset.

I also looked for other uses of tm_to_time_t without checking for an error return. Most of them do check. The exception is datestamp(), but is calling it on the output of localtime(time()), which should generally be sensible.

-Peff