PEP-4: Support for Non-Zero-Padded Date and Time Values?

[clnsmth]

Problem Statement:

In reviewing the acceptance of date and time values, we are evaluating whether to allow input formats that do not use zero-padding (e.g., "3/5/2025" instead of "03/05/2025"). A key consideration is whether such inputs are reliably parsed using the strptime standard, which is commonly used in downstream systems for date/time interpretation.

General Support Across Systems:

Based on a preliminary review, while the POSIX specification for strptime defines format codes like %m, %d, and %H as matching zero-padded numeric values, it seems most real-world implementations—including GNU libc, BSD libc (macOS), and Python—accept both zero-padded and non-zero-padded input. This means that values like "3" for %m or "7" for %H are typically parsed correctly, even if not explicitly guaranteed by the standard.

Typical Behavior:

This suggests:

• %m, %d, %H, %M, %S, %Y, and %y all generally accept single-digit input values.
• Parsers are forgiving and often consume as many digits as make sense, regardless of padding.

Possible Edge Case and Limitation:

• Embedded systems or constrained environments may use minimal libc implementations that follow the standard more strictly.

Recommendation Considerations:

• If maximum interoperability and strict schema validation are priorities, requiring zero-padded input ensures full compliance and predictability.
• If user flexibility and leniency are more important, allowing non-zero-padded input is unlikely to cause practical issues on mainstream systems, but should be tested.

[clnsmth]

Limitations of Regex-Based Date/Time Validation

ezEML's date and time quality control currently relies on regular expressions, which work well for date/time inputs that use separators (e.g., -, /, :). However, this approach breaks down when values lack separators—especially with non-zero-padded inputs—since regex patterns can’t reliably distinguish between components (e.g., "3052025" vs. "03052025").

To robustly support non-zero-padded and separator-free formats, parser-based validation using strptime (or equivalents) may be necessary.