[
https://issues.apache.org/jira/browse/CALCITE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767195#comment-17767195
]
Stamatis Zampetakis commented on CALCITE-5957:
----------------------------------------------
As far as I see the consensus is to make leading zeros everywhere (including
the year field) optional so '900-01-01' should be accepted as a valid date.
From my perspective that's the only thing missing for merging this PR.
[~zstan] Are you planning to update the PR or you prefer someone else to take
over?
Since '2023-01-01 22:00:00.123.123' is not a regression of CALCITE-5678, I am
fine postponing the validity decision in another ticket. From my experience
users are not very happy when parsers become stricter. I know of many users
would be pretty happy to have 2023-01-01 22:00:00.123 extracted out of
'2023-01-01 22:00:00.123.123' instead of a getting a null or an error.
> Valid DATE '1945-2-2' is not accepted due to regression
> -------------------------------------------------------
>
> Key: CALCITE-5957
> URL: https://issues.apache.org/jira/browse/CALCITE-5957
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.35.0
> Reporter: Runkang He
> Priority: Blocker
> Fix For: avatica-1.24.0
>
> Attachments: image-2023-08-27-19-09-33-284.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DATE '1945-2-2' is a valid date. In CALCITE-5923 when we turn on the result
> check of `testCastStringToDateTime`, we find that Calcite accepted DATE
> '1945-2-2' before CALCITE-5678 but not afterwards, so this is a regression
> that we need to fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
