A readable timestamp does not prove that two devices agree about time. For a proposed UG35 payload workflow, specify the event being recorded, the time representation, and the evidence connecting each clock to that event. Treat these as separate requirements before using timestamps to associate observations or explain the order of a delivery.

Imagine receiving a payload record and an aircraft record that both contain a date, a time, and a UTC offset. They look comparable. Yet one describes when an observation began while the other describes when a file arrived. Sorting those strings cannot resolve the difference. The purchasing question is not simply whether the system exports timestamps; it is what those timestamps mean and what can be demonstrated about them.

Start with the event, not the number of decimal places

Write a sentence for every time field that matters to the buyer. A useful definition identifies the event, the component assigning the value, and where the value is retained. An observation start, an observation end, a trigger request, a completed transfer, and a database import are different events. Ask the integrator which one a field represents instead of interpreting a short column heading after delivery.

This is an interface-scoping exercise, not an instruction to alter aircraft timing settings. The responsible supplier must determine which signals and records are actually available in the proposed configuration. A buyer can nevertheless insist on a shared vocabulary. Without it, a precise-looking export can support several incompatible explanations, and each team may believe that another team owns the missing definition.

For example, a project might need to associate a payload observation with a position record. Before discussing a tolerance, ask whether the requirement concerns the beginning, middle, or completion of that observation. If the task only needs a daily delivery sequence, a different level of evidence may be appropriate. Let the intended decision determine the requirement; do not buy apparent precision without a use for it.

What a timestamp standard can establish

RFC 3339, published in July 2002, describes Internet timestamp notation, including numeric offsets relating local time to UTC, and discusses interoperability problems with unqualified local times. That is useful background for exchanging records. It does not establish a UG35 interface, a synchronization tolerance, or evidence that a particular payload clock agrees with another clock. Those remain configuration-specific questions.

A procurement brief should therefore distinguish a representation check from a timing-evidence check. The first asks whether another system can interpret the field consistently. The second asks what evidence supports the claimed relationship between clocks and recorded events. Passing one should not silently mark the other complete. Keep separate review owners where the data team and integration team have different responsibilities.

Build a small timing evidence table

Use one row for each required record stream. Include the event definition, clock owner, stated time basis, output location, and the evidence the supplier proposes to provide. Add a final column for unresolved questions. This is more useful than a single line reading time synchronized, because it exposes which stream has been explained and which one is still being assumed to behave similarly.

• Event: What physical or software event does the value describe?
• Assignment: Which component creates the value, and does another component later replace it?
• Representation: How are time basis, offset, and fractional values documented?
• Evidence: What representative records and demonstration support the required relationship?
• Exception: How will missing, uncertain, or reset timing information be identified?

The table should describe the proposed delivered system, not a generic architecture diagram. If an example comes from a different payload or software release, label it accordingly. It can help explain a method, but it cannot close the acceptance question for an untested combination. A clear distinction between illustrative evidence and configuration evidence prevents a useful demonstration from becoming an unsupported product promise.

For teams working between the United States and Ireland, explicitly document the time basis expected at the handover boundary. Do not infer it from the office location or from how a spreadsheet happens to display a value. This is a cross-team communication recommendation, not a claim about local market demand or a country-specific operating requirement.

Ask for a trace through the delivered workflow

A useful demonstration follows one agreed event from its originating record into the file or application the buyer will actually receive. Ask the supplier to show the relevant original fields, any transformation, and the final field name. Preserve enough context to identify the configuration and software release used. The goal is an explainable chain, not a screenshot containing an attractive timestamp.

Choose a representative handover route. If the intended process includes an export tool and a later import into a customer's application, reviewing only an intermediate console leaves a gap. Conversely, do not impose an elaborate chain on a simple archival requirement without explaining the business need. The appropriate test is the smallest one that can answer the agreed question with traceable evidence.

Ask who will interpret an apparent disagreement. The payload supplier may own the original event record, the integrator may own transformation logic, and the customer may own the final import. These are proposed responsibility categories, not assertions about what any UG35 purchase includes. Put names or roles against the real project boundaries once the commercial scope is known.

A field-oriented review lesson is to ask what happened at the recorded instant before asking someone to sort the records. This is editorial guidance, not a reported customer incident. It helps separate a meaning problem from a clock problem. A team that first agrees on the event can then investigate the evidence without arguing over records that were never intended to describe the same thing.

Specify what happens when the evidence is incomplete

Successful examples are only part of the requirement. Ask how the delivered records identify missing values, unconfirmed time basis, or information unavailable for a particular observation. Do not prescribe a device recovery procedure from a blog article. Instead, request the supplier's documented behavior and agree how downstream reviewers will recognize records that should not be treated as fully comparable.

Also ask whether a corrected export preserves the original record and an explanation of the change. A buyer may need to distinguish a new interpretation from newly collected evidence. Decide which version is authoritative for the project and who can approve replacement. That decision belongs in the handover process rather than in an informal message accompanying a renamed file.

Separate a delivery deadline from the quality decision. Receiving a file on time does not establish that its timing evidence is adequate. A practical review outcome can be accepted for archival sequence but not accepted for observation association, provided that this narrower use is genuinely appropriate and documented. Avoid an all-purpose accepted label that later readers could apply beyond the demonstrated scope.

Keep adjacent data questions distinct

Before closing the timing review, ask a colleague who did not attend the demonstration to read the evidence table. Can that person identify the event, the record stream, and the unresolved limitation without an oral explanation? If not, improve the handover description. This is a documentation check, not a substitute for the supplier's technical evidence, but it can expose ambiguity while the people responsible are still available.

Timing evidence does not establish what measurement information a file contains. A perfectly documented time field can accompany an output that is unsuitable for the intended analysis. For that separate question, see the discussion of thermal pictures and radiometric file requirements. Define each dependency explicitly rather than allowing one strong-looking metadata field to stand in for the whole deliverable.

Likewise, a software version label is useful context but does not explain every component involved in creating the record. The software component and release handover guide addresses that documentation boundary. Keep the timing trace connected to the actual delivered release, while avoiding the assumption that a component inventory proves timing behavior.

Where UG35 belongs in the inquiry

The UG35 product listing is the starting point for identifying the platform under discussion. It is not evidence that a proposed payload supports a particular clock source, timestamp format, event signal, or timing tolerance. This article makes no such compatibility claim. For payload interfaces and a supported timing demonstration, contact us for configuration details.

Buyers comparing the broader VTOL and fixed-wing drone collection should carry the same event definitions between inquiries. Otherwise, apparently similar quotations may be answering different questions. Ask each proposed supplier which evidence is included, which work requires a separate integration scope, and which requirement remains unconfirmed. Compare those answers before comparing a bare statement of synchronization.

Send a timing brief that can receive a specific answer

Prepare a short brief naming the observation event, required record streams, intended downstream decision, and the application that will consume the files. Include a redacted example of the expected output structure where appropriate. Mark unknown timing requirements as questions for the responsible specialist, rather than inventing a tolerance merely to complete the form.

Then ask UNITED UAV about the proposed UG35 configuration with three concrete requests: confirm the event definitions that can be documented, identify the available clock-provenance evidence, and describe one end-to-end timing trace that could be supplied. A specific answer to those requests is more valuable than extra decimal places in an unexplained timestamp.