Inconsistent time display value on serviceNow incident form

[Ni Li]

We are currently developing a API call to update 4 timestamp fields (u_function_last_worked, u_issue_start, u_time_resolution_team_assembled, u_mitigation_time) in incident form. Out of the 4 fields, u_function_last_worked is the only one that auto added the time difference between UTC and CST time zone in the XML file, so that the display value shows the same as we entered through API. However, the remaining 3 was entered as the same value into the XML file, which lead to the time conversion showed up on the display value. Can anyone please help with the inconsistent display values between all the timestamp fields? 

I have attached the API call request body, XML file and the display value on incident form for your reference.

Please do not hesitate to reach out if you have any concerns. 

[-O-]

Actually only the 3 fields are set correctly/as expected/as documented.
It is the one where there is no match between the REST Payload and the XML that is not OK.

I can only assume that some business rule overwrote the value and that is why a difference is shown.

Considering that the data/time format YYYY-MM-DD HH:mm:ss does not contain time zone information the only safe option is the send and interpret in UTC - which did happen for the 3 fields, which is expected and documented.

You say

However, the remaining 3 was entered as the same value into the XML file, which lead to the time conversion showed up on the display value

The time conversion has nothing to do with all this.

That "time conversion" happens all the time because of how date/time fields work - values (ALWAYS) stored in UTC are converted on the fly (just for the purpose of displaying those to the user), into the time zone and format of the current user.

Easy to test too: take any date/time field, note the date/time value in it while looking at its "XML", look at the data/time value displayed in the form, calculate the difference and see that it is equal to the offset for the current time zone selected in your profile.

Change the time zone in your profile, note that after the form is refreshed, the data/time is "converted" (not), but if you refresh the XML, it remains the same - because date/times are always stored only in UTC.

That is why using any other time zone then UTC in REST payloads is not a solid solution.

E.g. someone changes the integration to run under a different user with a different time zone configured (than the one originally expected) and the dates will be hosed starting that moment.

Or someone updates the time zone on the profile of the user used to execute the integration and again dates are hosed.

Of course in the general panic trying to figure out what is going wrong, nobody will think of checking which is the integration user and what is the configured time zone for it.

To make it worse, the same can happen at the sending site too.

Debug that.

So best is to send in UTC and accept as is.

Though if you insist doing it the wrong way, you can add an additional parameter to the REST request described in KB0789000, but in that case you must make sure both the sending party and the receiving party agree on the time zone and they only change it if it happens at the same time on both sides.