Documentation

Cedar.Thm.Ext.Datetime

Datetime parser correctness #

Soundness, completeness, and failure characterization #

Well-formed datetime syntax is exactly syntax to which the grammar assigns some value.

Soundness of Datetime.parse: if parsing succeeds, the grammar assigns the input the returned datetime's value.

Completeness of Datetime.parse: if the grammar assigns a string the value d.val.toInt, then parsing accepts the string as d.

Failure characterization #

Because the grammar bounds years to four digits and zone offsets to ±23:59, every well-formed datetime value fits in Int64. Parsing therefore rejects exactly malformed strings.

Canonical serialization #

parse ∘ toString? roundtrip: every successfully serialized datetime parses back to the original value.

theorem Cedar.Thm.Datetime.toString?_injective {d d' : Spec.Ext.Datetime} {str : String} (h : toString? d = some str) (h' : toString? d' = some str) :
d = d'

toString? is injective on the values it serializes: datetimes with the same (defined) canonical string are equal. (Partial-serializer analogue of Decimal/Duration's toString_injective.)

Normalization #

Equal normal form iff equal parse — normalization decides datetime equality.

Datetime serialization is partial (toString?), so normalize = (parse ·).bind toString? can collapse two distinct parseable-but-unserializable values to the shared none. The forward direction therefore carries a serializability hypothesis on the parsed values; this is exactly what a full serialization-completeness result (parse s = some d → (toString? d).isSome, which needs the Std.Time civil-calendar round-trip) would discharge unconditionally, closing the gap with Decimal/Duration's total-toString versions. The backward direction is unconditional.