You could make the parameter that window/time range.
Obviously your underlying will have to change.
If it's always 30 days windows like your two examples suggest (is that sample really representative, or do they still want ability to do 60, 90,other day ranges?) , than you're lucky in that you can present the parameter text as "30-60 days" or "60-90 days", but still use an integer parameter value. If you treat @days as the minimum date, you could use something like
-- Start Date (Datetime since we're using GETDATE)
DateOpened >= DATEADD(DAY,-@days,GETDATE()) AND
-- End Date (Datetime since we're using GETDATE)
DateOpened < DATEADD(DAY,-@days+30,GETDATE())
Question: Is logic supposed to be based on exact time, or just date? Aging reports tend to be based on whole days.
GetDate is datetime. Is DateOpened a date or a datetime? For a 30-60 day report, do you want to exclude everything on 05/30 because 2021-05-30 00:00 is less than 2021-05-30 09:45:44.730?
Or is the intent to base it on date only? If the latter, then you need to convert the current time to a date -- e.g., CAST(GETDATE() AS DATE). If DateOpened is a date, this could help ensure more efficient queries by avoiding type conversion & enabling index on DateOpened to be used.