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

From: Norbert Kiesel <nkiesel@gmail.com>
Date: Jun 21, 2016, 06:37 UTC
Message-ID: <CAM+g_NtGWRCqaNz1DauZRReem0YPC6CaunHSwfhnB5LpvdGGcQ@mail.gmail.com>
In-Reply-To: <20160620222112.GB6431@sigill.intra.peff.net>

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.

On Mon, Jun 20, 2016 at 3:21 PM, Jeff King <peff@peff.net> wrote:

Show 27 quoted lines

> On Mon, Jun 20, 2016 at 03:11:23PM -0700, Junio C Hamano wrote:
>
>> 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