Parse before comparing
Check whether the response contains an offset, a named time zone, or no zone information at all. A date-time without a zone can be ambiguous; do not silently assume that it means the agent's local time or UTC.
Normalize instants to a consistent representation for ordering and duration calculations, while retaining the source zone when it carries business meaning such as a local appointment or billing day. Treat date-only values separately from instants.
Display with context
When presenting a time, identify the zone or make the user's locale choice explicit. Daylight-saving transitions can create missing or repeated local times, so validate inputs such as scheduled appointments around those transitions.
If the tool's format is unclear, inspect its documentation or sample payload before transforming values. Test boundary cases—midnight, offset changes, and date-only fields—so a conversion does not move an event to the wrong day.