Indeed the ideal would be to have some liberty around the supported datetime formats and it would be great if we find people who want to contribute in this direction.
However, this discussion is more about converging and taking a decision around CALCITE-5678 and CALCITE-5957. The results of the survey are not really conclusive since the participation was rather low (4 responses). So far everybody agrees that the SQL standard literal is valid but there are different opinions about the rest. Given the input so far, I am leaning towards leaving the repo as it is for now. This means that CALCITE-5678 remains in place and it is a breaking change that will come in the next Avatica version and do nothing for CALCITE-5957. We can revisit this decision in the future if necessary. Thanks everyone for your inputs! Best, Stamatis On Sun, Oct 1, 2023 at 9:56 AM stanilovsky evgeny <[email protected]> wrote: > > 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
