linux - Explaining the 'find -mtime' command

Question

I'm trying to remove all the dateed logs except the most recent. Before I execute a script to remove the files, I want to of course test my commands to make sure I'm bringing up accurate results.

When executing these commands the date is:

Sep  1 00:53:44 AST 2014

Directory Listing:

Aug 27 23:59 testfile.2014-08-27.log
Aug 28 23:59 testfile.2014-08-28.log
Aug 29 23:59 testfile.2014-08-29.log
Aug 30 23:59 testfile.2014-08-30.log
Aug 31 23:59 testfile.2014-08-31.log
Sep  1 00:29 testfile.log

I thought -mtime +1 was supposed to list all files over a day old. Why isn't the 8-30.log one listed?

find . -type f -mtime +1 -name "testfile*log"
./testfile.2014-08-27.log
./testfile.2014-08-28.log
./testfile.2014-08-29.log

This is the desired effect, but it was just trial and error. What is this 0 saying?

find . -type f -mtime +0 -name "testfile*log"
./testfile.2014-08-30.log
./testfile.2014-08-27.log
./testfile.2014-08-28.log
./testfile.2014-08-29.log

Answer 1

The POSIX specification for find says:

-mtimen 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.

Interestingly, the description of find does not further specify 'initialization time'. It is probably, though, the time when find is initialized (run).

In the descriptions, wherever n is used as a primary argument, it shall be interpreted as a decimal integer optionally preceded by a plus ( '+' ) or minus-sign ( '-' ) sign, as follows:

+n More than n.
??n Exactly n.
-n Less than n.

At the given time (2014-09-01 00:53:44 -4:00, where I'm deducing that AST is Atlantic Standard Time, and therefore the time zone offset from UTC is -4:00 in ISO 8601 but +4:00 in ISO 9945 (POSIX), but it doesn't matter all that much):

1409547224 = 2014-09-01 00:53:44 -04:00
1409457540 = 2014-08-30 23:59:00 -04:00

so:

1409547224 - 1409457540 = 89684
89684 / 86400 = 1

Even if the 'seconds since the epoch' values are wrong, the relative values are correct (for some time zone somewhere in the world, they are correct).

The n value calculated for the 2014-08-30 log file therefore is exactly 1 (the calculation is done with integer arithmetic), and the +1 rejects it because it is strictly a > 1 comparison (and not >= 1).