dybyte commented on issue #10352:
URL: https://github.com/apache/seatunnel/issues/10352#issuecomment-3757503124
> Thank you for raising this issue. The current implementation in
`DateTimeFunction.java` (L630-653) and `ZetaSQLType.java` (L430-448) does rely
on simple substring matching via `format.contains("yy")` and
`format.contains("mm")` to infer return types, which can lead to inconsistent
behavior for format variants like `yyyy-M-d H:m:s`.
>
> The documentation at `docs/en/transforms/sql-functions.md` (L898-907)
currently references `java.time.format.DateTimeFormatter` support without
explicitly listing allowed formats, making it unclear which patterns are
formally supported.
>
> To move forward with defining a format whitelist, could you clarify:
>
> 1. Should the whitelist be extensible (e.g., allow custom formats via
config), or strictly limited to a fixed set like `yyyy-MM-dd HH:mm:ss`,
`yyyy-MM-dd`, `HH:mm:ss`, and `yyyy-MM-dd'T'HH:mm:ss`?
> 2. For backward compatibility, should formats currently working with
`DateTimeFormatter` but outside the whitelist be grandfathered in, or should
this be a breaking change?
> 3. Should the whitelist validation happen at function planning time (type
inference) or execution time?
>
> Providing a concrete list of formats you'd like supported, along with
compatibility expectations, would help the community evaluate this proposal.
My preference would be to start with a strict, fixed whitelist of supported
formats.
If a format is not in the whitelist, the function should explicitly throw an
exception.
Although this is technically a breaking change, the current behavior is
already
silently inconsistent, so failing fast seems preferable.
We can keep the initial whitelist small and well-defined, and consider
extensions later
if there is demand.
For validation, I think it should happen at both planning/type inference
time and execution time as a safety net.
--
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]
