You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "rootvector2 (via GitHub)" <gi...@apache.org> on 2026/08/16 06:50:00 UTC
[PR] reject out-of-range sql date/time fields in DateTimeConverter.toDate [commons-beanutils]
rootvector2 opened a new pull request, #436:
URL: https://github.com/apache/commons-beanutils/pull/436
`DateTimeConverter.toDate` builds `java.sql.Date`/`Time`/`Timestamp` with `valueOf`, which silently rolls over out-of-range fields (`2006-02-31` -> `2006-03-03`, `25:70:90` -> `02:11:30`, `2006-10-23 25:70:90` -> next day), so malformed input in the default `useLocaleFormat=false` path is accepted as a different value instead of rejected; found while auditing the sql converters against the strict `setLenient(false)`/`ParsePosition` check the same class already applies on its locale-format branch, and fixed by validating against strict JDBC-format `DateTimeFormatter`s (`ResolverStyle.STRICT`) before `valueOf`, leaving valid padded and single-digit input unchanged.
- [x] Read the [contribution guidelines](CONTRIBUTING.md) for this project.
- [ ] Read the [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) if you use Artificial Intelligence (AI).
- [ ] I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
- [x] Run a successful build using the default [Maven](https://maven.apache.org/) goal with `mvn`; that's `mvn` on the command line by itself.
- [x] Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
- [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
- [x] Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] reject out-of-range sql date/time fields in DateTimeConverter.toDate [commons-beanutils]
Posted by "garydgregory (via GitHub)" <gi...@apache.org>.
garydgregory commented on PR #436:
URL: https://github.com/apache/commons-beanutils/pull/436#issuecomment-5307668163
Hello @rootvector2
Thank you for the PR.
The Javadoc and exception messages should be updated, for example
> String must be in JDBC format [yyyy-MM-dd] to create a ...
The behavioral contract has now become stricter: out-of-range fields are rejected instead of being rolled over. The error messages are unchanged. The Javadoc and messages are technically still true but it do not document the new
strictness. How about mention that "validation is strict, out-of-range fields are rejected”.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Reject out-of-range sql date/time fields in DateTimeConverter.toDate [commons-beanutils]
Posted by "rootvector2 (via GitHub)" <gi...@apache.org>.
rootvector2 closed pull request #436: Reject out-of-range sql date/time fields in DateTimeConverter.toDate
URL: https://github.com/apache/commons-beanutils/pull/436
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Reject out-of-range sql date/time fields in DateTimeConverter.toDate [commons-beanutils]
Posted by "rootvector2 (via GitHub)" <gi...@apache.org>.
rootvector2 commented on PR #436:
URL: https://github.com/apache/commons-beanutils/pull/436#issuecomment-5327033154
Makes sense. Updated all three exception messages to append "validation is strict, out-of-range fields are rejected" and added the same note to the `toDate` javadoc. Full `mvn` build still green (1287 tests, 0 failures).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Reject out-of-range sql date/time fields in DateTimeConverter.toDate [commons-beanutils]
Posted by "rootvector2 (via GitHub)" <gi...@apache.org>.
rootvector2 commented on PR #436:
URL: https://github.com/apache/commons-beanutils/pull/436#issuecomment-5437640060
Confirmed 148cad5 on master covers everything, no follow up needed. Agreed on `valueOf(LocalDate.parse(...))`, cleaner than parsing twice. Thanks for landing it and the credit.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Reject out-of-range sql date/time fields in DateTimeConverter.toDate [commons-beanutils]
Posted by "garydgregory (via GitHub)" <gi...@apache.org>.
garydgregory commented on PR #436:
URL: https://github.com/apache/commons-beanutils/pull/436#issuecomment-5386183087
Hello @rootvector2
I pushed patched up version of this PR. I think this PR can be closed unless you see follow up work needed.
The problematic bug I fixed is three instances of double parsing.
Instead of going round and round, I applied the diff locally, made the following changes, and pushed to master.
Double parsing for the `java.sql.Date` case.
Validation parses with the strict formatter and valueOf parses again. Functionally correct, but wasteful. For example:
```
LocalDate.parse(value, SQL_DATE_FORMAT);
return type.cast(java.sql.Date.valueOf(value));
```
The parsed LocalDate is discarded. A more efficient form would be `Date.valueOf(LocalDate.parse(...))`.
Double parsing of for the `java.sql.Time` case. Same as above.
Double parsing of for the `java.sql.Timestamp` case. Same as above.
I added details to Javadocs to clarify intent.
I added the follow unit tests:
In SqlDateConverterTest
testDefaultStringToTypeConvertValidLeapYear
testDefaultStringToTypeConvertInvalidNonLeapYearFeb29
testDefaultStringToTypeConvertValidBoundaryDates
testDefaultStringToTypeConvertStrictValidationMessage
In SqlTimeConverterTest
testDefaultStringToTypeConvertValidBoundaryTimes
testDefaultStringToTypeConvertInvalidTimeHourMinuteSecond
testDefaultStringToTypeConvertStrictValidationMessage
In SqlTimestampConverterTest
testDefaultStringToTypeConvertValidTimestampWithFraction
testDefaultStringToTypeConvertInvalidTimestampOutOfRangeDate
testDefaultStringToTypeConvertInvalidTimestampOutOfRangeTime
testDefaultStringToTypeConvertStrictValidationMessage
These tests cover valid leap-year and boundary values, invalid out-of-range values for all three SQL types, timestamp fraction handling and verification that the new ConversionException messages mention strict validation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@commons.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org