DanielCarter-stack commented on issue #10352:
URL: https://github.com/apache/seatunnel/issues/10352#issuecomment-3759109730
<!-- code-pr-reviewer -->
Valid concern. The current implementation uses simple substring matching
(`contains("yy")`/`contains("mm")`) to infer return types, which incorrectly
accepts format variants like `yyyy-M-d H:m:s` as `LocalDate` instead of
rejecting them.
**Evidence:**
- Runtime logic: `DateTimeFunction.java:630-653` - `parsedatetime()`
branches based on substring checks without format validation
- Compile-time inference: `ZetaSQLType.java:430-448` - same substring
matching approach for type derivation
- Documentation: `sql-functions.md:898-907` - only references
`DateTimeFormatter`, no whitelist defined
Adopting a format whitelist with clear rejection (as suggested in #10328)
would improve correctness and user experience. The whitelist should be enforced
in both type inference and execution phases.
**Question:** Should the initial whitelist include only standard formats
like `yyyy-MM-dd HH:mm:ss[.SSS]`, `yyyy-MM-dd`, `HH:mm:ss[.SSS]`, and
`yyyy-MM-dd'T'HH:mm:ss[.SSS]`, or do you have additional formats in mind?
--
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]
