Thank you Gabriel for this excellent explanation, It's very clear now.
However, is there a way overriding this behavior by storing the
2015-08-12T10:20:21.125+03:00 date as a TimeStamp corresponding to
2015-08-12 10:20:21.125 directly at Phoenix?
Thanks
בתאריך 18 באוג׳ 2015 21:48, Gabriel Reid
Tracking in https://issues.apache.org/jira/browse/PHOENIX-2169
On Thu, Aug 20, 2015 at 5:14 PM, Samarth Jain sama...@apache.org wrote:
Yiannis,
Can you please provide a reproducible test case (schema, minimum data to
reproduce the error) along with the phoenix and hbase versions so we can
Hi Rajeshbabu,
I applied the patch and it resolves the issue. Thank you so much! I'll update
the ticket with my comments.
Sincerely,Anchal
On Thursday, August 20, 2015 10:04 AM, rajeshb...@apache.org
chrajeshbab...@gmail.com wrote:
Hi Anchal,Rajmund
Sorry for late reply.
I have
Hi there,
I am getting an error while executing:
UPSERT INTO READINGS
SELECT R.SMID, R.DT, R.US, R.GEN, R.USEST, R.GENEST, RM.LAT, RM.LON,
RM.ZIP, RM.FEEDER
FROM READINGS AS R
JOIN
(SELECT SMID,LAT,LON,ZIP,FEEDER
FROM READINGS_META) AS RM
ON R.SMID = RM.SMID
the full stacktrace is:
Yiannis,
Can you please provide a reproducible test case (schema, minimum data to
reproduce the error) along with the phoenix and hbase versions so we can
take a look at it further.
Thanks,
Samarh
On Thu, Aug 20, 2015 at 2:09 PM, Yiannis Gkoufas johngou...@gmail.com
wrote:
Hi there,
I am
I guess you could manipulate the Timestamp by adding an extra 3 hours to
it, and that would then give you the expected output in sqlline, but I
really wouldn't advise doing this, as it will likely lead to confusing
issues further down the line (e.g. if you query via JDBC or with another
query
