Store evidence in UTC and label it. Tools disagree about display zones, and a record that shows a late night merge in one view and the next morning in another invites questions. Pick UTC as the rule, say so in your evidence log, and convert only for display.
Where the mismatch comes from
GitLab's documentation shows the issue clearly. In the GitLab interface, your local time zone is used for audit events. The audit events API returns dates and times in UTC by default, or the configured zone on self-managed installs. CSV exports use UTC. Three views of one event, potentially three different clock readings.
GitHub's REST examples show timestamps in the ISO 8601 form ending with a Z, for example created_at and expires_at values on artifacts, which denotes UTC.
When it bites
- Deadlines. A policy says access is removed within one business day. A termination at 23:30 local and a removal at 00:10 UTC may look like a miss or a hit depending on the zone.
- Sampling. An auditor samples by date range. A change at the edge of a month can appear in the wrong month in a local view.
- Retention. Expiry dates such as an artifact's
expires_atare computed by the platform. Compare them using the same zone.
A simple rule set
- Store raw exports exactly as the tool provides them. Do not edit timestamps.
- Add a line to your evidence log: tool, time zone of the file, who exported.
- For summary spreadsheets, use a UTC column and a local column, labeled.
- For service level checks, define the clock in the policy: "business hours, in the zone of the staff member's primary office" or "UTC". Choose one.
- When you screenshot a UI, include the visible zone label if the tool shows one, or avoid screenshots in favor of API output.
A worked example
Suppose your policy says leaver access is removed within one business day. A contractor finishes at 22:00 in a time zone five hours behind UTC, which is 03:00 UTC the next day. The removal is logged at 08:00 UTC that morning. In UTC the gap is five hours. In a local view the termination and removal might appear on different calendar days and seem to take longer or shorter than they did. Writing the zone beside both timestamps removes the argument before it starts.
What to say to an auditor
Short and factual: "Raw exports are stored as provided. Where a tool displays local time we use API or CSV output, which is UTC." That sentence answers the question before it is asked.
Edge cases
Daylight saving changes can make a local day 23 or 25 hours long. UTC has no such change. If your policy measures hours, UTC removes ambiguity. If your policy measures business days, define whose business day it is.
See also how fresh evidence must be.
Where Safeguard fits
Safeguard offers compliance and evidence automation, so collected records carry consistent timestamps. A free scan shows how findings are dated.
Quick check
Should I convert timestamps in raw exports?
No. Keep raw files unchanged and add a labeled conversion in a summary.
Does GitLab show UTC in its interface?
The documentation says the interface uses your local time zone, while the API defaults to UTC and CSV exports use UTC.
Sources
Last reviewed: 19 October 2026.
