The POSIX specification for find says:
-mtimenThe 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
nis used as a primary argument, it shall be interpreted as a decimal integer optionally preceded by a plus ( '+' ) or minus-sign ( '-' ) sign, as follows:
+nMore thann.
nExactlyn.
-nLess 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).