Analysis rejected because its date is older than the last known analysis: which layer controls the timestamp?

Our SonarQube server intermittently refuses to integrate a scanner report with a Compute Engine error indicating the analysis date is older than the date of the last known analysis for the project (exact wording unverified for our version). The scanner succeeds locally; the failure appears in the project's Background Tasks page during report processing.

From what I understand, the analysis timestamp is generated on the scanner machine, while the comparison against the project's latest snapshot happens server-side, dates are stored using the server/JVM time context, and the web UI converts them to each browser's local zone. Our scanner fleet runs on hosts in different regional time zones, and there appears to be no dedicated SonarQube timezone property — only the JVM default (user.timezone) and database server settings.

Target version: a current LTS with an external PostgreSQL database; exact behavior may differ from the embedded evaluation database.

Questions:

1. Which timestamp does the Compute Engine actually compare — scanner-generated analysis date or server receipt time — and can clock skew alone trigger this rejection?
2. Should all scanner and server hosts be standardized on UTC via the JVM default time zone, or is per-host local time safe as long as clocks are synchronized?
3. Does changing the JVM time zone affect only new analyses, leaving previously stored dates interpreted as before?