[BUG] ParseDateTime should not support special dates with Spark 3.2

[andygrove]

Describe the bug

ParseDateTimeSuite:

- WITH DECIMALS: to_date default pattern *** FAILED ***
  Mismatch between CPU and GPU for the following rows:
  
  [#0] CPU: [epoch,null]
  [#0] GPU: [epoch,1970-01-01]
  
  
  
  [#1] CPU: [now,null]
  [#1] GPU: [now,2021-09-03]
  
  
  
  [#2] CPU: [today,null]
  [#2] GPU: [today,2021-09-03]
  
  
  
  [#3] CPU: [yesterday,null]
  [#3] GPU: [yesterday,2021-09-02]
  
  
  
  [#4] CPU: [tomorrow,null]
  [#4] GPU: [tomorrow,2021-09-04] (ParseDateTimeSuite.scala:410)

Steps/Code to reproduce bug
Run ParseDateTimeSuite

Expected behavior
Tests should pass

Environment details (please complete the following information)
N/A

Additional context
Spark PR: apache/spark@a59063d

[Salonijain27]

We need to find the related change in Spark before we make a change

[andygrove]

I've added the Spark PR to the "Additional context" section

[revans2]

Wow that PR has no config to get the old behavior in it at all. Just the advice.

• In Spark 3.2, special datetime values such as epoch, today, yesterday, tomorrow, and now are supported in typed literals only, for instance, select timestamp'now'. In Spark 3.1 and 3.0, such special values are supported in any casts of strings to dates/timestamps. To keep these special values as dates/timestamps in Spark 3.1 and 3.0, you should replace them manually, e.g. if (c in ('now', 'today'), current_date(), cast(c as date)).

It looks like this was a bug fix because "now" was being replaced per row, which meant that the results could change for each row, and possibly depend on the machine it was run on. I don't think there will be a config to get the old behavior. This is good overall, but we still have to support the old behavior for older version.