SonarQube server-side UTC scheduling versus client-side browser time zone display consistency

Short answer

For current SonarQube releases the JVM default time zone is a stable contract for scheduled‑task execution and server‑side report generation. The UI, REST API and database all store and return UTC, but the UI converts to the browser’s zone on the client. No instance‑level setting or roadmap item currently aligns the server zone with the display zone. API consumers must therefore apply their own offset logic when correlating timestamps with UI‑displayed dates.

Explanation

• Storage and API: All timestamps in the database and REST responses are ISO‑8601 UTC strings. This is a hard requirement in the current architecture.
• Server‑side scheduling & reports: The scheduler and report exporters use the JVM default time zone, which is set when the JVM starts (typically the host’s TZ or the value of -Duser.timezone). This zone cannot be overridden per‑instance through SonarQube configuration.
• UI conversion: The web UI parses the ISO strings and renders them in the browser’s local time zone. This conversion happens client‑side and is independent of the server zone.
• No future convergence announced: The SonarQube roadmap contains no public entry to unify the server and client time‑zone handling. Existing workarounds (e.g., custom JVM flags) remain the only way to change the server zone.

Practical verification steps

1. Run java -XshowSettings:properties -version on the SonarQube host and note the user.timezone property. That is the zone used for scheduling and reports.
2. Export a PDF/CSV report and compare its date fields with the same period shown in the UI. A one‑day difference indicates the zone mismatch.
3. Call the REST API for a scheduled job event (e.g., /api/ce/task) and compare the submittedAt timestamp with the UI. Apply a manual OffsetDateTime conversion to see the alignment.

What API consumers should do

When correlating scheduled‑task timestamps (from the API) with dates shown in the UI, convert the UTC value to the user’s local zone using the same offset that the UI applies. Example in JavaScript:

const utc = new Date(apiTimestamp); // ISO‑8601 UTC
const local = utc.toLocaleString(); // browser’s zone

In Java or other server‑side consumers, use OffsetDateTime.parse(apiTimestamp).atZoneSameInstant(ZoneId.systemDefault()) to match the UI.

Missing diagnostic detail

Do you run SonarQube with a custom JVM time‑zone flag (e.g., -Duser.timezone=Europe/Paris)? If so, the zone used for scheduling and reports will differ from the host’s default, which may affect the offset you need to apply.