Good afternoon SuperOffice,
I am having a problem with the Updated Dates when accessing these in the Saas enviroment.
I have read the documentation here: https://docs.superoffice.com/en/api/netserver/web-services/so-timezone.html
It states that the Created and Updated dates are always in UTC, and that the SO-TimeZone header is ignored:
I have been testing this in postman, and the Updated Dates I am getting back from the API call are UTC + 2Hrs.
Below is an example of me update this company, as you ca see I did this at 15:11:18 (BST):
UTC for this would be 14:11:18pm, but when I call the API, I get a date of 16:11:18
I have tried to add the TimeZone header anyway, but get the same result:
Please could you advise where I am going wrong?
Cheers
Rich
Alle Svar (8)
Are timezones enabled in your environment? See also this thread: https://community.superoffice.com/en/technical/forums/api-forums/online-web-services/clarification-on-local-date-handling-in-superoffice-records/
I also ran the API call suggested by Tony to see what is configured and this looks correct also:
Please could you advise what the UTC dates are still not being returned by the API, when we have Timezones enabled?
Is there anything else we need to configure?
Cheers
Rich
Hi,
See the answer from Tony in this thread: https://community.superoffice.com/en/technical/forums/api-forums/online-web-services/utc-timezone-when-using-rest-api/ (the second one from november 8th) and the #5 point from this bug report: https://community.superoffice.com/en/product-releases/bugs-wishes/product-issue/?bid=44931&azure=1
Looks like that indeed the created and update dates when retrieving them using an archive provider are not correctly returned as UTC.
Hi Richard (and David)!
I have been able to [somewhat] reproduce your issue. I have enabled TimeZones and set it to UTC, just like you.
I've created an appointment at 11:37 local time
Issing a GET appointment by id request WITHOUT SO-Timezone header shows registered (CreatedDate) and updatedDate in local timezone
Issing a GET appointment by id request WITH SO-Timezone header (UTC, includeTZOffset) shows registered (CreatedDate) and updatedDate in UTC timezone
Using time.gov verifies these times:
Using an archive provider to look up this appointment, with SO-Timezone header does return erronious values, local time + 2, which is as David stated, and known bug.
Without the SO-Timezone header, it returns localtime:
So it does confirm the bug with archive queries and registered/updated dates again.
Thank you for reminding us of this issue and bringing it back to focus. We understand the frustration caused by the need for workarounds at this time. Unfortunately, because this issue has been known for sometime, others have already invest in workarounds, and any changes now will need to be communicated well in advanced. Any prioritization on this topic will have to be deferred until the next major version of the product, a time when breaking changes can be introduced. We appreciate your understanding and will keep you updated on any progress.