An offline record can contain several valid times. The worker may start a task at 14:03, finish it at 14:11, reconnect at 15:20 and receive server acceptance at 15:21. If an application stores only one field called “timestamp,” procurement and support teams cannot tell which event it represents or whether the device clock was reliable.
This guide shows how to define time evidence for rugged handheld and tablet workflows. It is an integration method, not a claim that an AIDC GO model synchronizes time, preserves offline events or exposes a particular audit API.
Name the event before choosing the timestamp
List the business events that matter: task opened, identifier captured, form completed, local queue entry created, upload attempted, server received, server accepted, record edited and supervisor approved. Each timestamp needs an event name, a source and an owner. A time without that context cannot establish the sequence by itself.
The offline transaction guide explains how to preserve transaction identity when a receipt is unknown. Timestamp design adds a different question: which clock recorded each stage, and can the backend distinguish work time from communication time?
Separate wall-clock time from elapsed time
Android's SystemClock reference distinguishes the wall clock from monotonic elapsed-time clocks. System.currentTimeMillis() represents date and time but can jump when the user or network changes the clock. elapsedRealtime() measures time since boot, including sleep, and is suitable for intervals rather than a calendar date.
An application may need both. A delivery record may store a real-world capture time, while diagnostics use a monotonic interval to show that an upload attempt lasted 18 seconds. Do not substitute one for the other, and do not assume the device's displayed local time proves synchronization with an authoritative source.
Use an unambiguous exchange format
RFC 3339 defines an Internet date-time profile with a stated relationship to UTC, using Z or an explicit offset. A stored value such as 2026-09-16T14:03:12+08:00 identifies an instant more clearly than 09/16/26 2:03, whose order and time zone are ambiguous.
Store the original event meaning separately from display formatting. The application can present local time to the worker while exchanging a normalized timestamp and offset. If the project needs the named time zone, device clock source or synchronization status, define those as additional fields rather than trying to infer them later from the formatted string.
Compare the common time fields
| Time field | Useful meaning | Limit that must remain visible |
|---|---|---|
| Device capture time | When the device clock said the worker performed the event | A user, network or configuration change may have shifted the wall clock |
| Monotonic interval | Duration between two events during the same boot session | It is not a calendar timestamp and does not survive every reboot or device transfer |
| Synchronization time | When a queued record or attachment was transmitted | It does not prove when the physical work occurred or when the server accepted it |
| Server receipt or acceptance time | When the authoritative service received or accepted a submission | It may be much later than field capture and does not replace the original event time |
Record the device ID, application build, record ID, clock source if available and any observed time change. The field names should remain stable in exports and audit screens.
Walk one offline inspection through four times
Consider an editorial example. A technician identifies pump A at 14:03 device time, finishes the inspection at 14:11 and submits while offline. The record enters a local outbox. Connectivity returns at 15:20, the application transmits the record, and the server accepts it at 15:21. A supervisor reviews it the next morning.
The record should not overwrite 14:11 with 15:21 merely because the server became authoritative later. It should retain the field completion event, queue identity, transmission attempt and server result as separate facts. If the device clock was ten minutes slow, the audit should preserve that observation and the server times instead of silently rewriting the field sequence.
Microsoft's Field Service timestamp troubleshooting note describes a named offline timestamp used when an offline booking status later synchronizes. It is a software-specific example, not a universal Android behavior or an AIDC GO capability.
Test clock changes and delayed synchronization explicitly
Use a controlled record with visible identifiers. Capture one event online, one offline and one after a documented clock or time-zone change in a test environment. Confirm what the worker sees, what the local record stores, what the server receives and what an export reports. Do not change time on an uncontrolled production device simply to create evidence.
Survey123's tracking guidance shows that a form can preserve start and end metadata while editor tracking records who submitted or later edited data. Its mobile quick reference also distinguishes an Outbox from submitted records. These named examples illustrate separate events; another application must be tested on its own version and configuration.
Send the time model with the application brief
Provide the application and version, device OS/build, time-setting policy, network time source if managed, required event names, UTC/offset format, offline queue behavior, server receipt and acceptance fields, edit/approval history, export requirements and any maximum tolerated clock error. Include an example record that crosses an outage or shift boundary.
Use the deployment readiness checklist to retain the build and test evidence. Compare the current handheld-terminal category and rugged-tablet category only after the application time model is defined. Send the application flow and model shortlist to Integration Support or Contact. For field forms and attachments, the field-inspection article covers record association; this article focuses on time meaning and ordering.