-
Notifications
You must be signed in to change notification settings - Fork 27
1372 datetime comparison #1406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1372 datetime comparison #1406
Conversation
…rison' into 1372-Datetime-Comparison
…d test cases with 'T' in data list
…ds left over from refactoring
gerrycampion
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went through and made a bunch of changes because I felt it was easier than writing all the comments. Primarily the changes remove redundant code and take advantage of enums by iterating over the enums wherever possible instead of handling each enum case individually.
Please review the changes I've made to see how this type of repetition could be avoided and let me know if you disagree with any of those changes. I did not modify the test cases, so I think it should produce the same results. I do have one additional comment to be addressed.
Add automatic precision detection for date comparison operators (Issue #1372 )
Extends the existing date_component parameter to accept "auto" as a value, enabling automatic precision detection when comparing dates with different granularity levels. When specified, the system detects the precision of both dates and compares them at the common (less precise) level. This solves the use case of comparing date-only fields like RFSTDTC ("2025-06-25") with datetime fields like AESTDTC ("2025-06-25T17:22") at the appropriate precision level. Implementation includes support for CDISC partial dates and uncertainty markers, comprehensive test coverage, and updated documentation in README.md and Operator.md.