Handle future commit datetimes in the future without panicking

[MalteT]

Duplicates

• I have searched the existing issues

Current behavior 😯

If the commit time is in the future, onefetch crashes.

Expected behavior 🤔

It should possibly handle the case or fail gracefully. The crash report blames this on me, but my system time is okay and I don't have much influence over my colleague's system time.

Steps to reproduce 🕹

Have the most recent git commit in the future and run onefetch

Additional context/Screenshots 🔦

name = "onefetch"
operating_system = "NixOS 24.5.0 [64-bit]"
crate_version = "2.20.0"
explanation = """
Panic occurred in file 'src/info/utils/mod.rs' at line 35
"""
cause = "Achievement unlocked: time travel! Check your system clock and commit dates."
method = "Panic"
backtrace = """

   0: 0x56049cc6bb63 - core::option::expect_failed::hcbf5a9b7e22cab9f
   1: 0x56049cc93285 - onefetch::info::utils::format_time::he784b32eb1d439c7
   2: 0x56049ccec879 - onefetch::info::InfoBuilder::last_change::h5aac04e9a53655fa
   3: 0x56049ccea471 - onefetch::info::build_info::h6232c8d9e8572b77
   4: 0x56049cc7dded - onefetch::main::hfc8e895e84fac4d0
   5: 0x56049cc85363 - std::sys_common::backtrace::__rust_begin_short_backtrace::he043df6535079d0d
   6: 0x56049cc86c9d - std::rt::lang_start::{{closure}}::h5f878ceb72151ea0
   7: 0x56049d5883d4 - std::panicking::try::h45c8379f4866ecc7
   8: 0x56049d581eb5 - std::rt::lang_start_internal::hf358ddc7f05da9a0
   9: 0x56049cc7e5f5 - main
  10: 0x7f25f061c0ce - __libc_start_call_main
  11: 0x7f25f061c189 - __libc_start_main@GLIBC_2.2.5
  12: 0x56049cc6be25 - _start
  13:        0x0 - <unresolved>"""

Possible Solution 💡

No response

Thanks for your awesome work!

[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.

[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.

[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]

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.

[o2sh]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[spenserblack]

Coming back to this, I think it should be pretty easy to implement. I'm just making a quick comment without checking the codebase, but I think that all that needs to happen is:

• Replace panic with eprintln!.
• Turn the calculated time's type into an Option<T> (or Result<T, E>) so that it can be None (or Err(E)), and then hide the stat if it couldn't be calculated.¹

Footnotes

1. Honestly, as an alternative to changing the value's type, we could probably get away with the easier solution of just falling back to SystemTime::now if the latest commit date is too high. ↩