BeamCalcRel implementation of date/time types aren't always Integer

[damccorm]

For some reason date and time offsets aren't always represented in generated code as Integer, sometimes they get unconverted to Long. This inconsistent behavior may lead to bugs. We should figure out the root cause.

Imported from Jira BEAM-12175. Original Jira may contain additional context.
Reported by: apilloud.

[vampire-hunter-lincoln]

Hi @damccorm,

Context
My team is using logical DATE(LogicalType<LocalDate, Long>) to represent DATE in Beam SQL(backed by Apache Calcite), but I find this comment.

Analysis
After reading some related source code, here is what happened for logical DATE(LogicalType<LocalDate, Long>) processing in Beam SQL according to my understanding, please correct me if I am wrong:

1. Since Beam configures Calcite to use java.lang.Long as the physical type for Calcite DATE, it means the compiled code will expect a Long object to hold value of Calcite DATE. Janino, as a Java compiler, will compile the expression according to Java's type rules.
2. During Beam value -> Calcite Value, an Integer value is extracted from the Java LocalDate(code). We provide this integer as a Calcite DATE input in Janino evaluation step.
3. During Janino evaluation step, if any conversion(expression) happens to this Integer, the result will be saved into a Long object and return a Long as output. Otherwise, it will still be the same Integer as output. That can explain the original comment.

Solution
So I believe, we can modify the step 2 above, extract a Long value from the Java LocalDate during Beam value -> Calcite Value(those two lines: line1 and line2). Then everything will be consistent as Long since both the value and definition will be Long.

Notes
This issue is same as #20864

Please let me know if you have any thoughts! Thank you!

CC: @Abacn