Commit Timestamp Display in Codecov UI Appears Off by Browser Time Zone

Answer to the core questions

1. Yes – the Codecov web UI treats the API‑returned UTC timestamps (ending in ‘Z’) as instants and converts them to the browser’s local time zone before displaying relative times such as “2 days ago”.

2. The date‑range filter on the coverage‑history chart accepts the dates you pick as local calendar dates; the frontend usually converts those local‑midnight values to UTC timestamps (ending in ‘Z’) before sending them to the API, so the plotted data reflects the range you selected in your own zone unless the backend re‑interprets them as UTC.

3. There is no documented UI setting or API flag to override this automatic local‑zone conversion; a timezone‑control feature would require a new feature request or custom plugin.

Confirmed facts

• Codecov’s API returns commit timestamps in ISO 8601 format with a ‘Z’ suffix, indicating UTC (e.g., "committed_at":"2026-09-14T12:34:56Z").
• JavaScript’s Date constructor (or a moment‑like library) parses the ‘Z’ suffix as UTC and then converts the instant to the local time zone for display.

Likely explanation (based on typical web‑app behavior)

• The UI renders relative times by calling new Date(utcString) and then formatting the result with toLocaleString or a library that defaults to the browser’s zone.
• For the coverage‑history filter, the frontend takes the selected start/end dates, builds timestamps at 00:00:00 in the local zone, converts those to UTC (adding the zone offset), and sends them as start_date and end_date parameters.

Verification steps for this case

1. Open any Codecov commit page, open DevTools → Network, find the request that returns commit data (often /api/v2/github/<user>/<repo>/commits). Note a timestamp field, e.g., "committed_at":"2026-09-14T12:34:56Z".
2. In the Console, run new Date('2026-09-14T12:34:56Z').toLocaleString() and compare the output to the relative time shown in the UI (you may need to convert the relative label to an absolute time for comparison).
3. Temporarily override your browser’s timezone (DevTools → Settings → Override timezone, e.g., set to UTC+5) and reload the page. Observe whether the displayed relative time shifts by the offset amount.
4. For the date‑range filter, pick a start date (e.g., Sep 10 2026), then inspect the request sent to the coverage‑history endpoint (/api/v2/github/<user>/<repo>/coverage). Verify that the start_date parameter is a UTC timestamp like 2026-09-10T00:00:00Z (local midnight converted to UTC).

Missing diagnostic detail that could change the recommendation

Does the observed offset remain constant for all commits, or does it vary with the date of the commit (e.g., due to daylight‑saving transitions)? If the offset varies, the issue is likely a DST‑handling bug in the UI’s date library; if it is constant, the behavior is simply the expected local‑zone conversion.