Skip to content

HHH-18532 Date/time related JavaType's are not always properly unwrapping into java.util.Date subclasses #8833

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

cigaly
Copy link
Contributor

@cigaly cigaly commented Aug 28, 2024

See Jira issue HHH-18532

Fixing unwrapping date/time related values into java.sql.Date and java.sql.Time


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.


@hibernate-github-bot
Copy link

hibernate-github-bot bot commented Aug 28, 2024

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

@cigaly cigaly force-pushed the HHH-18532 branch 2 times, most recently from 02fff14 to a7f1c0d Compare August 29, 2024 20:16
@cigaly cigaly marked this pull request as ready for review September 13, 2024 12:39
Copy link
Member

@gavinking gavinking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good overall but it seems to me that those calls to construct Time should be passing in milliseconds.

cigaly and others added 3 commits April 28, 2025 11:22
          - reordered matching in unwrap methods to push java.util.Date after java.sql.{Date,Time,Timestamp}
          - use new java.sql.{Date,Time}(instant.toEpochMilli()) instead of java.sql.{Date,Time}.from(instant);
            later method is not subclasses so it is always returning instance of java.util.Date
Comment on lines +68 to +70
final LocalTime localTime = Instant.ofEpochMilli( millis ).atZone( ZoneId.systemDefault() ).toLocalTime();
final Time time = Time.valueOf( localTime );
time.setTime( time.getTime() + localTime.getNano() / 1_000_000 );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it always correct to assume the provided epoch value is in the ZoneId.systemDefault() time zone? I'm afraid this might cause problems. Also having to restore milliseconds using getNano() is unfortunate.

I would much rather prefer an implementation similar to JdbcDateJavaType#toDateEpoch, e.g. toTimeEpoch that instead sets the YEAR, MONTH and DATE to 1970-01-01 and derives the correct time-only milliseconds value from that.

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

Successfully merging this pull request may close these issues.

3 participants