UTC timezone when using REST API

Add the SO-Timezone Header.

Best regards!

Hi Tony,

Thanks for the reply! Where I can get the timezone codes?

I tried with header SO-TimeZone:UTC and SO-TimeZone:UCT but it didn't work.

Best regards,

Alona

Hi Alona,

It only works if timezones are enabled in that client.

Hope this helps!

Hi Tony,

Thanks for the suggestion. Just enabled timezones on my SOD instance. Now I have Norwegian for both Timezone preference and Database time zone:

But I still get time in Norwegian timezone when making a REST API call. My request looks like this:

And the person in SOD:

Can I miss something else?

Best regards,

Alona

Hi Alona,

OK, I am sorry for not recognizing this sooner but it seems I created a bug report on this specific thing about a month ago.

https://community.superoffice.com/en/product-releases/bugs-wishes/product-issue/?bid=61151

Internal discussions on the topic lead to conclude that fixing this may have unknown cascading consequences and therefore is a high-risk change, and will need more time to consider changing the current behavior. 

Best regards.

Hi Tony,

Thanks for the clarification.

I assume then that REST API returns datetime in Database Time Zone. Is it possible to get the Database Time Zone for certain instance using REST API?

And would be really great if you answer one more question. Does Daylight Saving Time influence datetime values you get from REST API?

Thank you in advance,

Alona

Hi Alona,

Registered and Updated data is stored in the database as UTC - for stable travel transactions, etc. Getting those datetimes though is converted to local time.

All other datetimes, if you do not specify a different timezone, is local NetServer time when the data was created. Local NetServer time in online is Oslo time.

Yes, Daylight Savings always influences datetime. However it does not influence what you get from the API. If you save data with a specific datetime/timezone in Summer, it's not going to be returned to you adjusted for Winter time, you must always take those adjustments into account yourself.

TimeZone details are available using the archive or list endpoints, when timezones are enabled.

/api/v1/archive/TimeZones?$select=id,timeZone, etc.....
/api/v1/MDOList/timezonewithcode

Go ahead and continue to test these ideas out in some unit tests and hopefully they become clearer. 

Hope this helps!

Timezones support is now much improved: Documentation for the SO-TimeZones header is here.

You can now get timezone offsets included in the responses:

SO-TimeZone: NO, includeTZOffset

// SO-TimeZone: US-NY, includeTZOffset
// StartDate: "2018-12-24T07:34:45-0500" 
x = a.StartDate
// Mon Dec 24 2018 13:34:45 GMT+0100 (Central European Standard Time)
x.toISOString()
"2018-12-24T12:34:45.000Z"
x.getHours()
// 13
x.getUtcHours()
// 12