Fixing randomly failing test

[IlianIliev]

Pull Request check-list

Please make sure to review and check all of these items:

• Do tests and lints pass with this change?
• Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
• Is there an example added to the examples folder (if applicable)?
• Was the change added to CHANGES file?

NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open.

Description of change

This test fails randomly depending on whether it runs close to the end of the second or not.

For example, if the test runs at 1527800400.999999, then the integer value of the timestamp + timedelta of 1 seconds = 1527800401. This way when we call r.hexpireat with that value, the combination of the time spent in the python code and the network delay adds enough time to cause the expiration timestamp to be in the past when received by the server.
As a result, the result value of the hexpireat is 2 (timestamp in the past) instead of 1.

[IlianIliev]

I realized there is similar logic in core.py -> https://github.com/redis/redis-py/blob/master/redis/commands/core.py#L5265-L5266

if isinstance(unix_time_seconds, datetime.datetime):
    unix_time_seconds = int(unix_time_seconds.timestamp())

This causes failures when running test_hexpireat_with_datetime.

One option is to change the test to ensure it always rounds down the microseconds. Another is to change the core.py, which will change the logic and may result in a non-expected behavior for the user.

[vladvildanov]

@IlianIliev Let's go with option 1 for now

[vladvildanov]

@IlianIliev As I see pypy 3.10 still failing cause of hexpireat

[IlianIliev]

@vladvildanov, I missed some of the tests during the initial fix. I hope I have covered all of those now.