Fixes #56711

Summary

This PR adds first-class serialization support for DateOnly and TimeOnly across two major .NET XML serialization stacks: DataContractSerializer (DCS/DCJS) and XmlSerializer. The implementation treats these types as primitives (similar to DateTime, TimeSpan, etc.) rather than complex types, ensuring clean schema export/import and efficient round-trip serialization.

Key Changes

Core Implementation

• Extended primitive registration tables in both DCS and XmlSerializer to recognize DateOnly and TimeOnly as first-class primitives
• Added canonical wire formats:
  • DateOnly → yyyy-MM-dd (ISO 8601 date format)
  • TimeOnly → HH:mm:ss[.FFFFFFF] (ISO-like time format with optional fractional seconds)
• Consistent behavior across all three serializers with the same textual representations

Schema Export/Import

• Custom XSD simple types in each serializer's extension namespace:
  • XmlSerializer: http://microsoft.com/wsdl/types/ (URT namespace)
  • DataContractSerializer: http://schemas.microsoft.com/2003/10/Serialization/
• Pattern facets restrict lexical forms to prevent offset-bearing inputs that would cause data loss (they function as an executable spec: invalid forms fail at schema validation, not late in parsing)
• Full round-trip support through XSD export/import tooling (XsdDataContractExporter, XmlSchemaExporter, etc.)

Interoperability Features

• Attribute override for TimeOnly: [XmlElement(DataType="time")] forces export as standard xs:time for legacy schema compatibility
• Preserved existing mappings: xs:time → DateTime behavior unchanged for backward compatibility
• Cross-version safety: Older clients gracefully ignore unknown primitive types

Design Decisions & Rationale

1. Primitive vs Adapter Pattern

Decision: Implement as first-class primitives rather than adapter wrappers (like DateTimeOffsetAdapter).

Why: DateTimeOffset required an adapter historically due to its composite semantics (instant + offset) and late introduction when primitive tables were frozen. DateOnly/TimeOnly are lexically atomic, map cleanly to existing XSD bases, and the primitive infrastructure is now mature and stable.

2. Custom Restricted Types vs Direct XSD Mapping

Decision: Default to custom timeOnly/dateOnly types (restrictions of xs:time/xs:date) rather than direct mapping.

Why: Data preservation is serialization rule #1. Raw xs:time legally permits timezone offsets (13:45:00Z, 09:30:00-05:00) that TimeOnly cannot represent. Using custom restricted types with pattern facets prevents offset-bearing inputs that would force either silent data truncation or late runtime rejection; constraining the lexical space up-front makes the contract explicit and tool-validated.

3. Parsing Strictness

Decision: Enforce canonical forms only—reject offsets, zone indicators, 24:00:00, extra whitespace.

Why: Guarantees deterministic round-trips, prevents implicit data loss, enables simpler/faster parsing, and leaves room for future opt-in relaxed modes without breaking existing contracts.

4. Fractional Seconds Handling

Decision: Emit minimal form (trim trailing zeros, no forced width).

Why: Aligns with existing DateTime serialization behavior across XmlSerializer, DCS, and System.Text.Json (all omit unnecessary trailing fractional zeros). Shows only meaningful precision, produces stable canonical representations, and avoids implying precision that was never present.

5. No Binary Protocol Tokens

Decision: Use textual serialization only, no new binary XML tokens.

Why: Payloads are already minimal (10-15 characters), benefits would be negligible, and adding binary forms would require expanding public writer/reader APIs with significant maintenance overhead for little gain.

Testing Strategy

• Comprehensive round-trip tests for all three serializers (XML and JSON)
• Structured schema validation using XSD object model inspection rather than string matching
• Export/import verification through schema tooling
• Attribute override testing for TimeOnly → xs:time mapping
• Backward compatibility validation ensuring existing DateTime behaviors unchanged

Wire Format Examples

XML (DCS & XmlSerializer)

<!-- DateOnly -->
<dateOnly>2024-01-15</dateOnly>

<!-- TimeOnly (default) -->
<timeOnly>14:30:25.123</timeOnly>

<!-- TimeOnly with attribute override -->
<time xsi:type="time">14:30:25.123</time>

JSON (DCJS)

{
  "dateOnlyField": "2024-01-15",
  "timeOnlyField": "14:30:25.123"
}

Schema Export

<!-- Custom restricted types, defined in both the XML serializer and DCS custom namespaces (along with guid, timespan, etc) -->
<xs:simpleType name="dateOnly">
  <xs:restriction base="xs:date">
    <xs:pattern value="([0-9]{4})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])" />
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="timeOnly">
  <xs:restriction base="xs:time">
    <xs:pattern value="([01][0-9]|2[0-3]):([0-5][0-9])(:([0-5][0-9])(\.[0-9]{1,7})?)?" />
  </xs:restriction>
</xs:simpleType>

Backward Compatibility

• Zero breaking changes: All existing DateTime/DateTimeOffset serialization behaviors preserved
• Additive only: New primitive support is opt-in by using the new types
• Cross-version tolerant: Older runtimes that encounter these restricted custom types (derived from xs:date / xs:time) can still deserialize their lexical values into DateTime without information loss, effectively falling back on the base XSD types while ignoring the additional restriction pattern.
• Schema stability: Existing WSDL/XSD generation unchanged unless new types are used

Future Extensibility

The implementation leaves room for future enhancements:

• Optional relaxed parsing modes (via AppContext switches)
• Performance optimizations (binary tokens if justified by telemetry)
• Tooling improvements (analyzers for interop guidance)
• Historical JSON context: the legacy /Date(ticks)/ form (still seen with older DateTime serializers) originated before broad ISO 8601 convergence; choosing modern ISO text for these new primitives avoids perpetuating an anachronistic shape.

Files Changed

• Core serialization: Primitive registration tables and writer/reader delegates
• Tests: Comprehensive coverage across System.Private.Xml.Tests and System.Runtime.Serialization.Xml.Tests
• Schema tooling: Export/import logic for XSD generation

This implementation provides a solid foundation for modern date/time serialization while maintaining full backward compatibility and following established .NET serialization patterns.