Business trigger time
The moment a user action or system event occurs. Use it to determine whether the product created the send job promptly.
The meaning of email times
One email can have four timestamps
Trigger, queue, receipt, and display times are different. Align the time zone and event definition first, then decide whether a verification code arrived late or has already expired.
10:00:00 TriggeredThe user submits the login form and the app creates a send job. This is the time of the business action.
10:00:02 QueuedThe email job enters the sending queue. The difference between these times reflects the handoff between the app and the queue.
10:00:08 ReceivedThe destination server accepts the email. The gap from queueing is a closer measure of delivery latency.
18:00:08 DisplayedThe browser shows local time in UTC+8; this may be the same instant as 10:00:08 UTC.
Define the terms first
Don’t subtract the display clocks directly
Two devices showing different hours does not necessarily mean delivery was delayed. Convert every time to the same time zone or timestamp first.
Email header date
Usually written by the sending system, it may be affected by server clocks, queues, and configuration. It should not be treated as proof of receipt on its own.
Receipt time
The time recorded by the receiving system when it accepts the message. It is better for measuring actual arrival, but you still need to identify the time zone used.
Displayed time
Converted to the device’s local format for easier reading. When taking screenshots, record the device time zone too to avoid confusion across teams.
Validity start time
A verification code may start counting from generation, sending, or server-side issuance. Follow the product’s contract.
Countdown remaining
A countdown is a derived value. After backgrounding, sleep, or a device-clock change, recalculate it from the absolute expiry time.
Diagnose delivery delays
Break total latency into three parts
Only by knowing where time was spent can you decide whether to inspect application logs, the sending queue, or receiving policies.
A large trigger-to-queue gap points first to the application request, template rendering, and job service.
For a large queue-to-send gap, check rate limits, concurrency, retries, and provider status.
For a large send-to-receipt gap, check DNS, reputation, temporary rejections, and remote policies.
If the server has received the message but it appears late in the list, check polling frequency, caching, and the client network.
How to test verification-code expiry
First confirm which server-side event starts the validity period, then test within the period, around its boundary, and with repeated use. Do not replace server-side expiry checks by manually changing the device clock.
- Using the code immediately after generation should succeed
- The response near the expiry boundary should be clear
- After a new code is issued, the old code must behave as specified
How to record cross-time-zone collaboration
Keep the original ISO timestamp, time-zone offset, and local readable time in every bug report. If a screenshot says “10 a.m.”, document the device time zone.
- Use the event ID to connect logs across systems
- Use UTC as the team’s comparison baseline
- Use local time to reconstruct the user experience
Quick check
When something is “late,” answer these four questions
These four questions eliminate most time-zone misunderstandings and pinpoint real delays to system components you can investigate.
Where did the time come from?
Is it from an application log, email header, receiving server, or browser list? Different sources represent different events.
Which time zone is it in?
Does it include Z, an explicit offset, or a regional time zone? A timestamp without a time zone is incomplete evidence.
Are you comparing the same message?
The unique ID in the subject, recipient address, and job ID must match. Avoid comparing a resent message with the original.