Skip to content
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

Feat Request : Handle human errors for PartialDate completion #65

Open
r1m opened this issue Oct 27, 2020 · 1 comment
Open

Feat Request : Handle human errors for PartialDate completion #65

r1m opened this issue Oct 27, 2020 · 1 comment

Comments

@r1m
Copy link

r1m commented Oct 27, 2020

We encounter a lot of interpretation errors at the end of the month because of human errors in TAC bulletins.
On a 30 day month, sometime the operator fill the dates with 31.
Example : on 30st of September a bulletin is issued with date 311000. Actually meaning the 1st of October.

Depending on the reference condition we use to rebuild the completed date, we can end up with a date one month early or one month late. The code will shift again for one month because 31st of September is not a valid date.

Proposal :
Add a ReferenceCondition that allows invalid date to be interpreted by adding x days to the start of the month, instead of setting the day field with the given value.
Add 31 days to 1of September -> 1st of October.

@petringo
Copy link
Contributor

I think the case here is different from what toZonedDateTime(final ZonedDateTime referenceTime, final ReferenceCondition condition) and related methods were designed for. The ReferenceCondition is actually a constraint, not a completion rule or hint.

The solution might be to add new method(s) similar to toZonedDateTime(final YearMonth issueYearMonth) or toZonedDateTime(final LocalDate issueDate) allowing lenient resolving of complete time, letting day of month out of range to flow forward in time as you described. E.g. toZonedDateTimeLenient(...).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants