PEP-4: Proposal for Date and Time Congruence Library

[clnsmth]

In the 2024-10-09 ETSC meeting, we discussed the proposal to create a library for handling all date and time congruence checks across applications in the EDI ecosystem (e.g. ECC, ezEML, and DEX). The goal of this library is to reduce redundant code, simplify maintenance, and ensure consistency in handling date and time operations.

While we will eventually want a library to cover all types of congruence checks, the architecture for such a comprehensive solution is beyond the scope of this proposal. However, the library should be designed in a way that allows for future integration into a larger library if needed.

@rogerdahl , @jon-ide - what are your thoughts? How could DEX and ezEML benefit from this library? Are there any specific date and time processing requirements we should consider in the design?

[servilla]

Based on the list of unique dateTime formats provided by @jon-ide (unique_formats.txt), I recommend following a more conservative pattern that extends commonly found non-preferred formats with the following criteria:

1. year formats should require a full four-digit year (two-digit years are ambiguous)
2. day formats may either be two-digits for "day of month" or three-digits for "day of year"
3. month formats may either be two-digits or three-character abbreviations
4. case of format strings may vary

With these criteria (and as a first pass), the additions I would recommend (but may be subject to removal for technical reasons) are:

1. MM/DD/YYYY
2. mm/dd/yyyy
3. yyyy-MM-dd HH:mm:ss
4. dd-mon-yyyy (mon = month abbr)
5. yyyy-mm-dd
6. yyyy
7. DD-MON-YYYY (MON = month abbr)
8. yyyy-MM-dd
9. dd-mmm-yyyy (mmm = month abbr)
10. DD/MM/YYYY
11. HH:MM:SS
12. HHMM
13. yyyy-mm-dd HH:MM:SS
14. mm-dd-yyyy
15. YYYY-MM-DD HH:MM:SS
16. YYYY-MM-DD HH:MM
17. MM-DD-YYYY
18. yyyy/mm/dd
19. mm/dd/YYYY
20. DD-WWW-YYYY (WWW = month abbr)

*DeX likely has other constraints since they must be loaded into a data frame and made available for filtering.