Summary
Validation of the date-time format rejects timestamps containing year 0000, even though the RFC3339 grammar allows any four-digit year.
Example timestamp:
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:
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.
Summary
Validation of the
date-timeformat rejects timestamps containing year0000, even though the RFC3339 grammar allows any four-digit year.Example timestamp:
Context
During interoperability testing of JSON Schema
date-timeformat validation across multiple implementations, I observed that this value is accepted by several validators but rejected bypython-jsonschema. Further investigation suggests the behavior originates from therfc3339-validatordependency used internally for date-time checking.Specification Reference
RFC3339 defines the year component using the following grammar:
Reference:
https://www.rfc-editor.org/rfc/rfc3339
Because the grammar explicitly permits any four digits, the year
0000is syntactically valid according to the RFC.Minimal Reproduction
Observed Behavior
The validator raises a
ValidationError, indicating the instance is not considered a validdate-time.Expected Behavior
The timestamp should be accepted as syntactically valid according to the RFC3339 grammar.
Cross-Implementation Observation
During interoperability testing:
rfc3339-validatoralso 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-timevalidation to align strictly with the RFC3339 grammar? If the limitation originates in the underlying dependency, clarification in documentation may help users understand the behavior.