On Mon, Jun 20, 2016 at 03:11:23PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html