The ‘updated_at’ field is a system field that is set and updated on the backend once a change has been persisted to the master cloud DB.
That means that if a change is made offline, the updated at field will only change once that offline change has been synced to the backend.
Then, in terms of representation, you are right in that when retrieving that value via the backend API it is presented as a date and time in UTC, more specifically it is being presented using the ISO 8601 format. See the docs for more information.
So, just to be clear. The backend will store the exact time the change persisted (in local server time) , but when retrieving that timestamp via the api it will be represented as the UTC equivalent of the timestamp.
So just to be clear, if I am checking against the api updated_at date and time, I need to have the data and time I am comparing adjusted to UTC +0 for a proper comparison.
That depends on how you are comparing the data. If you are comparing them as strings (ie you want to use the raw data as it comes from the API), then yes you would need to convert your comparison data to the ISO 8601 format which would present it as a date and time string in UTC. If, however, you compare the data as actual time values (ie milliseconds since epoch) then no you wouldn’t need to convert the comparison data to UTC. The actual time value doesn’t change, just the display value.
For example if the change was logged at 8am Central time in the US then it will be presented as having been made at 2pm UTC, as those two values represent the same time instance.
In this latter comparison scenario you would need to first parse the API delivered ISO 8601 datetime string to an actual datetime type, but most languages have built in support for parsing ISO 8601 strings to dates. For example in JS it would literally just look like this.
var dateString = "2016-02-22T14:00:53Z";
var jsDate = new Date(dateString);