pub fn format(st: SystemTime) -> StringExpand description
Render a SystemTime in canonical form.
§The range is 0000-01-01 … 9999-12-31, and it used to be 1970-…
This function’s doc comment used to read “saturates at the epoch for
pre-1970 inputs: the schema has no use for them, and the alternative — a
negative-year string — would not be canonical.” The second clause is right
and the first was wrong about its own schema (D-270, 0.15.27): a
negative year is not canonical, but 0060-06-22 is — four digits,
CANONICAL_TS_GLOB accepts it, it sorts correctly against every later
stamp, and parse has always returned a real pre-epoch SystemTime for
it. So the two halves of this module disagreed about their own range:
parse accepted from year 0 and format answered from 1970, and every
instant in between came back as 1970-01-01T00:00:00.000000Z — the wrong
day, silently, with no error anywhere.
That matters because valid time is the caller’s, not the clock’s. A
bitemporal ledger recording when a fact was true has every reason to
carry a date before 1970, and the storage layer has always stored and
ordered one correctly. Only the SystemTime round trip lost it.
Found by fuzz_targets/timestamp_parse.rs on CI run 34060567071, on the
input "0060-06-22T22:22:24Z" — which is D-266’s point about these four
parsers arriving with a defect nobody had reasoned their way to.
Saturation remains, at the two ends the form imposes rather than at the
epoch: an instant outside the four-digit year clamps to
0000-01-01T00:00:00.000000Z or to OPEN_SENTINEL. parse cannot
produce one — its input is four digits by construction — so the clamp is
reachable only from a SystemTime built elsewhere, where returning
something canonical beats panicking on a display path.