[ 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)