date-with-timezone datatype does not support negative years for BCE

[aj-stein-gsa]

Describe the bug

As discovered through metaschema-framework/metaschema-java#375, it turns out that fn:year-from-dateTime() per specification on XPath 3.1 Functions (and underlying XML Schema XSD 1.0 and 1.1 data type specification), negative date years are permissible in the format -YYYY for <=-1 for BCE years.

Who is the bug affecting

Anyone developing Metaschema-aware tools and data with negative date and more complex data from historical periods.

How do we replicate this issue

See test failures and code workarounds from porting the official XPath 3.1 functions test suite to the metaschema-java test harness in metaschema-framework/metaschema-java@39fbfe5 (link to CI/CD failure in GitHub Actions).

Expected behavior (i.e. solution)

Negative dates are permitted.

Other comments

No response

[david-waltermire]

Research Findings: Negative Year (BCE) Support

Specification Support Summary

Specification	Negative Years	Year Zero	Notes
XSD 1.0 (xs:date, xs:dateTime)	✅ Supported	❌ Invalid	Year -1 = 1 BCE
XSD 1.1 (xs:date, xs:dateTime)	✅ Supported	✅ Valid (= 1 BCE)	Year -1 = 2 BCE
XPath 3.1	✅ Supported	Depends on XSD version	Implementation can use XSD 1.0 or 1.1
RFC 3339	❌ Not supported	❌ Not supported	Only 4-digit years (0001-9999)
JSON Schema (format: "date")	❌ Not supported	❌ Not supported	Based on RFC 3339

Current Metaschema Implementation

The current date patterns explicitly restrict years to 1900-2999 via the pattern (19|2[0-9]). This was likely added for leap year validation but inadvertently limited the year range.

The Core Problem

RFC 3339, which JSON Schema's date and date-time formats are based on, explicitly does not support negative years or years before 0001. From the RFC 3339 specification:

This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard... It explicitly excludes durations and dates before the common era.

This creates a fundamental incompatibility: XML Schema natively supports BCE dates, but JSON Schema (via RFC 3339) does not.

Options Considered

Option	Description	Viable?
A: Expand XML patterns only	Allow negative years in XML, keep JSON RFC 3339 compliant	❌ Breaks format parity
B: Create extended date types	New types like date-extended using string base with custom patterns supporting negative years in both formats	✅ Maintains format parity
C: Remove year restriction	Let xs:date/xs:dateTime handle validation natively	❌ Breaks format parity

Recommendation

Option B is the only viable approach that maintains parity between XML, JSON, and YAML datatype implementations.

Implementation would involve:

1. Create new types: date-extended and date-time-extended
2. Use xs:string as base type (not xs:date) in XML Schema
3. Use custom regex patterns that support negative years in both XML and JSON
4. Require timezone - eliminating the need for optional timezone variants (no -with-timezone variants needed)
5. Document the XSD 1.0 vs 1.1 year zero semantics (year 0 valid in XSD 1.1, invalid in XSD 1.0)

Example Pattern for Extended Date

-?[0-9]{4,}-[0-9]{2}-[0-9]{2}(Z|[+-][0-9]{2}:[0-9]{2})

This would allow:

• 2024-01-15Z (CE date with timezone)
• -0044-03-15Z (44 BCE - Ides of March)
• -2000-01-01+00:00 (2000 BCE with timezone offset)

Note: Timezone would be required to avoid ambiguity when dealing with historical dates across different calendar systems.

References

• XML Schema Date/Time Datatypes
• XSD date complete documentation
• RFC 3339 - Date and Time on the Internet
• ISO 8601 - Wikipedia
• JSON Schema date format discussion