Searching for files with 'Not older than' option

[MarcinW]

When searching for files (Alt+F7) with "Not older than" option, there is a subtle problem with date/time range calculation algorithm.


Let's take a look at the algorithm (X means the number of days/hours/etc. that the user entered):

1) When using "days", "weeks", "months and "years" options - i.e. when a date range is used for calculation (time is ignored) - the algorithm is:

find files that have date >= Now-X

Since date is internally represented in days, the calculation resolution is one day here. So X=0 means: "today".


2) When using "minutes" and "hours" options - i.e. when a time range is used for calculation - the algorithm is:

find files that have time >= Now-X

Since time is internally represented in seconds, the calculation resolution is one second here. So X=0 means: "this second".



So let's create a file and search for it:
Not older than 0 years: the file will be found
Not older than 0 months: the file will be found
Not older than 0 weeks: the file will be found
Not older than 0 days: the file will be found
Not older than 0 hours: the file will not be found
Not older than 0 minutes: the file will not be found

This is quite counterintuitive. But when we look at the algorithm above, it becomes clear, that the user has no chance to find anything when using 0 hours or 0 minutes option - because it is possible to find a file only in the same second that the file was created. So in practice it's impossible, and 0 for hours or minutes has no practical use.

On the other hand, it's also not very intuitive that using 0 years will find only files from the same day.



Strictly speaking, using the 0 value would always be useless (for all: minutes, hours, days, weeks, months or years) when calculating with an infinite precision, because, for X=0, the equation becomes: FileDateTime >= Now. But since FileDateTime cannot be greater than Now, the equation becomes: FileDateTime = Now.

From the other side, TC doesn't define anywhere, what the 0 value means. So it may be only presumed, that most users don't use the 0 value at all or assume that it means "current minute", "current hour", "current day", etc.



So I can see two solutions:
1) Disable the possibility of using the 0 value.
2) Clearly define the 0 value as the current minute/hour/etc. and modify the algorithm for the 0 value:

For example, for Now = 2016-07-21 21:13:53:
0 minutes = current minute = from 2016-07-21 21:13:00
0 hours = current hour = from 2016-07-21 21:00:00
0 days = current day = from 2016-07-21 00:00:00
0 weeks = current week = from 2016-07-18 00:00:00 (according to ISO 8601, Monday is the first day of the week)
0 months = current month = from 2016-07-01 00:00:00
0 years = current year = from 2016-01-01 00:00:00


All these notices apply also to the newly introduced "Older than" functionality.


Regards

[milo1012]

So in practice it's impossible, and 0 for hours or minutes has no practical use.

Finding future timestamps is of no practical use?
In fact I have a search preset set to "zero minutes" for such task, because I had a few situations where I needed it, due to timezone differences or some remote machines having a future system clock set.
As I see it, if you drop this possibility, you could search in TC for future timestamps only by putting some random future date in the "Date between" field.

I don't see how this is a bug, as it works like expected.

2) Clearly define the 0 value as the current minute/hour/etc. and modify the algorithm for the 0 value

I would find this approach very confusing and it would break current behavior.

[MarcinW]

Finding future timestamps is of no practical use?

Ok, you are right, it may have practical use.

I don't see how this is a bug, as it works like expected.

I can't agree that it works as expected*. For X=0 it should either find only future files, regardless of minute/hour/day/week/month/year setting - or work consistently, without such surprises, that I described in my initial post. I don't think it's expected, that you find only future files for 0 minutes and 0 seconds, but also some past files for 0 days/weeks/months/years.

* It's also the problem, that the behavior must be expected, because it's not clearly defined.

I would find this approach very confusing and it would break current behavior.

Well, as for me the current behavior is already broken... So something should be done to make it clearly defined and predictable.


Regards

[ghisler(Author)]

This is done because people think differently in days and hours:

1. When the unit is "days" or longer, TC assumes a corresponding time of 00:00. So for an age of 0 days, everything until the previous midnight is found.

That's what people normally say when they mean something is one day old: It was purchased sometimes on the previous day, the time doesn't matter.

When the unit is hours or newer, the exact time is used: When you say something is max 1 hour old, you look on the watch and substract one hour. Something which is 0 hours old must be created exactly now.

[MarcinW]

I fully accept your explanation.

So for an age of 0 days, everything until the previous midnight is found.

Currently, the problem is that TC doesn't conform to your point of view (which we both agree is right).

As you said, people understand "0 days" as "from midnight to now = this day". And TC works exactly in this way.

But when people think "0 months", they mean "this month". But TC finds only files from "this day".

When people think "0 years", they mean "this year". But TC still finds only files from "this day".


Basing on my example for Now = 2016-07-21 21:13:53:

0 minutes = current minute = from 2016-07-21 21:13:00
0 hours = current hour = from 2016-07-21 21:00:00
I don't stick to this. Maybe it's not a good idea to implement this.

0 days = current day = from 2016-07-21 00:00:00
It's what TC currently does.

0 weeks = current week = from 2016-07-18 00:00:00 (according to ISO 8601, Monday is the first day of the week)
0 months = current month = from 2016-07-01 00:00:00
0 years = current year = from 2016-01-01 00:00:00
TC currently does not work in this way. When selecting 0 weeks, months or years, TC searches for 0 days.

So I think it would be nice to correct TC behavior for weeks, months and years.

[ghisler(Author)]

But when people think "0 months", they mean "this month". But TC finds only files from "this day".

Hmm, it's not that easy: If you say it's maximum one month old, people usually think that it's 30 or 31 days old, not that it was purchased last month. 0 month old is usually not used this way at all.

[MarcinW]

Well, it's possible, that some people think like that. It's unclear.

But when we count in days, we truncate all lower units (hours, minutes and seconds).

So when counting in months, why not to truncate also weeks and days?

Currently there is no difference between searching for 30/31 days and 1 month in TC. So option for searching months brings no additional functionality and is a bit redundant. Maybe it would be good to have more powerful possibilities than less powerful... I mean two different functionalities when searching for days and for months, not the same, duplicated functionality.

After all, when searching for a 1-month old file and counting from the beginning of the previous month, both users will be satisfied: a user understanding "1 month" as 30/31 days and a user understanding "1 month" as the time from the beginning of the previous month.

Currently only the first user will find his file, the second not.

[ghisler(Author)]

For now I will leave it as it is. Changing it now after so many years would lead to even greater confusion.

[MarcinW]

Well, TC9 brings a new "Older than" functionality, so it's clearly visible that something changed. This may be the best moment to correct the behavior.

But even if not, it would be nice to have this functionality precisely described in the help file. Currently there is no information about the algorithm used for time/date ranges.

Regards