Hi! I now have a preliminary patch for TimeZone sensitive date/time handling in Phoenix. While the patch is not ready for inclusion, it is functionally complete (I think), and can form a basis for discussing the implementation of the new feature.
Please look at it, and let me know if you think that this approach is appropriate, or if you have suggestions for changes in the design and / or implementation. See a quick summary from the ticket below: I now have a functionally complete (still needs optimizations and cleanups) WIP patch at https://github.com/apache/phoenix/pull/1504 At the heart of the solution is the new ExpressionContext object. This object encapsulates the context necessary for evaluating an expression. It is tied to a PhoenixConnection object, and can be configured by properties. At the moment it stores the TimeZone and the format strings. We have two implementations, one of which is GMTExpressionContext, which implements the old date handling behaviour and treats dates (mostly, at least on the server side) as GMT timestamps. The new implementation is CompliantExpressionContext, which is initialized by the client TimeZone (can be overridden), and uses it for String parsing/printing, and for implementing the date functions. The current Phoenix epxression code, especially the singleton type system, is very resistant to adding this context to it, so my implementation uses a ThreadLocal variable to store and access the ExpressionContext. The big challenge is making sure that we propagate the ExpressionContext through all the components of an statement execution. - We're creating new threads for processing scan, and we need to make sure that ExpressionContext ThreadLocal is propagated. - We're also manipulating the classloader, we need to make sure that we copy the Expression TL to the new Classloader. - We need to push the context to the coprocessors. We do this by encoding the Context into Scan properties, and processing those in the coprocessors. - The Expression reconstruction happens BEFORE we rebuild the ExpressionContext TL in the coprocessor hook, so we need to lazily evaluate the context when executing the expression. - There are a few hacky places where we create a ConnectionlessQueryServices object on the server side (to handle default expressions). I have added new fields to the relevant RPC definitions in MetaDataService.proto to push the ExpressionContext into the operations. regards Istvan
