Just found this in the GH actions logs:

=================================== FAILURES ===================================
2020-06-04T13:44:39.7343980Z ______________________ TestFilters.test_filters_date_init ______________________
2020-06-04T13:44:39.7344363Z
2020-06-04T13:44:39.7346253Z self = <tests.test_filters.TestFilters object at 0x7f9d1cc08208>
2020-06-04T13:44:39.7346551Z
2020-06-04T13:44:39.7346827Z def test_filters_date_init(self):
2020-06-04T13:44:39.7347871Z with pytest.raises(ValueError, match='at minimum'):
2020-06-04T13:44:39.7348197Z > Filters.date(seconds_ago=0)
2020-06-04T13:44:39.7348389Z
2020-06-04T13:44:39.7348672Z tests/test_filters.py:52:
2020-06-04T13:44:39.7348925Z _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
2020-06-04T13:44:39.7349125Z
2020-06-04T13:44:39.7349393Z self = date, seconds_ago = 0
2020-06-04T13:44:39.7349772Z
2020-06-04T13:44:39.7350092Z def init(self, seconds_ago=None):
2020-06-04T13:44:39.7350379Z if not (bool(seconds_ago)):
2020-06-04T13:44:39.7350926Z > raise ValueError('seconds_ago must be used')
2020-06-04T13:44:39.7351241Z E ValueError: seconds_ago must be used
2020-06-04T13:44:39.7351442Z
2020-06-04T13:44:39.7351729Z telegram/ext/filters.py:1417: ValueError
2020-06-04T13:44:39.7351915Z
2020-06-04T13:44:39.7352159Z During handling of the above exception, another exception occurred:
2020-06-04T13:44:39.7352359Z
2020-06-04T13:44:39.7352632Z self = <tests.test_filters.TestFilters object at 0x7f9d1cc08208>
2020-06-04T13:44:39.7352880Z
2020-06-04T13:44:39.7353132Z def test_filters_date_init(self):
2020-06-04T13:44:39.7353800Z with pytest.raises(ValueError, match='at minimum'):
2020-06-04T13:44:39.7354155Z > Filters.date(seconds_ago=0)
2020-06-04T13:44:39.7354698Z E AssertionError: Pattern 'at minimum' not found in 'seconds_ago must be used'
2020-06-04T13:44:39.7354953Z
2020-06-04T13:44:39.7355178Z tests/test_filters.py:52: AssertionError
2020-06-04T13:44:39.7392319Z ##[group] Coverage report

Found this. will push the change.

Hey, just a quick question: Can you tell me a real "life" usecase for a bot, where it makes sense to only handle an update when it was send X seconds ago?

Hey, just a quick question: Can you tell me a real "life" usecase for a bot, where it makes sense to only handle an update when it was send X seconds ago?

I'm experiencing issues with users sending commands when they don't have an internet connection, the bot/server was restarted and myself during development (send commands when test bot was down -> flooding test bot once back up). So i just want to ignore everything that's older than x seconds in my bots. I currently have this implemented by creating my own filter class but thought it might be useful for others as well.

edit: re-reading your question it looks like you're under the impression is want to do the opposite: only handle old commands. well... i don't :) i have this
dp.add_handler(MessageHandler(filters=(~myFilters.date(seconds_ago=10)), callback=warn_old_msg))
and warn users their commands are ignored.

@ikkemaniac Oh, and starting clear is not what you want to aim for? Thats what I do. If someone sends an update during a downtime and it was important, they will resend it later.

@ikkemaniac Oh, and starting clear is not what you want to aim for? Thats what I do. If someone sends an update during a downtime and it was important, they will resend it later.

Uhhh... facepalm... never really thought about it. Nevertheless they won't get informed would they?

@ikkemaniac "they won't get informed"

You mean that the bot was down? No. I normally have a support channel for that stuff, or I could iterate over the recently used by user ids, if I want that. But thats not really the point now ;P

I personally don't really see the usecase for this filter, but your example is okay. If it is well implemented, its just another filter, so I would personally be fine with it.

The maintainers stance currently though is that its too much of a specific case to be worth included in our library. I will ping the other ones and see if your example changed that; if not, we might have a different solution coming in the future for these kind of special cases :)

ok

Hi @ikkemaniac ,

We've discussed this PR and the proposal you're making in the developers group, and we decided to reject your PR.
As it is, the usecase is too specific to add to the library, and it serves almost the exact same purpose as the clean parameter to start_webhook/updater. We see a usefull addition to the library to modify clean to accept a datetime or timedelta in addition to a bool, that will only clean messages sent before that period. If you're up to proposing that that would be great.

I'm closing this PR.