I'm struggling to wrap my mind around why the find interprets file modification times the way it does.  Specifically, I don't understand why the -mtime +1 doesn't show files less than 48 hours old. As an example test I created three test files with different modified dates: [root@foobox findtest]# ls -ltotal 0-rw-r--r-- 1 root root 0 Sep 25 08:44 foo1-rw-r--r-- 1 root root 0 Sep 24 08:14 foo2-rw-r--r-- 1 root root 0 Sep 23 08:14 foo3I then ran find with the -mtime +1 switch and got the following output:[root@foobox findtest]# find -mtime +1./foo3I then ran find with the -mmin +1440 and got the following output: [root@foobox findtest]# find -mmin +1440./foo3./foo2As per the man page for find, I understand that this is expected behavior: -mtime n        Files  data was last modified n*24 hours ago.  See the comments        for -atime to understand how rounding affects the interpretation        of file modification times.-atime n       File  was  last  accessed n*24 hours ago.  When find figures out       how many 24-hour periods ago the file  was  last  accessed,  any       fractional part is ignored, so to match -atime +1, a file has to       have been accessed at least two days ago.This still doesn't make sense to me though.  So if a file is 1 day, 23 hours, 59 minutes, and 59 seconds old, find -mtime +1 ignores all that and just treats it like it's 1 day, 0 hours, 0 minutes, and 0 seconds old?  In which case, it's not technically older that 1 day and ignored? Does... not... compute. 
Why does find -mtime +1 only return files older than 2 days?
find;timestamps
Well, the simple answer is, I guess, that your find implementation is following the POSIX/SuS standard, which says it must behave this way. Quoting from SUSv4/IEEE Std 1003.1, 2013 Edition, find:-mtime  n  The primary shall evaluate as true if the file modification time subtracted  from the initialization time, divided by 86400 (with any remainder discarded), is n.(Elsewhere in that document it explains that n can actually be +n, and the meaning of that as greater than).As to why the standard says it shall behave that waywell, I'd guess long in the past a programmer was lazy or not thinking about it, and just wrote the C code (current_time - file_time) / 86400. C integer arithmetic discards the remainder. Scripts started depending on that behavior, and thus it was standardized.The spec'd behavior would also be portable to a hypothetical system that only stored a modification date (not time). I don't know if such a system has existed.