AFAIK, Slick is just looking at the timestamp on the file.
When it complains, it looks at the timestamp of the file when Slick loaded or last saved it, and compares that to the current timestamp of the file.
The system clock shouldn't directly affect this comparison.
Normally Windows only shows you the hour and minute of the modification time.
You might need more information - since Windows keeps timestamps for files in 100ns increments, and Unix typically keeps it accurate to the second.
The only thing in Windows I know that shows more accurate filetime is "wmic".
From a CMD window, enter this:
wmic datafile where name="C:\\temp\\x.txt" get lastmodified
Where "DIR C:\temp\x.txt" shows
07/14/2017 01:32 PM 26 x.txt
WMIC will show much more precisely:
20170714133238.517893-420
On Windows, the FAT filesystem only keeps timestamps accurate to 2 seconds - so most programs, including Slick deal with that. On a file share, Slick may *assume* that the timestamp is more accurate than it really is - thus confusing things (though, I've never seen this happen - but then, I don't usually edit really big files on Samba servers).
V21 slick has auto-reload options to compare the file contents before complaining - but this is no good for really big files (as I think you are using, right?).
I thought it had an options WRT the FAT 2-second thing, but I can't find it.
See:
def_filetouch_checking
def_autoreload_compare_contents
def_autoreload_compare_contents_max_ksize