Is ExpiresAt a Unix timestamp? Would it hurt to add some information to the documentation?
I figured out that this is a Unix timestamp, but the time zone is a little ambiguous. If I look at the expiration time on the admin page, it says 4/3/26 at 11:59:59 PM, but when I convert ExpiredAt to a DateTimeOffset in C#, the expiration is given as 4/4/26 at 4:59:59 AM.
So, I assume that the expiration time shown on the admin page is my local time? This doesn’t make a lot of sense to me, because why would the license expiration time depend on the time zone of the person who added the entitlement? If I set the expiration date of the entitlement (through the admin page), it appears to default to 11:59:59 on that date in my time zone. But I might be creating a license for a customer in Turkey. When my software running in Turkey reads the ExpiresAt value, how should it be interpreted? The software doesn’t know whether I created the entitlement or one of my colleagues in Italy did.
Should I be dealing with ExpiresAt differently?
I really think that if you are going to store an expiration “date” as a Unix timestamp, it should be the timestamp for 11:59:59 PM on that date in UTC. Then the software can interpret that timestamp as UTC, and throw out the time part. I think this is the only reliable way to ensure that ExpiresAt represents a date, and not a specific time.
1 Like
Hi Michael,
Thank you for reaching out.
Your understanding is correct. The expiresAt value, along with other timestamps, is stored as a Unix timestamp, representing a specific point in time in UTC. When this value is processed in your application, it is interpreted in UTC.
In the admin portal, the expiration time is displayed in your local timezone for convenience. As a result, it may appear as April 3, 11:59:59 PM in the portal, while the same timestamp corresponds to April 4, 4:59:59 AM in UTC.
We do have an enhancement on our roadmap to support setting a specific time along with the expiration date. This should help eliminate such discrepancies.
Thank you Anees.
This doesn’t completely answer my question, though. I saw in a response to another issue that you modified the software so that setting an expiration date through the portal now sets the expiration to the end of the day. I assumed that’s why the portal reports the expiration time as 11:59:59. But that is 11:59:59 in the time zone of the user setting the expiration date, not UTC. This is what causes the confusion when it comes to interpreting the ExpiresAt value. If my software doesn’t know the time zone of the creator of the expiration date, then it can’t reliably determine which date was actually intended.
Let me say this another way. It appears that the portal is setting the ExpiresAt value using the time zone of the user (possibly because the calculation is being done client-side). So the time displayed in the portal is 11:59:59, but the actual timestamp stored can be some other time (in UTC). What should happen instead is that the the system sets the timestamp to 11:59:59 UTC, and then the portal front-end converts that value to the local time zone. In my opinion, it would be better to display the time in UTC even in the portal, to make it clear that the expiration time does not depend on the time zone of the user.
I hope that clarifies my concern.
We completely understand your concern. For the time being, we will add a hint in the UI to improve clarity. Additionally, a revamp of the timezone system is already on our roadmap, and we will keep you informed here once it is live.
In the meantime, if you have any further questions or require assistance, please feel free to reach out to our support channel at support@cryptlex.com
Kind regards,
Anees