[AAP-62956] Change datetime to use utc as timestamp instead of local timezone#921
[AAP-62956] Change datetime to use utc as timestamp instead of local timezone#921RudneiBertolJr wants to merge 1 commit intoansible:develfrom
Conversation
RudneiBertolJr
force-pushed
the
AAP-62956
branch
3 times, most recently
from
2aa641e to
da8bc7f
Compare
|
I would just like to have some form of testing for this, but I am struggling to see what that would be. Ultimately, this is compared against some time diff, but on another server. It's this other side of the token expiration implementation that this need to match. And that needs to use UTC. Presumably that could be hunted down, and if in DAB, tested against. |
|
Hey @AlanCoding, |
|
|
||
| if expiration is not None: | ||
| payload["exp"] = datetime.now() + timedelta(seconds=expiration) | ||
| payload["exp"] = datetime.now(timezone.utc) + timedelta(seconds=expiration) |
There was a problem hiding this comment.
Actually, if you have the ability to re-test, I would kind of prefer
from django.utils import timezone
now = timezone.now()There was a problem hiding this comment.
In [1]: from django.utils.timezone import now
In [2]: now()
Out[2]: datetime.datetime(2026, 1, 20, 21, 44, 41, 966889, tzinfo=datetime.timezone.utc)
In [3]: from datetime import datetime, timedelta, timezone
In [4]: datetime.now(timezone.utc)
Out[4]: datetime.datetime(2026, 1, 20, 21, 44, 54, 837486, tzinfo=datetime.timezone.utc)
In [5]: now()
Out[5]: datetime.datetime(2026, 1, 20, 21, 44, 59, 91693, tzinfo=datetime.timezone.utc)
They seem to be the same thing. I had the wrong import, it is from django.utils.timezone import now. This is the most standard thing to use now().
There was a problem hiding this comment.
Yeap, I have tested and they are the same. I will change my PR to use now().
>>> from django.utils.timezone import now
>>> now()
datetime.datetime(2026, 1, 20, 22, 5, 38, 890072, tzinfo=datetime.timezone.utc)
>>> from datetime import datetime, timedelta, timezone
>>> datetime.now()
datetime.datetime(2026, 1, 20, 14, 6, 8, 126278)
>>> datetime.now(timezone.utc)
datetime.datetime(2026, 1, 20, 22, 6, 24, 138297, tzinfo=datetime.timezone.utc)
>>> now()
datetime.datetime(2026, 1, 20, 22, 8, 12, 107243, tzinfo=datetime.timezone.utc)
AlanCoding
left a comment
AlanCoding
left a comment
There was a problem hiding this comment.
I think it's worth it to put in the now() pattern, because this happens so many times in related code we should standardzie
RudneiBertolJr
force-pushed
the
AAP-62956
branch
from
da8bc7f to
409ad4b
Compare
Fixing the issue reported at AAP-62956
RudneiBertolJr
force-pushed
the
AAP-62956
branch
from
409ad4b to
fb390f9
Compare
|
DVCS PR Check Results: PR appears valid (JIRA key(s) found) |
|
2 participants
Fixing the issue reported at AAP-62956
Description
Changing the module datetime to use UTC data to generate the expiration timestamp for the token.
When customer has controller node with TIME_ZONE variable configured to a timezone with timezone grater than 1h, generated tokens are generated already expired.
Now, it does not matter the timezone, the token will respect the expiration time set.
Type of Change
Self-Review Checklist
Testing Instructions
You can use the instructions for the reproduce at https://issues.redhat.com/browse/AAP-62956
Expected Results
Now does not matter the timezone between client and server, the expiration timestamp should respect the expiration time based on the UTC timezone.