-
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
hibernate-core/src/main/java/org/hibernate/type/descriptor/java/AbstractTemporalJavaType.java
Outdated
Show resolved
Hide resolved
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
…onvert milliseconds into java.sql.Time
@@ -175,12 +173,8 @@ public Date wrap(Object value, WrapperOptions options) { | |||
return null; | |||
} | |||
|
|||
if ( value instanceof Time time ) { |
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.
Any reason why you removed this?
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.
Request is that output Time
should represent local time on January 1st 1970, but it input can be on any date, for example:
jshell> var t = new Time(System.currentTimeMillis())
t ==> 22:24:43
jshell> new Date(t.getTime())
$6 ==> Thu May 15 22:24:43 CEST 2025
This the reason why we have to treat it like any other java.util.Date
subclass
jshell> var tt = T.millisToSqlTime(t.getTime())
tt ==> 22:24:43
This is now java.sql.Time
instance on January 1st 1970
jshell> new Date(tt.getTime())
$11 ==> Thu Jan 01 22:24:43 CET 1970
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.
I get that, it's just unfortunate that we would have to create copies every time we bind a java.sql.Time
to a prepared statement even if the value already is correctly at the epoch date.
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.
That is true. One possibility to prevent this is to return time if it is already at epoch date, and make new copy if not. Something like
if ( value instanceof Time time ) {
Date date = new Date( time.getTime() );
if ( date.getYear() == 70 && date.getMonth() == 0 && date.getDate() == 1 ) {
return time;
}
}
Alternatively java.util.Calendar
can be used, but I guess that this is 'cheaper' to create java.util.Date
instance than java.util.Calendar
if ( value instanceof Time time ) {
Calendar calendar = Calendar.getInstance();
calendar.setTime( time );
if ( calendar.get( Calendar.YEAR ) == 1970
&& calendar.get( Calendar.MONTH ) == Calendar.JANUARY
&& calendar.get( Calendar.DAY_OF_MONTH ) == 1 ) {
return time;
}
}
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.
LGTM
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.