Workarounds for "cp -p" not preserving nanoseconds on High Sierra with APFS?

I don't know if this affects MacOS versions newer than High Sierra, but it seems that cp -p won't preserve timestamps with nanoseconds resolution.

Because of this, the shell can wrongly tell that a file is older than other even if it was copied by cp -p. This breaks build system dependencies when some files were installed by cp -p: they keep reinstalling and reinstalling again because the nanoseconds don't match.

Can you suggest some workaround for this? I thought compiling my own cp binary, but however cp is usually a shell builtin, and moreover I'm not aware of any nanosecond-preserving cp version out there.

Note: I know of a workaround, but it's not reasonable: Execute touch on the source file before executing cp -p. Because touch doesn't preserve nanoseconds either, it makes them zero on the source file, so the result after cp -p guarantees exactly the same timestamp. However, as I said, it's not reasonable, because I don't like to touch files just for this: you lose their real last saved date.

Good to know that I'm not the only one who thinks this is a problem. I ran into it while writing a Python script for monitoring parts of my macOS (10.15.7) filesystem, which also involved coping files. The script sometimes behaved erratic and produced unpredictable output. After some poking around I found out that the incapability of cp -p to preserve nanoseconds is the core of the problem.

One workaround for your problem (but not for mine) could be coreutils: gcp -p behaves as intended.

I thought this was fixed in 10.15, but I just didn't repro the problem correctly. To save others the same embarrassment, here's a repro that shows the problem:

% python3 -c 'open("file1", "w")'
% stat -f %Fm file1
1609301645.481666557
% cp -p file1 file2
% stat -f %Fm file2
1609301645.481666000