dzamo commented on a change in pull request #2284: URL: https://github.com/apache/drill/pull/2284#discussion_r688385899
########## File path: exec/java-exec/src/main/codegen/templates/DateIntervalFunctionTemplates/AgeFunction.java ########## @@ -0,0 +1,106 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +<@pp.dropOutputFile /> +<#assign className="GAge"/> + +<@pp.changeOutputFile name="/org/apache/drill/exec/expr/fn/impl/${className}.java"/> + +<#include "/@includes/license.ftl"/> + +package org.apache.drill.exec.expr.fn.impl; + +import org.apache.drill.exec.expr.DrillSimpleFunc; +import org.apache.drill.exec.expr.annotations.FunctionTemplate; +import org.apache.drill.exec.expr.annotations.FunctionTemplate.NullHandling; +import javax.inject.Inject; +import org.apache.drill.exec.expr.annotations.Output; +import org.apache.drill.exec.expr.annotations.Workspace; +import org.apache.drill.exec.expr.annotations.Param; +import org.apache.drill.exec.expr.holders.*; +import org.apache.drill.exec.record.RecordBatch; +import org.apache.drill.exec.ops.ContextInformation; + +/* + * This class is generated using freemarker and the ${.template_name} template. + */ + +public class ${className} { + +<#list dateIntervalFunc.dates as fromUnit> +<#list dateIntervalFunc.dates as toUnit> + + @FunctionTemplate(name = "age", + scope = FunctionTemplate.FunctionScope.SIMPLE, + nulls = FunctionTemplate.NullHandling.NULL_IF_NULL) + public static class Age${fromUnit}To${toUnit} implements DrillSimpleFunc { + + @Param ${toUnit}Holder left; + @Param ${fromUnit}Holder right; + @Output IntervalHolder out; + + public void setup() { + } + + public void eval() { + java.time.LocalDateTime from = java.time.Instant.ofEpochMilli(right.value).atZone(java.time.ZoneOffset.UTC).toLocalDateTime(); + java.time.LocalDateTime to = java.time.Instant.ofEpochMilli(left.value).atZone(java.time.ZoneOffset.UTC).toLocalDateTime(); Review comment: @paul-rogers Recall my comment on the previous PR where I observe that the expressions above _do_ yield the correct LocalDateTime when you start from milliseconds since the "local epoch". If they didn't work there would be widespread breakage in Drill, e.g. `select cast(now() as varchar)` would give the wrong answer except in Drillbits set to UTC because it relies on identical code (c.f. CastDateVarChar.java). Yet said query correctly displays the local time on my UTC+2 machine. Here's my corrected sequence for your UTC-8 example. The incoming value is known to be milliseconds since the local epoch i.e. midnight 1970-01-01 in UTC-8. We deliberately misconstrue it as Unix time using `ofEpochMilli`, producing an absolute time with an error of -8 hours. We express that in the UTC time zone using `atZone`, then throw away the zone component using `toLocalDateTime`, then (presto!) finally declare that result to in fact be UTC-8, picking up a compensating error of +8 hours and the correct local time. I'm not advocating the above! I did not invent it, I (and the unfortunate Oleg) merely encountered it. I like subtle trickery in magic shows, not code. Would that I'd never set hands on it but I have and - it does give the correct answer, - it is used fairly widely in the code base making it kind of a _de facto_ standard, - included in the previous point are an equivalent procedure using Joda and instances of the procedure in reverse (starting with a local date object and ending in ms since "local epoch"), - the unfortunate ms since the "local epoch" representation is probably always going to require _something_ nasty and confusing. I think replacing this date code pattern in the code base, if we do, should be a fell swoop achieved in another PR devoted entirely to date code refactoring (and which also replaces usage of Joda). In the short term I propose that to fix the badly broken `AGE` function we should resign ourselves to using date code consistent with what's already there. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
