You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ClickHouse stores datetime as Unix timestamp, and timezone in column metadata. So timzone will only affect datetime value in string format during parsing and displaying. As ClickHouse server does not support custom timezone in http interface(only X-ClickHouse-Timezone header in response, which represents server timezone), it uses column/server timezone to format datetime values and returned in text format like TabSeparatedWithNamesAndTypes(which is relied by JDBC driver). Unfortunately this does not work when ClickHouse server uses non-UTC timezone, and JDBC client with use_server_time_zone set to false is in a different timezone. On the other hand, changing date_time_output_format to 'unix_timestamp' can avoid this issue, but it's not default and it may cause more issues since JDBC driver didn't consider that.
In order to fix the timezone issue:
take below workaround in 0.3.x (consider date_time_output_format when parsing)
re-format datetime string returned from server(parse using column/server timezone, and then re-format using client timezone)
switch to RowBinary format starting from 0.3.1 for permanent fix
The text was updated successfully, but these errors were encountered:
ClickHouse stores datetime as Unix timestamp, and timezone in column metadata. So timzone will only affect datetime value in string format during parsing and displaying. As ClickHouse server does not support custom timezone in http interface(only
X-ClickHouse-Timezone
header in response, which represents server timezone), it uses column/server timezone to format datetime values and returned in text format likeTabSeparatedWithNamesAndTypes
(which is relied by JDBC driver). Unfortunately this does not work when ClickHouse server uses non-UTC timezone, and JDBC client withuse_server_time_zone
set to false is in a different timezone. On the other hand, changingdate_time_output_format
to'unix_timestamp'
can avoid this issue, but it's not default and it may cause more issues since JDBC driver didn't consider that.In order to fix the timezone issue:
consider)date_time_output_format
when parsingThe text was updated successfully, but these errors were encountered: