Handle future commit datetimes in the future without panicking about onefetch

[OsiPog]

I'm that colleague

[spenserblack]

But I like that "time travel" achievement 😢 😆 But you're right that we could handle this more gracefully.

I think that most people don't pay attention to the commit time, so even if it was an unreasonable value like in the year 3000 it could still get merged in. And if that happens the repo is basically unusable by onefetch unless a maintainer rewrites the history to fix the commit date. So overall we should change this from a panic to a warning message so that at least onefetch can display the other stats, and one unexpected time getting accidentally merged in doesn't "break" the whole repo for onefetch.

Besides the panic, I'm also worried that we're dropping the timezone offset somewhere, which can cause this issue. Do both of you (@OsiPog and @MalteT) live in different timezones, and can you confirm that your system times are correct?

[OsiPog]

Actually, we live in the same time zone and I can confirm that my system time was in fact incorrect. So I just caused this issue by commiting with my system time being in the future.

[MalteT]

So I think the solution is to print something like could not calculate last change: last commit datetime is in the future and then continue running.

Or time traveler detected, omitting last change calculation to prevent temporal paradox :D

I'm not familiar with the code base, but if the change is not too involved I could assemble a PR :)

[spenserblack]

I think we did have a timezone issue, anway 😆 2a3707e

Regardless of who or what caused the issue, I don't think anybody wants to rebase the commit history to fix the commit times just to get onefetch to stop panicking. So I think the solution is to print something like could not calculate last change: last commit datetime is in the future and then continue running.

[spenserblack]

Labeling this as an enhancement instead of a bug since the panic was intended behavior.

[spenserblack]

Oh, I like that better, actually! All you need to do is filter out commits where the commit time is greater than now.

But to do that some refactoring might be needed to avoid recalculating "now" in multiple places. Ideally SystemTime::now should only be called once per execution.