The POSIX specification for find says:
-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), isn
.
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 thann
.
n
Exactlyn
.-n
Less thann
.
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
).