Remove Calcite return type override for FROM_DATE_TIME scalar function in PinotOperatorTable

[yashmayya]

• The FROM_DATE_TIME scalar function returns a long value representing milliseconds since epoch and is not a standard SQL function -

  pinot/pinot-common/src/main/java/org/apache/pinot/common/function/scalar/DateTimeFunctions.java

  Line 488 in 49896eb

  public static long fromDateTime(String dateTimeString, String pattern) {

• The return type was forced to TIMESTAMP in the multistage engine in [multistage] Support TIMESTAMP type and date ops functions #11350 and carried forward in the refactoring in Refactor function registry for multi-stage engine #13573.
• This leads to an inconsistent experience for the same Pinot UDF across the two query engines:
  

• The FROM_DATE_TIME function only has a scalar implementation in Pinot (and no transform function equivalent) that returns a long, so it isn't too clear why the Calcite return type was forced to TIMESTAMP.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 64.04%. Comparing base (59551e4) to head (4713ca7).
Report is 1086 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #14075      +/-   ##
============================================
+ Coverage     61.75%   64.04%   +2.29%     
- Complexity      207     1537    +1330     
============================================
  Files          2436     2596     +160     
  Lines        133233   143292   +10059     
  Branches      20636    21948    +1312     
============================================
+ Hits          82274    91770    +9496     
+ Misses        44911    44777     -134     
- Partials       6048     6745     +697     

Flag	Coverage Δ
custom-integration1	100.00% <ø> (+99.99%)	⬆️
integration	100.00% <ø> (+99.99%)	⬆️
integration1	100.00% <ø> (+99.99%)	⬆️
integration2	0.00% <ø> (ø)
java-11	63.95% <ø> (+2.24%)	⬆️
java-21	63.93% <ø> (+2.31%)	⬆️
skip-bytebuffers-false	64.01% <ø> (+2.27%)	⬆️
skip-bytebuffers-true	63.86% <ø> (+36.13%)	⬆️
temurin	64.04% <ø> (+2.29%)	⬆️
unittests	64.03% <ø> (+2.29%)	⬆️
unittests1	55.60% <ø> (+8.71%)	⬆️
unittests2	34.51% <ø> (+6.78%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yashmayya]

@Jackie-Jiang @xiangfu0 do you know why we had overridden the return type of this scalar function from LONG to TIMESTAMP in the multistage engine?

[Jackie-Jiang]

I think the idea is to return TIMESTAMP type when the value is a timestamp. The reason why this UDF returns LONG in v1 is that it was introduced before TIMESTAMP data type was added, and we cannot easily change the v1 behavior without breaking backward compatibility