-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
SQL: JDBC always uses timezone=UTC for requests to server #39915
Labels
Comments
Pinging @elastic/es-search |
matriv
added a commit
to matriv/elasticsearch
that referenced
this issue
Mar 12, 2019
Previously, JDBC's REST call to the server was always sending `UTC` instead of the timezone passed through connection string/properties. Moreover the conversion to `java.sql.Date` was problematic as a milliseconds calculation on the epoch millis was used to set the time to 00:00:00.000 and the timezone info was lost. This caused the resuling `java.sql.Date` object which is always using the JVM's timezone (no matter what timezone setting is used in the connection string/properties) to be wrongly created. Fixes: elastic#39915
matriv
added a commit
that referenced
this issue
Mar 14, 2019
Previously, JDBC's REST call to the server was always sending UTC instead of the timezone passed through connection string/properties. Moreover the conversion to java.sql.Date was problematic as a calculation on the epoch millis was used to set the time to 00:00:00.000 and the timezone info was lost. This caused the resulting java.sql.Date object which is always using the JVM's timezone (no matter what timezone setting is used in the connection string/properties) to be wrongly created. Fixes: #39915
matriv
added a commit
that referenced
this issue
Mar 14, 2019
Previously, JDBC's REST call to the server was always sending UTC instead of the timezone passed through connection string/properties. Moreover the conversion to java.sql.Date was problematic as a calculation on the epoch millis was used to set the time to 00:00:00.000 and the timezone info was lost. This caused the resulting java.sql.Date object which is always using the JVM's timezone (no matter what timezone setting is used in the connection string/properties) to be wrongly created. Fixes: #39915
matriv
added a commit
that referenced
this issue
Mar 14, 2019
Previously, JDBC's REST call to the server was always sending UTC instead of the timezone passed through connection string/properties. Moreover the conversion to java.sql.Date was problematic as a calculation on the epoch millis was used to set the time to 00:00:00.000 and the timezone info was lost. This caused the resulting java.sql.Date object which is always using the JVM's timezone (no matter what timezone setting is used in the connection string/properties) to be wrongly created. Fixes: #39915
matriv
added a commit
that referenced
this issue
Mar 14, 2019
Previously, JDBC's REST call to the server was always sending UTC instead of the timezone passed through connection string/properties. Moreover the conversion to java.sql.Date was problematic as a calculation on the epoch millis was used to set the time to 00:00:00.000 and the timezone info was lost. This caused the resulting java.sql.Date object which is always using the JVM's timezone (no matter what timezone setting is used in the connection string/properties) to be wrongly created. Fixes: #39915
matriv
added a commit
that referenced
this issue
Mar 14, 2019
Previously, JDBC's REST call to the server was always sending UTC instead of the timezone passed through connection string/properties. Moreover the conversion to java.sql.Date was problematic as a calculation on the epoch millis was used to set the time to 00:00:00.000 and the timezone info was lost. This caused the resulting java.sql.Date object which is always using the JVM's timezone (no matter what timezone setting is used in the connection string/properties) to be wrongly created. Fixes: #39915
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
JDBC always uses
UTC
as the timezone param for requests sent to the server,regardless of the
?timezone=XXX
used in the connection string.This is a bug, as all calculations with date/times (eg. scalar functions applies on top of them like DAY_OF_MONTH) are done with
UTC
timezone, and they potentially give wrong results, and thoseoperations cannot be translated and fixed in the client JDBC (which still holds the correct timezone passed from the params), as the original information of the exact timestamp is lost.
The text was updated successfully, but these errors were encountered: