[
https://issues.apache.org/jira/browse/DRILL-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398558#comment-17398558
]
ASF GitHub Bot commented on DRILL-7926:
---------------------------------------
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]
> The " age " function is not working properly.
> ---------------------------------------------
>
> Key: DRILL-7926
> URL: https://issues.apache.org/jira/browse/DRILL-7926
> Project: Apache Drill
> Issue Type: Bug
> Components: Functions - Drill
> Affects Versions: 1.17.0, 1.18.0
> Reporter: Александр Глухов
> Priority: Blocker
> Attachments: image-2021-05-13-16-17-21-154.png, screenshot-1.png,
> screenshot-2.png
>
>
> The " age " function is not working properly.
> *Playback steps*
> {code:sql}
> select extract(year from m. "years") `years` from (select age('2021-05-13',
> '2007-07-02') `years") m{code}
> *Expected result* 13.
> *Actual result* 14.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
