[ 
https://issues.apache.org/jira/browse/PHOENIX-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Elser updated PHOENIX-868:
-------------------------------
    Fix Version/s:     (was: 5.0.0)

> Make Time, Date, and Timestamp handling JDBC-compliant
> ------------------------------------------------------
>
>                 Key: PHOENIX-868
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-868
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Gabriel Reid
>            Assignee: Rajeshbabu Chintaguntla
>            Priority: Major
>
> From what I understand from the JDBC documentation, the way that a 
> java.sql.Date should be handled via JDBC is simply as a day, month, and year, 
> despite the fact that it is internally represented as a timestamp (the same 
> kind of thing applies to Time objects, which are a triple of hours, minutes, 
> and seconds).
> Further, my understanding is that it is the responsibility of a JDBC driver 
> to do normalization of incoming Date and Time (and maybe Timestamp) objects 
> to interpret them as being in the current time zone, and remove the extra 
> components (i.e. time components for a Date, and date components for a Time) 
> before storing the value.
> This means that today, if I insert a column value consisting of 'new 
> Date(System.currentTimeMillis())', then I should be able to retrieve that 
> same value with a filter on 'Date.valueOf(“2014-03-18”)’. Additionally, that 
> filter should work regardless of my own local timezone.
> It also means that if I store ‘Time.valueOf("07:00:00”)’ in a TIME field in a 
> database in my current timezone, someone should get “07:00:00” if they run 
> 'ResultSet#getTime(1).toString()’ on that value, even if they’re in a 
> different timezone than me.
> From what I can see right now, Phoenix doesn’t currently exhibit this 
> behavior. Instead, the full long representation of Date, Time, and Timestamps 
> is stored directly in HBase, without dropping the extra date fields or doing 
> timezone conversion.
> From the current analysis, what is required for Phoenix to be JDBC-compliant 
> in terms of time/date/timestamp handling is:
> * All incoming time-style values should be interpreted in the local timezone 
> of the driver, then be normalized and converted to UTC before serialization 
> (unless a Calendar is supplied) in PreparedStatement calls
> * All outgoing time-style values should be converted from UTC into the local 
> timezone (unless a Calendar is supplied) in ResultSet calls
> * Supplying a Calendar to PreparedStatement methods should cause the time 
> value to be converted from the local timezone to the timezone of the calendar 
> (instead of UTC) before being serialized
> * Supplying a Calendar to ResultSet methods should cause the time value from 
> the database to be interpreted as if it was serialized in the timezone of the 
> Calendar, instead of UTC.
> Making the above changes would mean breaking backwards compatibility with 
> existing Phoenix installs (unless some kind of backwards-compatibility mode 
> is introduced or something similar). 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to