You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by "Richard Antal (Jira)" <ji...@apache.org> on 2020/06/02 12:51:00 UTC
[jira] [Comment Edited] (PHOENIX-5066) The TimeZone is incorrectly
used during writing or reading data
[ https://issues.apache.org/jira/browse/PHOENIX-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123679#comment-17123679 ]
Richard Antal edited comment on PHOENIX-5066 at 6/2/20, 12:50 PM:
------------------------------------------------------------------
I created a [pull request|[https://github.com/apache/phoenix/pull/796]] to make it easier to see the differences.
In the latest patch I changed the static functions in the DateUtil class to non static. We can get the DateUtil instance by calling the getDateUtilContext on PhoenixConnection, this way we can set the timezone attribute for the DateUtil when we create the connection and use it later.
This change looks huge because DateUtil was replaced to getDateUtilContext everywhere.
There are lot of failing tests outside of GMT time zones, because this patch introduces a new behaviour for timezone handling. Strings that are parsed to time are not interpreted in GMT/UTC but in local timezone and we store the data in GMT or in QueryServices.DATE_FORMAT_TIMEZONE_ATTRIB if that is set to some other value.
I would like to hear other opinions about this change before doing any further modification.
was (Author: richardantal):
I also created a [pull request|[https://github.com/apache/phoenix/pull/796]] to make it easier to see the differences.
In the latest patch I changed the static functions in the DateUtil class to non static. We can get the DateUtil instance by calling the getDateUtilContext on PhoenixConnection, this way we can set the timezone attribute for the DateUtil when we create the connection and use it later.
This change looks huge because DateUtil was replaced to getDateUtilContext everywhere.
There are some failing tests outside of GMT time zones, because this patch introduces a new behaviour for timezone handling. Strings that are parsed to time are not interpreted in GMT/UTC but in local timezone and we store the data in GMT or in QueryServices.DATE_FORMAT_TIMEZONE_ATTRIB if that is set to some other value.
I would like to hear other opinions about this change before doing any further modification.
> The TimeZone is incorrectly used during writing or reading data
> ---------------------------------------------------------------
>
> Key: PHOENIX-5066
> URL: https://issues.apache.org/jira/browse/PHOENIX-5066
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 5.0.0, 4.14.1
> Reporter: Jaanai Zhang
> Assignee: Richard Antal
> Priority: Critical
> Fix For: 4.15.1, 5.1.1, 4.16.0
>
> Attachments: DateTest.java, PHOENIX-5066.4x.v1.patch, PHOENIX-5066.4x.v2.patch, PHOENIX-5066.4x.v3.patch, PHOENIX-5066.master.v1.patch, PHOENIX-5066.master.v2.patch, PHOENIX-5066.master.v3.patch, PHOENIX-5066.master.v4.patch, PHOENIX-5066.master.v5.patch, PHOENIX-5066.master.v6.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have two methods to write data when uses JDBC API.
> #1. Uses _the exceuteUpdate_ method to execute a string that is an upsert SQL.
> #2. Uses the _prepareStatement_ method to set some objects and execute.
> The _string_ data needs to convert to a new object by the schema information of tables. we'll use some date formatters to convert string data to object for Date/Time/Timestamp types when writes data and the formatters are used when reads data as well.
>
> *Uses default timezone test*
> Writing 3 records by the different ways.
> {code:java}
> UPSERT INTO date_test VALUES (1,'2018-12-10 15:40:47','2018-12-10 15:40:47','2018-12-10 15:40:47')
> UPSERT INTO date_test VALUES (2,to_date('2018-12-10 15:40:47'),to_time('2018-12-10 15:40:47'),to_timestamp('2018-12-10 15:40:47'))
> stmt.setInt(1, 3);stmt.setDate(2, date);stmt.setTime(3, time);stmt.setTimestamp(4, ts);
> {code}
> Reading the table by the getObject(getDate/getTime/getTimestamp) methods.
> {code:java}
> 1 | 2018-12-10 | 23:45:07 | 2018-12-10 23:45:07.0
> 2 | 2018-12-10 | 23:45:07 | 2018-12-10 23:45:07.0
> 3 | 2018-12-10 | 15:45:07 | 2018-12-10 15:45:07.66
> {code}
> Reading the table by the getString methods
> {code:java}
> 1 | 2018-12-10 15:45:07.000 | 2018-12-10 15:45:07.000 | 2018-12-10 15:45:07.000
> 2 | 2018-12-10 15:45:07.000 | 2018-12-10 15:45:07.000 | 2018-12-10 15:45:07.000
> 3 | 2018-12-10 07:45:07.660 | 2018-12-10 07:45:07.660 | 2018-12-10 07:45:07.660
> {code}
> *Uses GMT+8 test*
> Writing 3 records by the different ways.
> {code:java}
> UPSERT INTO date_test VALUES (1,'2018-12-10 15:40:47','2018-12-10 15:40:47','2018-12-10 15:40:47')
> UPSERT INTO date_test VALUES (2,to_date('2018-12-10 15:40:47'),to_time('2018-12-10 15:40:47'),to_timestamp('2018-12-10 15:40:47'))
> stmt.setInt(1, 3);stmt.setDate(2, date);stmt.setTime(3, time);stmt.setTimestamp(4, ts);
> {code}
> Reading the table by the getObject(getDate/getTime/getTimestamp) methods.
> {code:java}
> 1 | 2018-12-10 | 23:40:47 | 2018-12-10 23:40:47.0
> 2 | 2018-12-10 | 15:40:47 | 2018-12-10 15:40:47.0
> 3 | 2018-12-10 | 15:40:47 | 2018-12-10 15:40:47.106 {code}
> Reading the table by the getString methods
> {code:java}
> 1 | 2018-12-10 23:40:47.000 | 2018-12-10 23:40:47.000 | 2018-12-10 23:40:47.000
> 2 | 2018-12-10 15:40:47.000 | 2018-12-10 15:40:47.000 | 2018-12-10 15:40:47.000
> 3 | 2018-12-10 15:40:47.106 | 2018-12-10 15:40:47.106 | 2018-12-10 15:40:47.106
> {code}
>
> _We_ have a historical problem, we'll parse the string to Date/Time/Timestamp objects with timezone in #1, which means the actual data is going to be changed when stored in HBase table。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)