reject string-form datetime (tag 0) without a UTC offset

[sahvx655-wq]

Changes

decode_datetime_string (tag 0) hands the payload straight to datetime.fromisoformat and returns whatever comes back. That call is a lenient ISO 8601 parser, not an RFC 3339 validator: it happily accepts offset-less strings like 2020-01-01T00:00:00 and even date-only ones like 2020-01-01, decoding them to a naive datetime. RFC 8949 §3.4.1 ties tag 0 to RFC 3339, which makes the UTC offset mandatory, so a conformant value should always come back timezone-aware. I noticed this while diffing the Rust decoder against the 5.x pure-Python reference, whose timestamp_re requires the offset and rejects these strings; the rewrite lost that guard. The practical risk is that an untrusted sender can hand the application a naive datetime where an aware one is guaranteed, which then throws TypeError: can't compare offset-naive and offset-aware datetimes downstream or is silently misread as local time.

The fix rejects a parsed value whose tzinfo is None with a CBORDecodeError. A well-formed RFC 3339 string always carries Z or a ±HH:MM offset and therefore always parses to an aware datetime, so no valid input is affected; the existing datetime tests (offsets, fractional seconds, the >6-digit truncation cases) all still pass. Keeping the check inside the decoder means callers get the tag 0 aware-instant guarantee without each having to re-validate.

Checklist

• You've added tests (in tests/) which would fail without your patch
• You've updated the documentation (in docs/), in case of behavior changes or new features
• You've added a new changelog entry (in docs/versionhistory.rst).

[coveralls]

coverage: 95.027% (+0.006%) from 95.021% — sahvx655-wq:datetime-tag0-utc-offset into agronholm:master

[agronholm]

Thanks!