My system has some major drift between System.system_time and System.os_time, by about 97 minutes. I realize that this may not be a everyday common occurance for most people, and I'm not 100% sure of why it's happening locally, but it does seem that System.os_time will always return a more reliable timestamp, as will DateTime.utc_now() which seems to use os_time internally. I'm wondering if there's a reason for the use of System.system_time rather than os_time in this library, as system_time seems to at least sometimes have consistency issues that the other options don't seem to have.
~96 minutes, 1.6 hours. My access TTL is 60 minutes, hence the expiration immediately on creation.
It's harder to show here via code, so you'll have to trust me, but the DateTime call is in line with the true time, and the system_time call is behind the true time, rather than DateTime being ahead, and that's confirmed with my laptop's displayed time, my cell phones displayed time, and https://www.unixtimestamp.com/ time.
Happy to submit a PR for this, but wanted to first check if there was conscious decision to use system_time over os_time, or a reason not to use os_time/DateTime.
Steps to Reproduce
This one might be a little hard to reproduce exactly as some of the issues might be OS/machine dependent. But the steps seem to be:
exchange
, but from what I can tell the issue is with theGuardian.timestamp
function)I've written a bit more about it in this ElixirForum post: https://elixirforum.com/t/guardian-generating-an-expired-token-because-system-system-time-datetime-is-this-time-warp/56110/13
My system has some major drift between
System.system_time
andSystem.os_time
, by about 97 minutes. I realize that this may not be a everyday common occurance for most people, and I'm not 100% sure of why it's happening locally, but it does seem thatSystem.os_time
will always return a more reliable timestamp, as willDateTime.utc_now()
which seems to useos_time
internally. I'm wondering if there's a reason for the use ofSystem.system_time
rather thanos_time
in this library, assystem_time
seems to at least sometimes have consistency issues that the other options don't seem to have.Expected Result
A non expired JWT token
Actual Result
An expired JWT token.
The code underlying the
sign_in
function:Call to
system_time
showing the time drift:~96 minutes, 1.6 hours. My access TTL is 60 minutes, hence the expiration immediately on creation.
It's harder to show here via code, so you'll have to trust me, but the
DateTime
call is in line with the true time, and thesystem_time
call is behind the true time, rather thanDateTime
being ahead, and that's confirmed with my laptop's displayed time, my cell phones displayed time, and https://www.unixtimestamp.com/ time.Happy to submit a PR for this, but wanted to first check if there was conscious decision to use
system_time
overos_time
, or a reason not to useos_time
/DateTime
.