I compared time handling via -[a,c,m]time with the -size handling to check for consistency (see bug #12162 Enhancement req: finding files less than 2Gb in size [needs community feedback]). While I think that a unified handling of comparing values – be it time or size – is beneficial, I agree to have a separate bug for discussing the time handling – in the end a time is still different to a size.

I found the time handling of find to be quite cumbersome to human beings, while it makes some sense technically assuming that find uses integer comparision as follows.

I did – quoted from the other bug:

ms@mango:/tmp/find-times> touch -d "1 day ago" morethan1dayago
ms@mango:/tmp/find-times> touch -d "22 hours ago" lessthan1dayago
ms@mango:/tmp/find-times> touch -d "2 days ago" morethan2daysago
ms@mango:/tmp/find-times> touch -d "3 days ago" morethan3daysago
ms@mango:/tmp/find-times> touch -d "46 hours ago" lessthan2daysago
ms@mango:/tmp/find-times> touch -d "70 hours ago" lessthan3daysago

I get – quoted from the other bug:

ms@mango:/tmp/find-times> ls -l
insgesamt 0
-rw-rw-r-- 1 ms teamix 0 Aug 14 18:11 lessthan1dayago
-rw-rw-r-- 1 ms teamix 0 Aug 13 18:12 lessthan2daysago
-rw-rw-r-- 1 ms teamix 0 Aug 12 18:12 lessthan3daysago
-rw-rw-r-- 1 ms teamix 0 Aug 14 16:11 morethan1dayago
-rw-rw-r-- 1 ms teamix 0 Aug 13 16:11 morethan2daysago
-rw-rw-r-- 1 ms teamix 0 Aug 12 16:11 morethan3daysago
ms@mango:/tmp/find-times> date
Mi 15. Aug 16:29:51 CEST 2012
ms@mango:/tmp/find-times> find -mtime +1 -printf "%p\t %t\n" | sort
./lessthan3daysago Sun Aug 12 18:12:10.0626806028 2012
./morethan2daysago Mon Aug 13 16:11:42.0727680142 2012
./morethan3daysago Sun Aug 12 16:11:50.0715653807 2012
As predicted -mtime +1 translated to more than two days ago.
ms@mango:/tmp/find-times> find -mtime +3 -printf "%p\t %t\n" | sort
+3 translates to more than 4 days ago, thus no results
ms@mango:/tmp/find-times> find -mtime +2 -printf "%p\t %t\n" | sort
./morethan3daysago Sun Aug 12 16:11:50.0715653807 2012
And +2 to more than 3 days ago.
Yet with -time it seems to be the other way around:
ms@mango:/tmp/find-times> find -mtime -2 -printf "%p\t %t\n" | sort
./lessthan1dayago Tue Aug 14 18:11:33.0444291877 2012
./lessthan2daysago Mon Aug 13 18:12:00.0302854716 2012
./morethan1dayago Tue Aug 14 16:11:23.0258103147 2012
. Wed Aug 15 16:12:10.0625203012 2012
-2 translates to less than 2 days ago (as I actually wrote before)
ms@mango:/tmp/find-times> find -mtime -1 -printf "%p\t %t\n" | sort
./lessthan1dayago Tue Aug 14 18:11:33.0444291877 2012
. Wed Aug 15 16:12:10.0625203012 2012
-1 to less than one day ago.
Thus we have:
-mtime -1: less than one day
-mtime 1: one day, 24-48 or <48 hours
-mtime +1: more than two days!


I made a suggestion for alternative time handling in the other bug that I copy to here as well:

-mtime lt 1d: less than one day (00:00:00 to 23:59:59.9999999999999, short < 24:00:00)
-mtime lte 1d: less or equal one day (00:00:00 to 24:00:00)
-mtime gt 1d: more than one day (24:00:00.0000000000001, short >24:00:00 to anything)
-mtime gte 1d: more or equal one day (24:00:00 to anything)
maybe -mtime eq 1d: exactly one day (24:00:00.000000000000)
Old semantic for -mtime 1 can be more clearly expressed by:
-mtime gte 1d -and -mtime lt 2d


Advantages:
1) a lot more intuitive to human beings
2) distinction between < and <= as well as > and >=
3) compatible with old scripts, cause old behavior can be kept (I actually teach the -[a|c|m]time wierdness since quite some time)
4) no conflict with input/output redirection
5) different units possible for times as well (d = days, h = hours, m=minutes, M=months, Y=years and such or even have it verbose to reduce ambiquity)
6) consistent with my suggestion for sizes ;)


-[a|c|m]time eq 1d makes no sense with nanosecond precision cause it hits extremely rarely. I´d skip -eq for times. Searching exact filesizes make more sense.

-[a|c|n]time eq "exact absolute time spec" makes more sense, cause search for an exact time doesn't seem to be possible at all at the moment as -[c|a|]newer goes with more or less (with !) but not equal

An option for timespec to limit resolution may be good to not have to type in the exact nanosecond timestamp. But then this could be expressed as after and (!) before as well to express a limited range.