Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

expires_unix is not giving consistent results #975

Closed
glensc opened this issue Mar 17, 2024 · 1 comment · Fixed by #980
Closed

expires_unix is not giving consistent results #975

glensc opened this issue Mar 17, 2024 · 1 comment · Fixed by #980
Labels
Milestone

Comments

@glensc
Copy link
Contributor

glensc commented Mar 17, 2024

The problem

I was exploring cache contents and found something odd, r.expires_unix fluctuates 1s between different runs on same data.

    for r in session.cache.responses.values():
        print(f"{r.expires_unix}: {r.url}")

different outcome from different runs:

➜ grep 'https://api.trakt.tv/shows/134421/seasons?extended=episodes' /tmp/cache[456]
/tmp/cache4:1710720658: https://api.trakt.tv/shows/134421/seasons?extended=episodes
/tmp/cache5:1710720659: https://api.trakt.tv/shows/134421/seasons?extended=episodes
/tmp/cache6:1710720658: https://api.trakt.tv/shows/134421/seasons?extended=episodes

Expected behavior

It should be 1710720658 or 1710720659 on every run.

Environment

  • requests-cache version: 1.2.0
@glensc glensc added the bug label Mar 17, 2024
@JWCook
Copy link
Member

JWCook commented Mar 19, 2024

It looks like the current method for converting to a unix timestamp introduces a bit of randomness based on the delta from the current time and rounding the microseconds value to the nearest second. I can fix that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants