REST API and Timezones
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2015 11:40 AM
I have been experimenting with the REST APIs and Date/Time fields. I am POSTing to an Import Set and then GETing from the corresponding table. When we post, we are posting all Date/Times in 'GMT', but for the longest time I couldn't figure out why I wasn't getting the expected date when I was retrieving the record. I finally discovered documentation that said that the dates are returned using the user's timezone that was used in the REST call. Sure enough, setting my test user's timezone finally meant that I could retrieve the same date that I posted.
However, I am trying to develop a consumer of these REST calls that doesn't know about the user in service now. Is there a way to programmatically ask for the dates in 'GMT' or in a format that includes the timezone so that I can normalize it in our code? It seems very odd that my backend application should have to know anything about the service now user's account other than the fact that it is authorized to make the calls and access the data. Or is there some other way to handle date/times when using REST?
Thanks for your help.
- Labels:
-
Integrations
-
Scripting and Coding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-20-2015 07:11 AM
Could you not create an API account and have this set to "GMT"? You would then know that any returning result would be "GMT" and then process as required.
The other way would be to create a scripted web service and then process as required, returning the GMT time or by passing a timezone, return the correct time for the timezone.
Scripted Web Services - ServiceNow Wiki
Pete
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-21-2015 06:05 AM
Thank you for your suggestions, Peter.
The first suggestion is what we are currently doing. While it does work, it's not really ideal. Our end goal is to provide the application with data controlled by varying roles, but have the user set up whatever account credentials they want to. So, that means we currently have to tell the user to make sure to set the timezone on whatever account they are using. Not very user friendly.
I looked at the scripted web service link that you provided. It seems to be SOAP only and we'd rather stick to REST unless we have no other option.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-21-2015 06:20 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-23-2015 06:45 AM
Hmmm...well, the default value for sysparm_display_value is false and we are not changing it. So maybe the weirdness is on import to the update set? I am positive that we are always sending the date/time in UTC. I've checked the payloads while debugging and the times are correct. I did a few more experiments where I left the uploaded date/time the same, but changed the Timezone on the REST user. First GMT, then US/Eastern, then US/Pacific (System time). I would expect that if the insert is leaving things alone, that changing the timezone for the REST user would have no effect unless I am looking at the return values for a REST GET. Instead, when I look at these values in the ServiceNow UI, they all are hours apart.
It appears I made the wrong assumption and asked the wrong question. How then do I get SN to not convert a date/time that is imported through an update set?