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
hibernate.jdbc.time_zone unsupported on TIME columns #856
Comments
In theory it should already work :-) I will have a look |
Can you past an example of an entity you are using? A reproducer would be even better. You can use JBang to start an example testcase:
You can replace |
Nevermind.... I can see the exception |
for more deatils, we are using LocalTime in the Entity and TIME in the database Entity Table |
So the issue here is that the notion of a zoned time is entirely broken and should never have been introduced in SQL (fortunately most databases don't support it). The mapping between timezones depends on the date, and so only zoned datetimes make sense. Until this moment I had no idea about the behavior of So I'm not sure what to do here. "Fix" it to do the same bad thing as ORM, or just ignore the setting when working with times? Or just ignore the property altogether, and figure out how to do this using a connection property instead? (Might need a new feature in the Vert.x client, I'm not sure.) |
I'm removing the "bug" label. It's not a bug that zoned times don't work. They're broken by design. |
(This is of course partly my fault for not digging deeper when I did #676 and noticing the problem with the behavior of |
I started a discussion here. |
Ok, but they are trying to store a |
But that's not what this property does, it seems. In ORM it attaches a timezone to the thing. At least, it seems to me. (I have never been able to completely understand the semantics of that JDBC method.) |
I think I will check what ORM does and do the same. It's probably the behaviour that users tjhat are familiar with ORM will expect anyway. |
hahahaha oh sweet summer child! ORM calls a JDBC method which has essentially undocumented semantics. (And probably behaves differently on every database.) |
So to recap part of the discussion with @yrodiere on Zulip:
So the options are (1) just silently ignore the setting, (2) blow up when the setting is present, or (3) do something we know is broken. I'm inclined to go with (2). |
I suppose we could keep doing what we're currently doing for datetimes, and just ignore the setting which it comes to times. But geez, that amounts to introducing a new and differently-broken interpretation of a feature which is already kinda broken. Brrr. |
@pqab why precisely do you use this setting? Could you reasonably, like, just not use it? |
And same question for @Ngosti2000 |
To be fair, I didn't expect it to be applied to objects that don't have time zone like I suspect the problem is that it's a global property and if you set it because it makes sense in other cases I don't think there is a way to disable it for specific fields. Or maybe there is? |
Right, same. We assumed too much sanity. |
Not that I know of. |
we have some others |
We cannot apply a timezone to a time without a date, this probably the best we can do without throwing an exception.
We cannot apply a timezone to a time without a date, this probably the best we can do without throwing an exception.
We cannot apply a timezone to a time without a date, this probably the best we can do without throwing an exception.
Done |
Hi, we are trying to add the property
<property name="hibernate.jdbc.time_zone" value="UTC"/>
to our application, but we gotUnsupportedOperationException
on some MySQLTIME
columns, may I know is there any plan to support that?Stacktrace
java.lang.UnsupportedOperationException: null at org.hibernate.reactive.adaptor.impl.PreparedStatementAdaptor.setTime(PreparedStatementAdaptor.java:246) Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
Environment Information
The text was updated successfully, but these errors were encountered: