fix: require Z suffix on all timestamps (RFC 3339 UTC indicator)

[mwiesen]

Summary

This PR addresses issue #13 by strictly defining the SPXP timestamp format to always use Z as UTC indicator — no other timezone representation is permitted.

Problem

The SPXP specification stated that timestamps are in UTC, but neither the type definition nor the examples included the Z suffix. This causes ambiguity: many parsers (including JavaScript's new Date()) interpret naive datetime strings as local time rather than UTC.

Additionally, RFC 3339 technically allows +00:00 as an equivalent to Z — but +00:00 could also be misread as a fixed offset rather than true UTC, and some standard serialization libraries may produce it instead of Z.

Changes

• Type definition (SPXP-Spec.md §3): Format is now exactly YYYY-MM-DDThh:mm:ss.sssZ
  • Z MUST be used — no other timezone representation permitted
  • +00:00 and other UTC offset notations MUST NOT be used
  • Implementations SHOULD avoid standard serialization libraries that may produce timezone offsets instead of Z
• All timestamp examples in SPXP-Spec.md, SPXP-PME-Spec.md, and SPXP-SPE-Spec.md updated to include Z

Rationale

SPXP has deliberately chosen to always store and transmit timestamps in UTC to avoid the well-known complexity of timezone handling. Requiring the literal Z (rather than allowing +00:00) enforces this intent unambiguously and keeps the format simple for implementors. Clients are responsible for converting UTC to local time for display purposes.

Closes #13

[mwiesen]

Backwards compatibility addendum

The original v0.3 spec deliberately omitted the Z suffix to discourage developers from blindly using standard date serialization libraries and instead force explicit awareness that SPXP timestamps are always UTC. This was a conscious design decision, not an oversight.

As a result, all existing v0.3 implementations in the wild (including deployed servers and clients) produce timestamps without the Z suffix. Requiring Z strictly on read in v0.4 would therefore break interop with all existing v0.3 data — every timestamp from a v0.3 server would be rejected by a v0.4 client.

To address this, I've pushed an additional change to this branch that introduces a lenient read / strict write rule:

• Writing: Z is mandatory (as this PR already specified)
• Reading: both formats MUST be accepted and treated as UTC — the missing Z is implicitly appended

This follows Postel's law and is the standard approach to backwards-compatible format evolution. It means v0.4 clients interoperate seamlessly with v0.3 data without any version-gating logic, while the ecosystem gradually converges on the unambiguous Z format as implementations upgrade.