fix: mark capture_time and other timestamps as UTC-aware

[birkholz-cubert]

Summary

Fixes the issue reported in cubert-hyperspectral/cuvis.pyil#29 (the issue was filed against cuvis.pyil, but the cause lives here in cuvis.python).

measurement.capture_time returned a UTC time as a naive datetime (no tzinfo). Consumers could not tell the value was UTC and might interpret it as local time, corrupting timezone-aware processing.

Root cause

base_datetime was a naive datetime.datetime(1970, 1, 1). The SDK derives timestamps by adding a millisecond offset (milliseconds since the Unix epoch, i.e. UTC) to it, and adding a timedelta to a naive datetime stays naive.

Fix

Make the epoch base explicitly UTC-aware in both definitions:

base_datetime = datetime.datetime(1970, 1, 1, tzinfo=datetime.timezone.utc)

Fixing at the source corrects all four derived fields consistently with one change each: capture_time, factory_calibration (Measurement.py), GPSData.time and SensorInfo.readout_time (cuvis_aux.py). The UTC instant is unchanged - only the +00:00 label is added.

Tests

• test_measurement_capture_time now also asserts tzinfo is not None and a zero UTC offset.
• New test_measurement_capture_time_value asserts the exact expected value of the bundled test_mesu.cu3s fixture (2023-11-24 11:13:05.356000+00:00).

All 11 tests in tests/test_measurement.py pass.

Compatibility note

This is a behavioral change: comparing capture_time against a naive datetime (e.g. datetime.datetime.now()) now raises TypeError: can't compare offset-naive and offset-aware datetimes. This is the correct behavior, but downstream code relying on naive comparisons will need to attach a tzinfo.