mdfind bug: mdfind does not track same modification date as finder, HTML file input, and ls

The UNIX inode tables are far below any metadata content that would concern Spotlight or the mdls command.

If one saves the following Bash script to a text file, and permits it executable, it will show all four UNIX date/time stamps for a given file or folder:

#!/bin/bash
#
# Syntax: http://www.real-world-systems.com/docs/stat.1.html
#    and: man stat
# See: stat(1), strftime(3)

for file in "$@"
do
    stat -t '%Y-%m-%d %X' -f '%n%Sp%T %z %Su %Sg %N %SY %n Last Access:        %Sa %n Last Modify:        %Sm %n Last inode change:  %Sc %n Birth of inode:     %SB%n' "${file}"
done
printf "\n"
exit 0

chmod +x ./lsd.sh
./lsd.sh ~/Desktop/test

The output appears as (I have removed the personal folder path from it), after I add the child test1 folder:

Last Access:        2020-09-02 13:05:25 
Last Modify:        2020-09-02 13:06:33 
Last inode change:  2020-09-02 13:06:33 
Birth of inode:     2020-09-02 13:03:43

What I meant was that the metadata was not intended for folder contents, not that it may or may not be used. Being that it doesn't appear to have been intended for that purpose, the metadata assigned probably shouldn't be used.

As VikingOSX noted, there is file system data for that, but I've found it may not always be reliable.

You would hope you could at least rely on file system data as it shouldn't be dependent on something choosing to write metadata.

The way UNIX works is that a parent folder's Last modify and last inode change dates are updated whenever its contents change, whether that is the addition, deletion, or renaming of a child folder or file.

Spotlight does not expose time, only date. The UNIX stat command provides a means to extract a specific time to the second if you wish, and you can use that in a loop to check if a file's creation time is in a given range, regardless of date. I wrote a script for another post that does that:

#!/bin/zsh

: <<'COMMENT'
Automator folder action script to test the creation date
time stamp of a file and see if it is in the range of 9:30pm
until 5am. Delete it if it is, and ignore it otherwise.
COMMENT

# path to the drop folder
DROPFOLDER="${1:a:h}"

setopt NO_CASE_GLOB
for f in "${DROPFOLDER}/*.(jpg|jpeg)(.N);
do
    # extract the time as hhmm of the file creation date
    hhmm=$(stat -t '%H%M' -f '%SB' "${f:a}")

    [[ $hhmm -ge 2130 || $hhmm -le 0500 ]] || continue
    # rm -f "${f:a:t}"
    echo "${f:a}" > ~/Desktop/rpt.txt
done
exit 0



When one uses Image Capture to download a file from a camera to macOS, the Finder will attempt to use the EXIF key DateTimeOriginal to set the creation date/time of the file shown by Finder. It will not be the current System time, as would be the case with any other file creation scenario on macOS.

Spotlight adjusts its times to 0000 UTC. Sometimes, once you substract your UTC offset from the Spotlight time, you realize that the date is one day off too, because the adjusted time is before midnight of the date shown by Spotlight. I trust Finder before I would Spotlight, and also, less math involved.

I don't think the content is referring to the contents of a folder. It is referring to the content of a file, like when the photo was retouched, or the text of a document was modified. But, perhaps it should refer to the content of a folder.

Don't rule out Spotlight or Finder search windows using this syntax:

kind:folder name:test modified:>08/01/2020

To show you any folder named test that was modified after Aug. 1, 2020. Turn that arrow around, and it would mean before.

The UNIX inode tables are far below any metadata content that would concern Spotlight or the mdls command.

That's what I was trying to convey. Apple's full, robust use of metadata isn't anywhere close to being complete. Use the other data which has a higher probability of being correct. Some (maybe all) of it is duplicated in metadata, so available through Spotlight, but the made up stuff isn't particularly reliable.