If the OP is using /DCOPY (mistaking it for /COPY), the defaults for
/DCOPY are D (Data) and A (Archive) for what to copy from source to
destination. The source timestamps are not copied to the destination
files for /DCOPY, by default, so the destination files should get a new
date for the newly created files. As I recall, /DCOPY will retain the
timestamps for the folders wherease /COPY might not (it only preserves
the file timestamps) -- this is from memory and what I read, so it would
needs to get tested. If the OP was specifying a directory as the source
or destination arguments when using /COPY, I suppose the directory
timestamps could be different while the file timestamps were the same;
that is, with directories specified instead of filespecs, the filenames
might have the same timestamps but not the directories.

I think Paul might been onto something with the differences in
timestamping granularity in file systems between the source and
destination. NTFS retains timestamps down to a resolution of 100
nanoseconds (0.0000001 s). FAT32 stores only at a resolution of 2
seconds. That is a 2 billion difference in granularity. You can use
wmic to retrieve a file's timestamps down to the nearest microsecond.

wmic datafile where name='c:\\temp\\testme.txt' get CreationDate

This shows the Creation Date as an decimal value in the format
yyyymmddHHMMSS.xxxxxxsUUU, whe

yyyy = 4-digit year (0000 - 9999)
mm = 2-digit month (01 - 12)
dd = 2-digit day of month (01 - 31)
HH = 2-digit hour (00 - 23)
MM = 2-digit minutes (00 - 59)
SS = 2-digit seconds (00 - 59)
.xxxxxx = decimal seconds down to microsecond (000000 - 999999)
s = Negative or positive (- or +) offset from Coordinated
Universal Time.
UUU = 3-digit offset in minutes originating timezone deviates from
Coordinated Universal Time.

You need to remove the space character in the property names for the
'get' command. Use CreationDate, not Creation Date. Double backslashes
are need in the name field: the first backslash escapes the next
backslash which is otherwise a special character. In my example, I'm
looking at the Creation Date value for a file in c:\temp\testme.txt.

Since robocopy is comparing last-modified timestamps, you would use:

wmic datafile where name='path\\filename' get LastModified

I ran these commands under Windows 7 for a file stored in an NTFS
partition. I didn't have a FAT32 partition to test what value gets
reported by wmic for the Create or Last Modified datestamps.

I'm wondering with the change for daylight savings if the UUU value
might've changed making the source files look an hour different than
existing destination files by the same name. The destination files were
created earlier, the daylight change happened, and now the source files
look an hour off from the offset for the prior destination files. From
what I've read, this problem only occurs for FAT32 where Windows does
not automatically update the timestamps for DST changes. I doubt
Windows rewrites all files to affect a 60-minute change to the UUU value
for every file but instead just computes the offset for the system clock
to bias the UUU value.

https://freefilesync.org/manual.php?...ht-saving-time
"NTFS stores time in UTC format, while FAT uses local time."

To eliminate the extraneous all-file copy by robocopy twice per year for
each DST change, the OP would need to convert his USB drive from FAT32
to NTFS. Then the files on his USB drive would be compared on their UTC
time rather than a local time that changes twice per yead due to DST.