TimeZones, timestamps and API
Status: Not prioritized
Description
I have a few questions centered around
this help document and how it conflicts with what I have been seeing while testing the REST API.
- In a production instance of SuperOffice would you expect GET ../TimeZone to return values, specifically UTC? In our test instances it does not return anything. If yes, then the other questions can probably be disregarded, but my understanding from looking at other documentation is that the timezone functionality needs to be specifically turned on.
- In other communications with you all, and in the document I linked above, I have been told variously that the database time is represented as, UTC+1, NO time (presumably following Europe/Oslo from IANA) and UTC. Since the NO time zone respects daylight savings I need clarity on if the database also respects daylight savings, or is consistently UTC+1, or is in fact UTC. In my own testing, datetimes do seem to follow the Norwegian timezone but it would be nice to have that confirmed.
- In the help document above, it says that createdAt and updatedAt are always UTC. Again, in my testing, this is not true. They are coming out as NO time. Since our test instance is also based in Norway I cant tell if these fields respect some timezone setting in SuperOffice or reflect the database time. This is important to know because of point 5.
- My guess is that the SO-TimeZone header only works if timezone functionality is turned on in SuperOffice and GET .../TimeZones returns values. In my testing, no datetimes were converted when trying to specify a timezone. Am I missing any steps beyond specifying UTC as the value for the header?
- The caveat to the above is that adding SO-TimeZone = includeTZOffset does convert createdAt and updatedAt to UTC, but only if looking up an object by ID, not when looking up a list of objects. For list lookups we can do a timezone conversion on our side if they follow a specific timezone, but I am confused by the difference in behavior.
What I did to create the situation in number 5:
- Connect to my test tenant that does not have timezones enabled in postman
- GET /Person/{id} with the header 'SO-TimeZone' set to 'includeTZOffset'
- See that the response has created/updatedAt in UTC, including the 'Z' timezone indicator
- GET /Person with the header 'SO-TimeZone' set to 'includeTZOffset'
- See that the response includes multiple person objects. Created/updatedAt is in Oslo time for every object and there is no timezone indicator.
info
Please log in to comment.
Details
| Issue id | 44931 |
| Registered | 25 Jul 2023 |
| Last modified | 30 Jan 2025 |
| Severity | Medium |
| Area | CRM |
| Status | Not prioritized |
| Target release | |
| Type | Bug |
Comments
Thank you for taking the time to report the issue. After careful consideration, we have decided not to address this bug at this time. Our decision is based on one or more of the following reasons:
Limited Impact: While we understand this issue affects your experience, it has a minimal impact on the overall functionality of the system.
Priority and Resources: Higher-priority tasks or strategic goals take precedence, and this issue does not align with our current focus areas.
Workaround Available: A viable workaround exists, reducing the need for an immediate fix.
We appreciate your understanding and hope you can agree on this. This allows us to focus on delivering greater value in other important areas.