-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
base: main
Are you sure you want to change the base?
Conversation
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/JdbcTimestampJavaType.java
Outdated
Show resolved
Hide resolved
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/LocalDateTimeJavaType.java
Outdated
Show resolved
Hide resolved
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/OffsetDateTimeJavaType.java
Outdated
Show resolved
Hide resolved
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/ZonedDateTimeJavaType.java
Outdated
Show resolved
Hide resolved
...te-core/src/test/java/org/hibernate/orm/test/mapping/type/java/DateSubclassesUnwrapTest.java
Outdated
Show resolved
Hide resolved
Thanks for your pull request! This pull request appears to follow the contribution rules. › This message was automatically generated. |
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/LocalDateTimeJavaType.java
Outdated
Show resolved
Hide resolved
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/OffsetDateTimeJavaType.java
Outdated
Show resolved
Hide resolved
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/ZonedDateTimeJavaType.java
Outdated
Show resolved
Hide resolved
02fff14
to
a7f1c0d
Compare
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/LocalDateTimeJavaType.java
Outdated
Show resolved
Hide resolved
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/OffsetDateTimeJavaType.java
Outdated
Show resolved
Hide resolved
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.
This looks good overall but it seems to me that those calls to construct Time
should be passing in milliseconds.
11fecb6
to
e5a3870
Compare
1f7511d
to
ffaaaee
Compare
Co-authored-by: Marco Belladelli <[email protected]>
- 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
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 ); |
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.
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.
See Jira issue HHH-18532
Fixing unwrapping date/time related values into
java.sql.Date
andjava.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.