Hi Gabriel,
Thanks for the pointer. I believe you may be correct! I am using Squirrel SQL with Phoenix jdbc client library. I will write my own client code using the jdbc library to pull back the values and see what I get. Thanks! Matt *From:* Gabriel Reid [mailto:gabriel.r...@gmail.com] *Sent:* 16 April 2015 20:09 *To:* user@phoenix.apache.org *Subject:* Re: Timezones in Phoenix Hi Matt, How are you viewing the timestamps (or in other words, how are you verifying that they're not in GMT)? The reason I ask is because internally in Phoenix, timestamps are used without a timezone (they're just based on a long, as you've saved in your table). However, the java.sql.Timestamp's string representation shows a timestamp in the local timezone of the client. I expect that this string formatting in j.s.Timestamp is what you're encountering. If so, it's not due to anything in Phoenix; instead, it's the way the JDBC api works. - Gabriel On Thu, Apr 16, 2015 at 1:09 PM Matthew Johnson <matt.john...@algomi.com> wrote: Hi all, I have a bunch of millisecond timestamps stored in HBase as Long values. I have a Phoenix view that reads these values as an UNSIGNED_DATE. Now that the clocks have gone forwards, the Phoenix driver has automatically applied the timezone change and as a result all of my Long values are being converted an hour off. Is there a way to set the timezone in Phoenix so that it will read the longs to dates as GMT+0000 (since this is what the millisecond values represent). Or, should I create a new view and create it to return an UNSIGNED_LONG, and then use the ‘to_date’ function and pass in a timezone? This is less convenient as it would mean using the function everywhere where we have queries, but is an option. Thanks, Matt
