[
https://issues.apache.org/jira/browse/PHOENIX-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387897#comment-15387897
]
James Taylor commented on PHOENIX-868:
--------------------------------------
We should fix this in 5.0 when the Phoenix/Calcite integration comes in. For
now, we can put the fix on the calcite branch. I'd recommend we document how
we're morphing the date/time types for existing tables:
- DATE and TIME type would become TIMESTAMP
- UNSIGNED_DATE and UNSIGNED_TIME would become UNSIGNED_TIMESTAMP
- TIMESTAMP would become TIMESTAMP(9) - see PHOENIX-2511. I think it's fine if
we only support TIMESTAMP(9) and TIMESTAMP(6) which would be the same as
TIMESTAMP and give errors for other precisions.
Once we do this, existing table won't have any occurrences of DATE or TIME and
we can adjust our implementation to be JDBC compliant and represent these under
the covers as an int.
> 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
>
> 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
(v6.3.4#6332)
