Thank you, Stamatis. I vote for direct following the SQL standard, i.e.: only strict SQL standard compliant literals
date like 10-1-1 is strange and contain huge field for human errors.
Hey everyone, CALCITE-5678, which landed recently in Avatica, enforces strict validation of datetime literals and is inline with the SQL standard specification. However, this strict validation also leads to behavior changes (e.g., CALCITE-5957) since some previously "valid" dates are now considered invalid. Roughly four people have expressed an opinion on the aforementioned JIRAs but since this is a change that will likely have wider impact I would prefer to gather some more inputs from the community. I created a very brief anonymous survey [1] with a few sample literals to aid the decision on what Calcite/Avatica should consider valid and invalid from now onwards. I will close the survey in 96 hours from now. Please fill in the survey and/or comment under the respective tickets. Based on the feedback we can opt to do one of the following: * Revert CALCITE-5678 (restore the liberal parsing of datetime literals) * Merge CALCITE-5957 (stricter parsing but leading zeros are optional) * Reject CALCITE-5957 (only strict SQL standard compliant literals) Best, Stamatis [1] https://forms.gle/23f3yVhJCKZJdqQu8
