[Feature] Relative date filters

[RyanCrossby]

Describe the feature you'd like

I would like to enable filtering using relative dates for fields such as release date, updated date, and created date. Currently, we can filter using absolute dates, like all scenes released after January 1, 2023, but there is no option to specify relative timeframes, such as scenes added in the last 30 days.

Describe the benefits this would bring to existing users

Implementing relative date filtering would enhance the flexibility and usability of the search feature, allowing users to quickly find content based on a specific timeframe without needing to manually calculate dates. Users could save these filters as permanent options, improving their overall experience and efficiency in locating relevant scenes.

Is there an existing way to achieve this goal?

At present, the only method available is to manually calculate the date and use absolute dates for filters. While this can work for ad-hoc searches, it does not allow for the creation of permanent or reusable filters.

Additional context

My idea is to use the same greater than/less than filter we currently have, with the ability to specify a number followed by "days" (e.g., release date greater than: 30 days). Other approaches may also be considered, but this format would provide a straightforward solution.

[Gykes]

@WithoutPants

The backend work is done for this and I have several ways to handle to UI. I was thinking there are 2 ways we can handle this.

1. Use the current front end for date, created at, updated at, etc and just add a new field into the existing filter there for relative date.

2. Create a new filter that would be Date (Relative) and same with the others.

Essentially do we want to combine them in the UI or keep the separate? I feel like keeping them separate would be the best bet to give people more options for filtering but it increases UI clutter

[WithoutPants]

Adding (relative) filter entries would add far too much clutter.

I would look at adapting the date input for filtering to accept -x, meaning x days ago. We could expand this to add suffixes for months or years, but I'm not sure how much we need. A mouseover hint explaining possible values is probably a good idea.

[Gykes]

Hmmm, okay.

Currently I have them separated in the UI and my testing is showing that it is working. I will combine them into the non-relative filters and PR it so you can have a look.

I'm not quite sure what you mean by the -x. I presume you mean by adding in a new string modifier to take the input in days and apply accordingly. Currently I have logic that accepts a Days/Months/Years operator which I believe to be a better way to handle it but will let you decide once we can get some eyes on it.

[Gykes]

So, I played around with it some and came up with something like this. It autodetects based on what is filled out. If there is a date selected then the relative date defaults to 0 and does nothing. I was tempted to add in a button for Absolute vs Relative so that users don't get confused when they cant select both.

The dropdown allows users to select Days, Months, or Years and they can input a desired integer. The verbage is obviously temp till I get a go ahead on UI style

[RyanCrossby]

@Gykes Thanks for looking into this!

Since this is a fairly advanced and niche feature, I suggest keeping the UI simple and avoid cluttering it too much.

Building on the previous suggestions, I think it's best to always have a single field displayed to the user. The two possible approaches I can think of are:

• A toggle to switch between absolute and relative (defaulting to absolute).
• A combined field that supports both absolute and relative input.

I would lean toward the second option, as it seems simpler both for users and for the implementation. The behaviour would be:

• typing directly in the field defaults to absolute dates (as-is)
• the date picker continues to set absolute dates (as-is)
• entering a value starting with a "+" or "-" switches to relative mode, with:
  • a mandatory number
  • an optional specifier ("d" or "m" or "y", defaulting to "d")
  • Example: '-30d' => '30 days in the past', '+15' =>'15 days in the future'.
• all other formats are displayed as invalid (as-is), perhaps with the relative date syntax shown in the error message and in the placeholder

PS: I'm not entirely sure how many use cases there are for relative dates in the future, but I wanted to outline the general idea.