[bug #37110] find: alternative time handling

[Martin Steigerwald]

URL:
  <http://savannah.gnu.org/bugs/?37110>

                 Summary: find: alternative time handling
                 Project: findutils
            Submitted by: martin21
            Submitted on: Mi 15 Aug 2012 17:30:07 GMT
                Category: find
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.4.2
           Fixed Release: None

    _______________________________________________________

Details:

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:

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

I get – quoted from the other bug:

address@hidden:/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 
address@hidden:/tmp/find-times> date 
Mi 15. Aug 16:29:51 CEST 2012 
address@hidden:/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. 
address@hidden:/tmp/find-times> find -mtime +3 -printf "%p\t %t\n" | sort 
+3 translates to more than 4 days ago, thus no results 
address@hidden:/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: 
address@hidden:/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) 
address@hidden:/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.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37110>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/