zhangshenghang commented on issue #10352:
URL: https://github.com/apache/seatunnel/issues/10352#issuecomment-3756878914
<!-- code-pr-reviewer -->
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.
--
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]
