LAS timestamps change scale across pipeline - a discussion on desired output format

[bloom256]

Description

LAS specification expects GPS time, but in practice input timestamps may be in
any format (Unix time, vendor-specific scaling, etc.). Since we depend on user
data, we currently have no reliable way to enforce LAS-spec timestamps and
can only work with whatever format the input provides.

Example from one dataset:

• input (e.g. lidar0010.laz):
  1755795461.846266

During processing timestamps change drastically:

• intermediate (e.g. scan_lio_0.laz):
  1755795470578609408.000000
  (intermediate format is less important)

But the final outputs also contain extreme values:

• final (global-pc-step1.laz / global-pc-step2.laz):
  1755795605974932718310391808.000000

These final values look like the input timestamp was rescaled twice and is no longer comparable to the original time.

---

Question for discussion

Given that input timestamps may already violate LAS spec, should final point
clouds simply preserve timestamps in the same form as the input (pass-through),
so time remains comparable across stages?

Concern: changing final output timestamp format may break backward compatibility
for existing consumers.

---

Proposal (for discussion)

• Option A (compatibility): keep current behavior and document it clearly.
• Option B (preferred semantics): add an option/config to preserve input
  timestamp format in final outputs (default off), and potentially switch the
  default later.

[michalpelka]

I would be happy to get all exported files in seconds.
Input data is in seconds - it can be seconds from startup (one lidar) or seconds from epoch (synchronized):
https://github.com/JanuszBedkowski/mandeye_controller/blob/fb0669182f0c22c2a48ff24ebce7bcad9f1efbe0/code/save_laz.cpp#L134C1-L134C40.