[
https://issues.apache.org/jira/browse/PHOENIX-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940280#comment-13940280
]
Gabriel Reid commented on PHOENIX-869:
--------------------------------------
{quote}The intention with the Calendar version of getDate/Time/Timestamp was to
convert the time (which is stored in GMT) to the time in a potentially
different time zone depending on the Calendar passed through. Is that not the
case?{quote}
I think that the date/time/timestamp values are actually stored as an offset
based on a point in time in GMT (i.e. java epoch) and not actually stored as a
time in GMT, which is the bigger issue outlined at PHOENIX-868. The current
code that uses a Calendar isn't necessarily really broken (i.e. it doesn't
crash). However, the way the calendar is used in the current code just doesn't
do anything. It's technically the same as just copying the timestamp value into
a long primitive and then reading it back out.
The intention of the patch was to remove the code that isn't doing anything,
and document it a bit so that it's more clear in the future when work on
PHOENIX-868 starts. However, it can indeed wait for PHOENIX-868 to be
implemented, as it doesn't actually change any actual behaviour.
> Remove unused Calendar conversions in ResultSet and PreparedStatement
> ---------------------------------------------------------------------
>
> Key: PHOENIX-869
> URL: https://issues.apache.org/jira/browse/PHOENIX-869
> Project: Phoenix
> Issue Type: Bug
> Reporter: Gabriel Reid
> Priority: Minor
> Attachments: PHOENIX-869.patch
>
>
> The PhoenixResultSet and PhoenixPreparedStatement methods that accept a
> Calendar object currently appear to perform what is effectively a no-op with
> the Calendar.
> The time and date values are currently stored as absolute timestamps (and
> lacking any timezone information). There is a larger underlying problem with
> date and time handling in Phoenix, which is outlined in PHOENIX-868 --
> however, there's no reason to keep performing the extra calendar operations
> that have no effect.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
