GitLab Backend API vs Client Applications: Who Should Convert Timestamps to Local Time?

Integration Boundary Question

The GitLab backend API stores and returns all timestamps in UTC (ISO‑8601 with a ‘Z’ suffix), while the web UI converts these values to the authenticated user’s preferred time zone using client‑side JavaScript. Consumers of the API—such as CI/CD scripts, external dashboards, or custom integrations—must perform their own conversion if they need localized times.

The goal is to clarify where the conversion responsibility should lie: should the API optionally return timestamps already adjusted to a requested time zone, or should clients continue to handle the conversion independently?

Considerations include maintaining backward compatibility for existing parsers that expect the ‘Z’ suffix, avoiding unexpected changes to response format, and ensuring consistent behavior across all endpoints that return timestamps.

Questions
- Should GitLab introduce an optional query parameter (e.g., ?time_zone=America/New_York) that returns timestamps in the supplied zone?
- How would such a parameter affect existing clients that rely on the current UTC‑only format, and what versioning or deprecation strategy would mitigate breaking changes?
- Which endpoints should support the parameter first, and how should the API document the expected output format when the parameter is present?