Try a simpler approach for handling Timestamps on SQL Server #6038
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rationale
More research in the SQL Server JDBC issues list suggests a possible approach for sending Timestamps via JDBC using a standard string format that doesn't vary based on language settings. Turns out the 12.6.3 version of the JDBC driver introduced an issue where the driver failed to parse timestamps returned from the database when parameters were sent setting the explicit
Types.TIMESTAMP
type. (Ironically, the bug was introduced as part of the fix to a Timestamp + stored procedure issue that I filed earlier with the team.) That forced us to always omit the type when setting Timestamp parameters in our statement wrapper, which lead to the need to vary the timestamp format we sent based on locale. The latest (12.8.1) version fixes this issue, so I'm hopeful we can return to setting the explicit type which seems to then universally support the ISO-style format.Related Pull Requests