A timestamp originating from a GPS receiver is not necessarily still expressed in GPS time when it reaches an exported file. The receiver or later software may already have converted it to UTC. Before combining records in a proposed UIV2200 workflow, identify the time scale of each exported field and its conversion history. Applying a correction twice can create a mismatch rather than remove one.

The word GPS does not define the export

Picture a hypothetical handover containing positioning records and sensor records. A reviewer sees GPS in the equipment description and decides to apply a GPS-to-UTC conversion to the positioning timestamps. The files then appear farther apart in time. The missing question was whether that conversion had already happened before export.

This example is not a reported UIV2200 behavior or a customer incident. It illustrates a metadata problem: the origin of the timing information and the scale used to label the exported record are different facts. A buyer should ask for both rather than infer the second from the first.

Use the time-scale distinction carefully

NIST's explanation of time scales states that GPS time does not incorporate leap seconds, whereas UTC does. It also explains that the GPS broadcast message includes the UTC offset and that receivers usually apply it automatically. This supports the need to identify what an output contains; it does not establish the behavior of every receiver, firmware version or export format.

For the rotation-market context, the Measurement Standards Laboratory of New Zealand describes its time standard and NTP servers referenced to UTC(MSL). That is evidence about the national timing reference, not proof that a project computer or aircraft log is synchronized to it. A system's actual configuration still needs verification.

The rest of this article proposes an editorial handover workflow. It deliberately does not provide a universal seconds offset or a current leap-second prediction. Those values and their applicability must be verified for the relevant dates and conversion method rather than copied permanently into a spreadsheet.

Ask for a contract for each time field

A useful timestamp description names more than a column called time. Ask the data owner to specify the scale, representation, units, origin or epoch where relevant, timezone treatment and meaning of the recorded event. The last item matters because a timestamp might refer to an observation, a record being produced or a later export stage. The owner should state what it means for that field.

Keep the description attached to the actual file version. A general receiver manual may explain several supported outputs, only one of which was selected. A software screenshot may show a setting without proving which setting produced the delivered file. The handover should connect the documentation, configuration and sample output sufficiently for the recipient to review the claim.

• Exact field name and a sanitized example value
• Declared time scale and representation
• Units and any relevant origin
• Event represented by the timestamp
• Conversion already applied and the responsible component
• Handling of missing, invalid or uncertain time information
• Software, firmware and export configuration identifiers

These are proposed documentation fields, not a claim that a particular logger exports them automatically. If a detail is unknown, mark it unknown and assign a person to resolve it. A missing field definition should not be replaced by a plausible guess simply because the timestamp has the expected number of digits.

Trace the conversion once, end to end

Make a short processing history for one representative record. Start with the source output, follow any logger or processing software and end with the column used in the analysis. At each step, ask whether the time value, label or interpretation changed. This can be done as a review of documented behavior and retained records; it need not involve changing the source system.

Separate a confirmed conversion from a proposed correction. The first belongs in the provenance of the delivered record. The second is a hypothesis that needs evaluation. Mixing them in one notes field can make it difficult to tell whether an analyst is describing the existing pipeline or recommending a future change.

Our editorial recommendation is to preserve the original value and store any derived value separately during diagnosis. Record the method, applicable date information and justification. That makes a later review possible if the interpretation changes, and avoids losing the evidence needed to understand an unexpected offset.

Use a small sample to challenge the interpretation

Before approving a full data merge, ask the responsible technical team to evaluate a small, representative and permitted sample. The sample should have enough supporting context to distinguish the competing explanations. Its purpose is to test the documented interpretation, not to find a shift that makes an arbitrary pair of curves look similar.

Agree what evidence would support the conclusion and what would leave it unresolved. A reviewer might require a configuration record, an explanation from the output owner and a reproducible comparison using the preserved sample. The exact method should be appropriate to the equipment and application; this article does not prescribe a flight test or instructions for changing timing hardware.

If the results do not match expectations, preserve the discrepancy. Do not erase it by silently editing the original timestamp column. The issue may require clarification of the output definition, a processing review or a different explanation entirely. An honest unresolved result is more useful than a clean-looking file whose changes cannot be explained.

A double-conversion example without a guessed offset

Suppose an invented export pipeline already produces UTC timestamps. A downstream analyst then applies an additional GPS-to-UTC conversion because the source device used GPS timing. The derived values no longer mean what the analyst intended. The appropriate review is to establish the original scale and remove the unjustified extra transformation from the proposed processing path, not to introduce another unexplained shift.

Notice that this reasoning does not require a fixed numerical offset in the example. The mistake is semantic before it is arithmetic. The conversion was applied to the wrong kind of input. A correct formula used on an already-converted field can still produce the wrong result for the intended task.

A handover note should therefore explain the accepted interpretation in words as well as documenting the calculation. That gives procurement and project managers a way to understand why a change was made without pretending to validate the timing algorithm themselves. Technical review remains with the qualified owner.

Do not collapse other timing questions into this one

Identifying GPS time versus UTC does not settle every possible mismatch between two streams. The related discussion of filter group delay and channel alignment concerns the measurement signal path. It is a different question from the time scale used in the exported field. The team should investigate the relevant evidence instead of assuming that one familiar correction explains every discrepancy.

Data packaging is another separate issue. The GeoPackage extension handover guide explains why recipient operations should be specified rather than inferred from the ability to open a file. A timestamp can survive a file transfer unchanged while its meaning remains undocumented. File compatibility and time semantics deserve distinct acceptance rows.

For collaborations between the United States and New Zealand, write the shared time-field definition before discussing local display preferences. A report's presentation timezone and a stored field's declared scale should not be treated as interchangeable metadata. Ask the implementation owner to describe both, including any conversion used for display.

Connect the schema to the UIV2200 proposal

The UIV2200 product page establishes the product identity for an integration inquiry. It does not confirm a specific receiver, timestamp output, sensor logging format or synchronization interface. Those details must be established for the proposed configuration and the components actually supplied.

When reviewing the VTOL and fixed-wing drone collection, carry the same data-handover requirements across the options. Otherwise, an aircraft comparison can be distorted by different assumptions about included logging, processing or integration work. Ask each provider to identify its responsibilities and the dependencies that remain with the buyer or another contractor.

A useful brief includes the intended sensors, the systems that will receive the records and the decision supported by combining them. Where those components are not yet selected, say so. A configuration discussion can identify the evidence still needed without inventing a complete timing architecture on behalf of the product.

Keep future changes visible

After acceptance, keep the timestamp schema with the export recipe and configuration record. If a software update changes an output option, the owner should review whether the accepted interpretation still applies. The same filename or column heading should not be treated as proof that all underlying semantics remained unchanged.

Maintain a clear distinction between raw records, accepted derived records and exploratory analysis. The distinction helps a later reviewer find the evidence behind a result and prevents a diagnostic conversion from quietly becoming part of the production workflow without review. It also gives the team a defined place to record unresolved assumptions.

Ask what the field means before fixing it

Our editorial buyer lesson is to preserve the original timestamp and account for every conversion. A good handover explains the exported scale, the event represented and the transformations already applied. That is a stronger basis for integration than a generic statement that all equipment uses GPS.

Send a sanitized timestamp schema and conversion history through the UNITED UAV contact page when discussing a UIV2200 configuration. Request confirmation of the proposed components, output definitions and integration responsibilities. Keep operationally sensitive records private until an appropriate exchange arrangement is in place, and leave unknown fields explicitly open until current evidence resolves them.