Introduction
When querying data through APS APIs you might come across fields that store timestamps. In these cases, you always need to address the difference between the value you obtain and the value compatible with your end-user timezone. That's what we'll address in this blog.
When to consider Date and Time offsets
Imagine you're retrieving data through API and this data will be used to build a dashboard that can be used to keep track of a project or any other task where time is relevant.
In scenarios like this, you always need to show the information in a date and time compatible with your end-user context.
As an example, when a user accesses their files through ACC UI, they will always see the dates according to this system timezone (check the video attached to this blog for details), but when you query the same data using any API, this result might be seen in a different format.
That happens because in API responses, the date and time is returned in UTC timezone as a standard to address interoperability properly. (refer to RFC 3339).
This happens with many APIs.
To illustrate better you can check a few examples below:
- GET projects/:project_id from ACC - lastSignIn, createdAt and updatedAt fields
- GET workitems/:id from Design Automation - timeQueued, timeDownloadStarted, timeInstructionsStarted, timeInstructionsEnded, timeUploadEnded and timeFinished fields
- GET projects/:project_id/versions/:version_id from Data Management - createTime and lastModifiedTime fields
- DateTime Scalar from AEC Data Model
How to address Date and Time offsets
To present dates according to your end-user context, you should always check their current timezone and apply the equivalent offset to the timestamp obtained from the response.
You can find an interesting StackOverflow thread on that here.
Additionally, you can find an overview of the discussed scenario in the video below: