Store exception expiry as an exact UTC timestamp, show it in each viewer's local time with the zone named, and define in policy whether "expires 30 November" means the start or the end of that day. Ambiguity here is what makes builds break at odd hours.
The problem in one sentence
A date alone is not a moment. "Expires 30 November" can mean midnight at the start of the day, the end of it, in London, in Auckland or in a build server's default zone. Teams spread across zones will disagree, and a gate evaluating at 23:00 may behave differently from one at 01:00.
Rules that remove the ambiguity
- Store a full timestamp in UTC. ISO 8601 with an explicit offset, such as 2026-11-30T23:59:59Z.
- Choose end of day, and say so. Most teams find "valid through the end of the named day" matches how people think.
- Show local time and zone in the UI and in reminders, next to the UTC value.
- Have the gate read the same clock as the record. Evaluate against server time, not a laptop.
- Log the evaluation time in the build output so a surprise failure can be explained.
Where things go wrong
| Situation | Risk | Fix |
|---|---|---|
| Date only, no time | Two readings of the same exception | Require a timestamp |
| Local time stored without zone | Shifts when someone travels | Store UTC |
| Clock drift on CI runners | Gate disagrees with the record | Use a trusted time source |
| Daylight saving change | Expiry shifts by an hour | Store UTC and avoid local arithmetic |
| Exception expires over a weekend | Block arrives with no approver around | Warn earlier, see below |
Weekends and holidays
If an exception ends on a Saturday, the block arrives when nobody can renew it. Either nudge expiry dates to working days when granting, or send the final reminder earlier. See when to send vulnerability exception expiry reminders.
Grace periods are a policy decision
Some teams give a short grace period after expiry. If you do, write it into the policy, make it explicit in the record, and keep it uniform. A grace period that appears only when a senior person asks is an unrecorded exception to the exception rule.
Testing it
Write a small test for your gate: create an exception that expires in two minutes, run the evaluation before and after, and confirm the verdict changes at the stated time. Repeat with a server in a different zone. Ten minutes of testing beats a Monday morning outage.
How this looks in audit
An auditor comparing the export with build logs wants to see that a build after expiry was blocked or covered by a new approval. Exact timestamps make that comparison trivial. Date-only records make it a debate. The earlier post on what happens when a vulnerability exception expires covers the expected behaviour at that moment.
Safeguard's policies and gates apply a rule at the time a build or merge is evaluated, which makes a clear, timestamped expiry easy to reason about.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch where the gate makes its decision, because that is the moment expiry time matters.
Quick check
Is end of day better than start of day?
Either works if it is written down. End of day usually matches what people expect from "valid until".
Why UTC?
It does not shift with daylight saving or travel, so every system agrees on the moment.
Last reviewed: 19 October 2026.
