Github user tzolkincz closed the pull request at:
https://github.com/apache/incubator-phoenix/pull/26
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the fe
Github user jtaylor-sfdc commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-43171342
This looks good to me. @gabrielreid - if you agree, would you mind pulling
it in?
---
If your project is set up for it, you can reply to this email and ha
Github user gabrielreid commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-43331422
This has been logged in Jira
(https://issues.apache.org/jira/browse/PHOENIX-983) and pulled in.
I don't have the rights to close this PR, could you
Github user gabrielreid commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-42276153
Sounds ok to me.
At first I was thinking that this is something that should really be
avoided (i.e. making what is essentially an API method with s
Github user JamesRTaylor commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-42208259
+1 @tzolkincz. I think this approach makes sense.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user tzolkincz commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-42206344
For now I would keep implementation with Date, as long as Phoenix Date is
suitable for this use case. When we switch Date in Phoenix to JDBC date, we
would mi
Github user gabrielreid commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-42192917
I think that Timestamp is the only applicable JDBC type that is appropriate
for this kind of function -- it's the only thing that represents a specific
poin
Github user tzolkincz commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-42187381
Finally I see your point. So, there is a situation:
* if we use Timestamp, we'll have nanoseconds time resolution which
implicate plus 4 bytes of data when
Github user gabrielreid commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-42072847
> It makes sense to use date cos you wanna get offset by timezone in some
particular date - so you'll probably call this function on column with Date
data t
Github user tzolkincz commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-42016094
HI, thanks for code review.
* I've updated code to parsing Date object not Long object. So if
implementation of Phoenix Date will change, this will still w
Github user gabrielreid commented on the pull request:
https://github.com/apache/incubator-phoenix/pull/26#issuecomment-41725018
A couple of points on this:
* I think that this should probably take a Timestamp as parameter instead
of a Date. Although Dates and Timestamps are curren
GitHub user tzolkincz opened a pull request:
https://github.com/apache/incubator-phoenix/pull/26
add function timezone offset
Function for get offset (shift) of timezone at particular datetime. Example
use case: let's say you have stored some data in some offset and want to query
l
12 matches
Mail list logo
