feat: implement `delete_message_seconds` for bans

[shiftinv]

Summary

Implements delete_message_seconds and deprecates delete_message_days while keeping backward compatibility.

Documentation may eventually (once the api docs PR is merged) need an update as it doesn't seem like deleting a few minutes' worth of messages works as expected, which could indicate that the lower bound isn't actually 0 and/or that the step size is 60 minutes/1 hour.

Resolves #657.

Checklist

• [x] If code changes were made, then they have been tested
  • [x] I have updated the documentation to reflect the changes
  • [x] I have formatted the code properly by running task lint
  • [x] I have type-checked the code by running task pyright
• [ ] This PR fixes an issue
• [x] This PR adds something new (e.g. new method or parameters)
• [ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
• [ ] This PR is not a code change (e.g. documentation, README, ...)

[onerandomusername]

I don't think we need to deprecate delete_message_days as it is more user friendly than delete_message_seconds. We could potentionally add a timedelta parameter and keep delete_message_days for the time being.

eg delete_since and support both a datetime and timedelta being passed to it.

[shiftinv]

I don't think we need to deprecate delete_message_days as it is more user friendly than delete_message_seconds. We could potentionally add a timedelta parameter and keep delete_message_days for the time being.

eg delete_since and support both a datetime and timedelta being passed to it.

Not deprecating delete_message_days sounds fine, but I'd be careful with implementing a datetime parameter, since we can't guarantee that it would actually delete up to that point (think ratelimits). Not sure about timedelta, but I suppose that would be less of an issue.

Either way, this depends on how the upstream issue with inaccuracies is resolved, as the API seems to be rounding the number of seconds to some value (hours?), which isn't documented yet.

[onerandomusername]

Either way, this depends on how the upstream issue with inaccuracies is resolved, as the API seems to be rounding the number of seconds to some value (hours?), which isn't documented yet.

is there an issue on the discord api docs repo concerning this discrepancy?

[shiftinv]

is there an issue on the discord api docs repo concerning this discrepancy?

not an issue, but a comment on the relevant PR, https://github.com/discord/discord-api-docs/pull/5219#issuecomment-1192344340

edit: escalated by devs internally, waiting for a response

[onerandomusername]

This should have a documentation note about discord/discord-api-docs#5439 for the time being, otherwise looks good if that's added.

[shiftinv]

I don't think we need to deprecate delete_message_days as it is more user friendly than delete_message_seconds.

https://github.com/DisnakeDev/disnake/pull/659/commits/78838089800f0457015bccece76a39ad29d6c50f

This should have a documentation note

https://github.com/DisnakeDev/disnake/pull/659/commits/f1778175374b04433bf3f6fa5d9b15368d3f89a8

---

Still need to think about the timedelta parameter, seems like something that could easily be implemented in user code as well (and we wouldn't have to worry about naming things :^) ).

[shiftinv]

api issue seems to be fixed \o/ parameter name still isn't fully decided yet, I've renamed it to delete_message_duration for now

[onerandomusername]

https://github.com/DisnakeDev/disnake/pull/659/commits/09983210f132e64b2085b859bf68f7ba61964879

@shiftinv would you please update the pull name?

[shiftinv]

update the pull name?

done

[shiftinv]

We should probably error if both delete_message_days and clean_history_duration are provided at the same time.

https://github.com/DisnakeDev/disnake/pull/659/commits/976c3ca00ef43465fecdd1185deb48c9e858cfb8