stevomitric commented on PR #59577:
URL: https://github.com/apache/spark/pull/59577#issuecomment-6398604687
Thanks @uros-b for the review!
- Precision 6 vs 7–9: Updated the description. With a format, a DATE or
other-family timestamp input at precision 6 keeps the SPARK-52457 behavior, the
same as the two-argument form, while 7–9 converts like CAST. Fixing SPARK-52457
removes the difference, so I'd keep that separate from this PR.
- Numeric input: #59243 landed with coercion, so I merged master and kept
its acceptsNumeric condition together with the nanosecond types in inputTypes.
A numeric input with a format is now parsed as a string at every precision,
consistent with the two-argument form. I also took over its doc wording and
added a precision-6 case to the tests.
- try_to_timestamp overflow: Confirmed it's pre-existing in the microsecond
path. With a format, try_to_timestamp('-290309-01-01', 'yyyy-MM-dd') throws
ArithmeticException: long overflow in both ANSI modes, and so do to_timestamp,
unix_timestamp and to_date. The nanosecond path here inherits it, so I'd leave
it to a separate fix.
- BIGINT precision: It only affects out-of-range values like 4294967305, and
with the preview flag off the call still fails, just with FEATURE_NOT_ENABLED
instead of INVALID_TIMESTAMP_PRECISION. Since 4.3.0 is already at RC2, do we
need to backport it?
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
