jnturton commented on code in PR #2689:
URL: https://github.com/apache/drill/pull/2689#discussion_r1003172295
##########
contrib/udfs/src/main/java/org/apache/drill/exec/udfs/DateFunctions.java:
##########
@@ -140,8 +143,77 @@ public void eval() {
java.time.format.DateTimeFormatter formatter =
java.time.format.DateTimeFormatter.ofPattern(format);
java.time.LocalDateTime dateTime =
java.time.LocalDateTime.parse(inputDate, formatter);
- java.time.LocalDateTime td =
org.apache.drill.exec.udfs.NearestDateUtils.getDate(dateTime, intervalString);
+ java.time.LocalDateTime td = DateConversionUtils.getDate(dateTime,
intervalString);
out.value =
td.atZone(java.time.ZoneId.of("UTC")).toInstant().toEpochMilli();
}
}
+
+ @FunctionTemplate(names = {"yearweek","year_week"},
+ scope = FunctionTemplate.FunctionScope.SIMPLE,
+ nulls = FunctionTemplate.NullHandling.NULL_IF_NULL)
+ public static class YearWeekFunction implements DrillSimpleFunc {
+ @Param
+ VarCharHolder inputHolder;
Review Comment:
See below, I think that in that case we want this function defined for DATE
only using the convertlet stuff to convert it to `100*year()+week()` and a new
```
create function INT year_week_auto_parse(date_str VARCHAR) as
100*year(to_timestamp(date_str, 'auto')) + week(to_timestamp(date_str, 'auto'));
```
(assuming we can do these pure SQL UDFs). So we're composing general purpose
functions to get to the specific "What I need right now is a durable year_week
function" instead of hardcoding different behaviour into a new `year_week` to
what we offer for e.g. `year`, `month`, or `week`. The latter would leave users
frustrated by date extraction functions that arbitrarily (to them) work on
mixed format strings in some cases and not in others.
--
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]
