find: find -amin 1 output differs with GNU

[Devel08]

uutils findutils:

$ cargo run --bin find -- -amin 1
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/find -amin 1`

GNU findutils:

$ find -amin 1
./target/debug/find.d

[MsfPablo]

Tried to reproduce this with controlled atimes (via `os.utime`) rather than relying on whatever the filesystem happened to record during a `cargo run` build, and the exact-match semantics for `-amin N` (floor of elapsed-seconds/60) matched GNU find's documented behavior exactly:

$ python3 -c "import os,time; now=time.time(); open('f2','w').close(); os.utime('f2', (now-70, now-70))"
$ find . -amin 1
./f2

So I don't think there's a semantic bug in the age-comparison logic itself. My read is the original repro (`find -amin 1` with no path, right after `cargo build`) just depends on which files in the tree happen to have an atime in the [60s, 120s) window at that exact moment — which is inherently timing-dependent and not something a test can pin down reliably. GNU's output (`./target/debug/find.d`) reflects a file whose atime happened to be ~1 min old on ITS particular run, not a difference in matching logic.

Happy to be pointed at a more deterministic repro if there's a real discrepancy I'm missing (e.g. a specific boundary case), but wanted to flag this before spending more time chasing a timing artifact.