I remember running into this on other systems, and having different effects than testing with it now shows. I think these are implementation differences. I'm describing them as such below.
Most implementations of
mv attempt to not change the timestamp of a file when it moves it. However, may not consider the effects of after portions of the move.
This basically means:
If you are moving a file or directory within a filesystem, the timestamps on that file or directory won't change.
If you move a file to a different filesystem, its timestamp will be reset to the current time, because this is secretly a copy. However,
mv is generally smart enough to restore the old timestamp to the best of its ability, so access time and modify time will "remain" the same, but the change timestamp will be updated to the current time.
If you move an empty directory to a different filesystem, the same rule applies.
If you move a directory with contents to a different filesystem,
mkdir a new directory, replicate the permissions and ownership, and restore the original time... and then move the contents of that directory into it, updating its timestamp. Some implementations fix this (like GNU coreutils
mv 8.29), and others don't (like the ones I remember testing this behavior on before).
mv will always update the timestamp on the directory it moves files/directories from and the directory into which it moves files/directories. (Basically, it modifies these directories, so of course it updates their modify timestamp, so long as the filesystem in question has modify timestamps. As far as I'm aware, that's all of them.)