GPS week seconds need the relevant week context before they can identify an acquisition time unambiguously. For a UG39-related lidar handover, request the declared time encoding, collection-date context and treatment of week boundaries. Preserve the original records and ask the processing owner to demonstrate the receiving interpretation. Do not guess the week from a file's modification date or treat a plausible time value as proof of correct conversion.

A time field can be incomplete without looking broken

A point-cloud file may open successfully while a recipient still lacks the information needed to interpret its time values. A project manager sees a field called GPS time and assumes it is already a complete calendar timestamp. The processing specialist may know that the values need additional context. Unless that context travels with the delivery, both people can believe they have agreed on the same requirement when they have not.

This article concerns the meaning of stored time values, not the accuracy of a sensor clock or synchronization between devices. Those are separate technical questions. It also does not assert that a UG39 configuration includes lidar equipment, a time-conversion tool or a processing service. The goal is to help a buyer describe the data obligation before asking a supplier to confirm what it can provide.

What the PDAL documentation supports

The official PDAL GPS-time conversion documentation distinguishes several time representations. It explains that conversion from GPS week seconds requires the collection start date in GMT to resolve week context, and that wrapping across a new week must be handled explicitly. The filter also has assumptions about point order; blindly sorting wrapped values across a week boundary is not an adequate remedy. These statements describe the documented tool, not a universal conversion procedure.

For a purchasing team, the implication is an evidence request rather than a command to run. Ask the processing provider which representation enters its workflow, which leaves it and what supporting context it uses. Require the provider to explain any boundary handling relevant to the actual delivery. The buyer should not copy an example pipeline and assume that it applies to an unknown file.

Describe the input and output separately

Start with two clearly labeled fields in the brief: source time representation and required delivered time representation. If either is unknown, mark it as unresolved. This prevents a statement about the desired output from being mistaken for evidence about the source. The processing owner should identify where the source declaration comes from and whether it has been checked against the actual data.

Next, name the intended receiving application and use. A recipient may need to associate points with another reviewed record, organize a processing batch or retain acquisition context for later audit. These uses may require different demonstrations. Explain the decision first, then let the qualified provider propose an appropriate verification method and identify any information it still needs.

Keep file dates in a separate part of the record. A download time, archive date or last-modified timestamp describes a file-management event, not necessarily the acquisition represented inside the file. If the only available clue is a filename, request clarification instead of silently adopting it as the missing date context. A convenient guess can become difficult to detect after it is embedded in a derivative.

Build a compact time-context manifest

The following fields form an editorial proposal for a delivery manifest. The actual requirements should be agreed with the receiving authority and processing specialist. No claim is made that this list satisfies every lidar standard or every public data program.

• Identify the source files and retain their unchanged originals.
• State the declared source time representation and where that declaration was verified.
• Record the collection-date context required by the chosen conversion.
• Describe whether a boundary is crossed and how the provider handles it.
• Name the delivered time representation and receiving software.
• Identify the processing version, responsible reviewer and accepted output files.
• List unresolved assumptions and the evidence required to close them.

The manifest should distinguish confirmed facts from information awaiting confirmation. A blank date field should not become a guessed date because a template requires every cell to be filled. Ask the provider what can be delivered honestly while the context remains unresolved, and whether the intended use must wait. This keeps the commercial schedule from silently deciding a technical interpretation.

Request a boundary-aware demonstration

A demonstration should address the cases that matter to the buyer's delivery. If the data spans a relevant time boundary, ask the specialist to include a suitable non-sensitive sample from that portion and explain the expected interpretation. If it does not, record the scope honestly. Do not create a claim of boundary coverage merely because the software has an option for it.

Ask for a traceable relationship between input and output records in the demonstration. The purpose is to understand what the provider changed, not to prescribe a particular implementation. A reviewer should be able to identify the sample, its source context, the declared processing choice and the resulting interpretation. That explanation is stronger than a screenshot showing only that the output file opened.

Preserve order information until the processing owner has explained its role. A well-intentioned cleanup step can change how a sequence is presented to a tool. This is especially important when values repeat or reset under the declared representation. Any sorting or conversion should be part of the documented workflow, not an invisible spreadsheet edit made to improve the appearance of a sample.

Handle ambiguity as an explicit exception

Suppose a hypothetical delivery arrives with a time field but no reliable collection-date record. The buyer should not ask a junior reviewer to select the most plausible week and continue. Instead, identify the evidence gap, the intended use affected and the party who can recover the missing context. Keep the original file available while the issue is investigated.

If a revised derivative is later supplied, the release note should describe the basis of the correction and identify the superseded artifact. A corrected filename alone is not an explanation. The receiving team needs to know whether the change resolved a representation issue, added missing documentation or altered values. The provider should describe the scope without implying that unrelated quality questions were also settled.

This is an editorial lesson in data custody, not a field case or a claim about a particular supplier. The useful habit is to make assumptions reviewable before they become accepted facts. That can be done with a short exception record and named responsibility; it does not require a large new administrative system.

Keep related quality questions distinct

A correct interpretation of time does not establish point classification quality, geometric accuracy, sensor calibration or completeness. It may be one necessary part of a larger acceptance process, but the other requirements still need their own evidence. Ask the technical lead to identify which conclusions the time review supports and which remain open.

The same separation applies to a contract's scope. Hardware configuration, data processing, conversion review and final acceptance may belong to different organizations. A buyer should avoid a single line saying that time is supported when the parties mean different things by it. Itemize who provides the original context, who performs any conversion and who accepts the result.

For US and Singapore recipients, name the actual project requirements and reviewer rather than infer a common standard from geography. This article does not establish compliance with a national mapping program or aviation rule. If a program specification applies, obtain its current requirements and have the responsible specialist reconcile them with the proposed delivery.

Connect the requirement to UG39 without assuming a system

Use the UG39 product page to identify the aircraft under discussion. Ask for configuration details relevant to the intended project, while keeping any lidar sensor, processing software and specialist service as separate confirmation items. No capability should be inferred from the fact that this buyer guide discusses lidar files.

A clear inquiry can name what the buyer already controls. Perhaps a processing contractor is selected and only the aircraft configuration remains open. Perhaps the buyer is still defining the data handover and wants to know which responsibilities could be quoted. Either way, distinguish existing decisions from requests so the response can address the actual gap.

Questions for the receiving team

Does GPS time always identify a complete date? Do not assume so from the field name. Establish the representation and the context needed to interpret it.

Can a file timestamp supply the missing week? Not without supporting evidence that it represents the required collection context. Treat it as a separate metadata item until the provider explains its relevance.

Should we sort first? Ask the processing specialist to define the workflow. The documented PDAL behavior makes order and wrapping relevant; an undocumented cleanup is not a verification method.

Send the context with the question

Source note: PDAL's stable GPS-time conversion documentation was checked on 15 October 2026; no page publication date was established. Tool documentation is not a certification of LAS conformity or a statement of UG39 compatibility.

Related topics include GeoJSON coordinate-order interpretation and preserving order when reviewing monitoring dependence. They address different meanings that can be lost when values are detached from their context.

Compare aircraft options in the VTOL and fixed-wing collection, then contact UNITED UAV with the proposed time representation, known collection context and receiving application. Ask for confirmed UG39 configuration information and a clear boundary around any separately proposed processing work. The next useful artifact is a time-context responsibility record, not a guessed calendar interpretation.