Reject out-of-range '@' Unix timestamp instead of panicking

Use UNIX_EPOCH.checked_add(...) so an out-of-range value returns None
and propagates through the existing ? like every other parse failure in
TimeFilter::from_str, rather than panicking via SystemTime's Add. See #2081.

CHANGELOG.md

@@ -13,6 +13,7 @@
 - Fire the "search pattern contains a path separator" diagnostic for any pattern containing `/`, not just patterns that happen to name an existing directory. Preserves the legacy Windows behaviour that also flags native `\` separators when the pattern resolves to a real directory. See #1873.
 - Also fire the "search pattern contains a path separator" diagnostic for `--and` patterns, not only the primary positional pattern. `--and` patterns are matched against the file name just like the primary pattern, so a path separator in them silently returned zero results. See #1873.
 - Fix bug where passing "-" as a directory argument didn't actually search that directory, see #849 (@Sean-Kenneth-Doherty).
+- Fix panic when `--changed-before`/`--changed-within` is given an out-of-range `@` Unix timestamp; the value is now rejected gracefully, see #2081 (@nikolauspschuetz).
 
 # 10.4.2
 

src/filter/time.rs

@@ -42,7 +42,7 @@ impl TimeFilter {
             )
         } else {
             let timestamp_secs: u64 = s.strip_prefix('@')?.parse().ok()?;
-            Some(UNIX_EPOCH + Duration::from_secs(timestamp_secs))
+            UNIX_EPOCH.checked_add(Duration::from_secs(timestamp_secs))
         }
     }