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

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

Jeff King [off-list ref] writes:

quoted

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