RFC3339 year 0000 rejected by date-time format validation

Summary

Validation of the date-time format rejects timestamps containing year 0000, even though the RFC3339 grammar allows any four-digit year.

Example timestamp:

0000-01-01T00:00:00Z

Context

During interoperability testing of JSON Schema date-time format validation across multiple implementations, I observed that this value is accepted by several validators but rejected by python-jsonschema. Further investigation suggests the behavior originates from the rfc3339-validator dependency used internally for date-time checking.

Specification Reference

RFC3339 defines the year component using the following grammar:

date-fullyear = 4DIGIT

Reference:
https://www.rfc-editor.org/rfc/rfc3339

Because the grammar explicitly permits any four digits, the year 0000 is syntactically valid according to the RFC.

Minimal Reproduction

from jsonschema import validate

schema = {
    "type": "string",
    "format": "date-time"
}

validate("0000-01-01T00:00:00Z", schema)

Observed Behavior

The validator raises a ValidationError, indicating the instance is not considered a valid date-time.

Expected Behavior

The timestamp should be accepted as syntactically valid according to the RFC3339 grammar.

Cross-Implementation Observation

During interoperability testing:

• Hyperjump JSON Schema accepts the timestamp.
• jsonschema-rs accepts the timestamp.
• python-jsonschema rejects the timestamp when format validation is enabled.
• Direct calls to rfc3339-validator also reject the timestamp.

This indicates that the behavior likely originates from the underlying RFC3339 validation library used by the Python stack.

Possible Cause

The underlying validation library appears to reject year 0000, possibly due to limitations in date parsing logic or assumptions about supported calendar ranges.

Question

Is this behavior intentional, or would it be preferable for date-time validation to align strictly with the RFC3339 grammar? If the limitation originates in the underlying dependency, clarification in documentation may help users understand the behavior.

Start with the validate(...) minimal reproduction and compare it with the direct rfc3339-validator call described in the issue. Trace how date-time format validation reaches that dependency, then verify the expected result for 0000-01-01T00:00:00Z against RFC3339 and document or test the resulting behavior.