A2P SMS Event Timing: Reconciling Platform, Provider, and DLR Timestamps
A practical guide to logging, comparing, and auditing SMS event times without confusing DLR receipt with independent confirmation of delivery to a handset.
Why Recorded Times Can Differ
An A2P message can generate records in several systems: the originating application or platform, the provider that receives the message, and systems that issue or deliver a status report. Each record may correspond to a different moment and use a different clock source, time zone, or level of precision.
For that reason, two different timestamps do not, by themselves, prove that there is an error. To interpret them, first determine what event each field is intended to represent and which system generated it. The documentation available for this article does not support attributing universal timestamp or DLR definitions to any particular specification; agree on and document those semantics with each provider.
- Do not compare a creation time with a receipt time as if they described the same event.
- Record the originating system and the stated meaning of each timestamp.
- Treat each field’s precision and semantics as properties to verify, not assume.
Separate Creation, Submission, Acceptance, and Callback Receipt
Use explicit event names. At a minimum, distinguish when the record or request was created, when the platform attempted to submit it, when it received an acceptance response, the event time reported by the provider, and when the callback reached your system. Do not assume that “accepted” means delivered to the handset.
Keep the event time reported by the provider separate from the time your platform received that report. The former is a statement from the system reporting the event; the latter documents local receipt. If the provider does not specify what its timestamp represents, preserve it as source data without reinterpreting it.
- Define an event dictionary with each event’s name, originating system, and meaning.
- Store the timestamp reported by the provider and the local receipt timestamp separately.
- Do not turn acceptance or report receipt into a claim of delivery to the device.
Normalize for Comparison, but Preserve the Original Data
To make searches and comparisons across systems easier, adopt a common time representation, such as UTC, and an unambiguous serialization convention. Before converting a value, identify its time zone or offset. If it is unavailable, record that it is missing: do not assume the time corresponds to the server’s or operator’s time zone.
Normalization should not overwrite the received value. Preserve the original text or value, the stated time zone, the source, and the derived normalized value. This lets you review conversions, resolve discrepancies, and reconstruct what each system reported.
- Store the original value unchanged.
- Record the time zone or offset; explicitly indicate when it is unknown.
- Store the normalized value in a separate field and document the conversion rule.
- Do not invent precision: preserve the available precision and note when it is unknown.
Clock Skew, Uneven Precision, Duplicates, and Out-of-Order Events
A timestamp alone is not enough to diagnose a misaligned clock. Compare fields only when you know their meaning and time zone, and record observed differences as indicators, not automatic proof of their cause. If the system exposes reliable information about clock synchronization or quality, store it separately; do not infer it from an apparently unusual sequence.
Callbacks may arrive after other events or may be repeated. Design ingestion to preserve received events, identify possible duplicates using stable identifiers when available, and maintain a change history. If there is no suitable identifier, do not infer that two reports are the same event merely because they share a status and time.
- Distinguish the reported event time from the local receipt time.
- Record the stated or available precision; do not add fractions of a second that were not present.
- Preserve late and out-of-sequence events rather than discarding them because they arrived later.
- Use message and event identifiers when available, and document their limitations.
- Do not irreversibly remove duplicates: retain evidence of deduplication.
Reconciliation Rules: Precedence Without False Certainty
There is no universal, supported rule here for ordering all A2P SMS events by timestamp precedence. Define internal rules by event type and by each provider’s contract or technical documentation. An acceptance response, a status event reported by the provider, and callback receipt must remain distinct facts.
When two sources disagree, avoid choosing one time as “the true one” without a documented reason. You can establish an operational reference time for reporting, but preserve all observations and label the criterion applied. If a value’s meaning or time zone is unclear, mark the comparison as inconclusive.
- Define precedence according to event semantics, not a generic field name.
- Record the rule applied, its version, and the sources involved.
- Separate the status calculated by your platform from statuses received from third parties.
- Escalate unresolved discrepancies instead of turning them into delivery confirmation.
Minimum Fields for an Auditable Record
A useful record should let you reconstruct what was received, from whom, and how it was interpreted. The exact schema depends on the integration, but it is helpful to separate correlation data, original data, normalized times, and reconciliation decisions.
Limit access to identifying data and follow your organization’s applicable retention and security policies. Auditability does not require processing more personal data than necessary to correlate events and resolve issues.
- Internal message identifier and, if available, provider-assigned identifier.
- Event type and status as received, without losing the original value.
- Originating system or provider and interface version or reference, when available.
- Original timestamp, stated time zone or offset, and available precision.
- Local receipt timestamp and normalized timestamp, stored separately.
- Event or callback identifier, if available, and the result of duplicate detection.
- Reconciliation rule applied, result, reason, and time of decision.
- Uncertainty indicator when the meaning, time zone, or sequence cannot be established.
Example: Delayed DLR and Uncertain Final Status
Suppose a platform records a submission and later receives an acceptance response. It then records another transition and eventually receives a callback whose reported timestamp appears earlier than its local receipt time. The difference could be due to transmission delay, different timestamp criteria, an unknown time zone, or misaligned clocks; without additional data, it is not possible to choose a cause.
The prudent approach is to preserve both times, associate the callback with the message only using suitable correlation keys, and flag the sequence for review if it conflicts with documented rules. The callback establishes that the platform received a report with certain content. Without documentation that defines its semantics and scope, it should not be presented as independent verification that the handset received the SMS.
- Keep the DLR’s reported timestamp and the receipt timestamp in separate fields.
- Do not reorder or delete the history to make it appear chronological.
- Record the reported status and any uncertainty about its meaning.
- Describe the result as a status reported by the provider, not as independent proof of handset receipt.
Periodic Testing and the Limits of a Timestamp
Validate the flow with controlled, legitimate tests in your own integrations. Check that original values are preserved, time-zone conversion is reproducible, late events are not lost, and duplicates are identified without deleting the history. Repeat the review whenever the interface, configuration, or provider rules change.
A timestamp alone does not prove who received the message, that the clock was synchronized, that the event occurred at exactly that time, or that the content appeared on the handset. Conclusions depend on the event definition, the source, and the available technical evidence. Document these limits in operational and reconciliation reports.
- Test timestamps with and without time zones and verify that originals remain unchanged.
- Include cases involving late, repeated, and out-of-sequence callbacks.
- Compare local interpretation with the current documentation for each integration.
- Regularly audit time differences and reconciliation results without turning them into delivery guarantees.
Frequently asked questions
Does receiving a DLR confirm that the SMS reached the handset?
Receiving the callback confirms that your system received a report. Its meaning depends on the source’s documented semantics and, by itself, is not independent verification of receipt by the handset.
Should I store all timestamps in UTC?
You can maintain a normalized UTC field to compare systems, but also preserve the original value and the stated time zone or offset. If the time zone is unknown, record that rather than assuming one.
Which time should take precedence when the platform and provider disagree?
There is no universal precedence that applies to every field. Define rules by event type and the integration’s documentation, preserve both observations, and label unresolved discrepancies.
How should I handle a callback that arrives out of order or is duplicated?
Preserve it with its receipt time and reported timestamp. Use stable identifiers to detect duplicates when available, maintain the history, and do not discard events just because they arrived late.
What does a difference between two timestamps prove?
It shows that the records contain different values; it does not, by itself, identify the cause. Differences in semantics, time zone, precision, delay, or clocks may be involved. Additional data is needed to establish a cause.
Sources consulted
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA