[jira] [Updated] (CALCITE-6092) Invalid test cases in CAST String to Time
[
https://issues.apache.org/jira/browse/CALCITE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6092:
Labels: pull-request-available (was: )
> Invalid test cases in CAST String to Time
> -
>
> Key: CALCITE-6092
> URL: https://issues.apache.org/jira/browse/CALCITE-6092
> Project: Calcite
> Issue Type: Bug
>Reporter: Jerin John
>Priority: Major
> Labels: pull-request-available
>
> Encountered some
> [tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238]
> within SqlOperatorTest file for the CAST operator on String to Datetime
> conversions, which are found to be invalid time strings on some tested
> instances of DBs like BQ, MySql, Postgres.
> It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but
> then updated to verify conversion performed by the CAST operator (refer to
> JIRA ticket: CALCITE-5554 and
> [commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119])
> Example test case (L1223):
> {{cast('1241241' as TIME)}} | expected: "72:40:12" | actual: "16:40:12"
> The string '1241241' is being parsed as number of hours, and internal
> conversion into milliseconds is done as {{{}1241241 * (int) MILLIS_PER_HOUR
> }} which results in na INT overflow.
> The resultant overflowed value is 1701612160 milliseconds = 472.67004
> hours, and 472 % 24 is 16 (and .67 is roughly 2/3 so 40ish minutes seems
> legit)
> Considering that multiple dialects catch these cases as invalid time strings
> for conversion, code should be updated to handle them as exceptions and the
> tests to be corrected to reflect this behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6092) Invalid test cases in CAST String to Time
[
https://issues.apache.org/jira/browse/CALCITE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerin John updated CALCITE-6092:
Description:
Encountered some
[tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238]
within SqlOperatorTest file for the CAST operator on String to Datetime
conversions, which are found to be invalid time strings on some tested
instances of DBs like BQ, MySql, Postgres.
It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but then
updated to verify conversion performed by the CAST operator (refer to JIRA
ticket: CALCITE-5554 and
[commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119])
Example test case (L1223):
{{cast('1241241' as TIME)}} | expected: "72:40:12" | actual: "16:40:12"
The string '1241241' is being parsed as number of hours, and internal
conversion into milliseconds is done as {{{}1241241 * (int) MILLIS_PER_HOUR }}
which results in na INT overflow.
The resultant overflowed value is 1701612160 milliseconds = 472.67004
hours, and 472 % 24 is 16 (and .67 is roughly 2/3 so 40ish minutes seems legit)
Considering that multiple dialects catch these cases as invalid time strings
for conversion, code should be updated to handle them as exceptions and the
tests to be corrected to reflect this behavior.
was:
Encountered some
[tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238]
within SqlOperatorTest file for the CAST operator on String to Datetime
conversions, which are found to be invalid time strings on some tested
instances of DBs like BQ, MySql, Postgres.
It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but then
updated to verify conversion performed by the CAST operator (refer to JIRA
ticket: CALCITE-5554 and
[commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119])
Example test case (L1223):
The string '1241241' is being parsed as number of hours, and internal
conversion into milliseconds is done as {{1241241 * (int) MILLIS_PER_HOUR}}.
The resultant value is 1701612160 milliseconds = 472.67004 hours, and 472 %
24 is indeed 16 (and .67 is roughly 2/3 so 40ish minutes seems legit)
Considering that multiple dialects catch these cases as invalid time strings
for conversion, code should be updated to handle them as exceptions and the
tests to be corrected to reflect this behavior.
> Invalid test cases in CAST String to Time
> -
>
> Key: CALCITE-6092
> URL: https://issues.apache.org/jira/browse/CALCITE-6092
> Project: Calcite
> Issue Type: Bug
>Reporter: Jerin John
>Priority: Major
>
> Encountered some
> [tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238]
> within SqlOperatorTest file for the CAST operator on String to Datetime
> conversions, which are found to be invalid time strings on some tested
> instances of DBs like BQ, MySql, Postgres.
> It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but
> then updated to verify conversion performed by the CAST operator (refer to
> JIRA ticket: CALCITE-5554 and
> [commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119])
> Example test case (L1223):
> {{cast('1241241' as TIME)}} | expected: "72:40:12" | actual: "16:40:12"
> The string '1241241' is being parsed as number of hours, and internal
> conversion into milliseconds is done as {{{}1241241 * (int) MILLIS_PER_HOUR
> }} which results in na INT overflow.
> The resultant overflowed value is 1701612160 milliseconds = 472.67004
> hours, and 472 % 24 is 16 (and .67 is roughly 2/3 so 40ish minutes seems
> legit)
> Considering that multiple dialects catch these cases as invalid time strings
> for conversion, code should be updated to handle them as exceptions and the
> tests to be corrected to reflect this behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6092) Invalid test cases in CAST String to Time
[
https://issues.apache.org/jira/browse/CALCITE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerin John updated CALCITE-6092:
Description:
Encountered some
[tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238]
within SqlOperatorTest file for the CAST operator on String to Datetime
conversions, which are found to be invalid time strings on some tested
instances of DBs like BQ, MySql, Postgres.
It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but then
updated to verify conversion performed by the CAST operator (refer to JIRA
ticket: CALCITE-5554 and
[commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119])
Example test case (L1223):
The string '1241241' is being parsed as number of hours, and internal
conversion into milliseconds is done as {{1241241 * (int) MILLIS_PER_HOUR}}.
The resultant value is 1701612160 milliseconds = 472.67004 hours, and 472 %
24 is indeed 16 (and .67 is roughly 2/3 so 40ish minutes seems legit)
Considering that multiple dialects catch these cases as invalid time strings
for conversion, code should be updated to handle them as exceptions and the
tests to be corrected to reflect this behavior.
was:
Encountered some
[tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238]
within SqlOperatorTest file for the CAST operator on String to Datetime
conversions, which are found to be invalid time strings on some tested
instances of DBs like BQ, MySql, Postgres.
It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but then
updated to verify conversion performed by the CAST operator (refer to JIRA
ticket: CALCITE-5554 and
[commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119])
Example test case (L1223):
Considering that multiple dialects catch these cases as invalid time strings
for conversion, code should be updated to handle them as exceptions and the
tests to be corrected to reflect this behavior.
> Invalid test cases in CAST String to Time
> -
>
> Key: CALCITE-6092
> URL: https://issues.apache.org/jira/browse/CALCITE-6092
> Project: Calcite
> Issue Type: Bug
>Reporter: Jerin John
>Priority: Major
>
> Encountered some
> [tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238]
> within SqlOperatorTest file for the CAST operator on String to Datetime
> conversions, which are found to be invalid time strings on some tested
> instances of DBs like BQ, MySql, Postgres.
> It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but
> then updated to verify conversion performed by the CAST operator (refer to
> JIRA ticket: CALCITE-5554 and
> [commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119])
> Example test case (L1223):
> The string '1241241' is being parsed as number of hours, and internal
> conversion into milliseconds is done as {{1241241 * (int) MILLIS_PER_HOUR}}.
> The resultant value is 1701612160 milliseconds = 472.67004 hours, and 472
> % 24 is indeed 16 (and .67 is roughly 2/3 so 40ish minutes seems legit)
> Considering that multiple dialects catch these cases as invalid time strings
> for conversion, code should be updated to handle them as exceptions and the
> tests to be corrected to reflect this behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6092) Invalid test cases in CAST String to Time
[ https://issues.apache.org/jira/browse/CALCITE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerin John updated CALCITE-6092: Description: Encountered some [tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238] within SqlOperatorTest file for the CAST operator on String to Datetime conversions, which are found to be invalid time strings on some tested instances of DBs like BQ, MySql, Postgres. It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but then updated to verify conversion performed by the CAST operator (refer to JIRA ticket: CALCITE-5554 and [commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119]) Example test case (L1223): Considering that multiple dialects catch these cases as invalid time strings for conversion, code should be updated to handle them as exceptions and the tests to be corrected to reflect this behavior. was: Encountered some [tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238] within SqlOperatorTest file for the CAST operator on String to Datetime conversions, which are found to be invalid time strings on some tested instances of DBs like BQ, MySql, Postgres. It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but then updated to verify conversion performed by the CAST operator (refer to JIRA ticket: CALCITE-5554 and [commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119]) Considering that multiple dialects catch these cases as invalid time strings for conversion, code should be updated to handle them as exceptions and the tests to be corrected to reflect this behavior. > Invalid test cases in CAST String to Time > - > > Key: CALCITE-6092 > URL: https://issues.apache.org/jira/browse/CALCITE-6092 > Project: Calcite > Issue Type: Bug >Reporter: Jerin John >Priority: Major > > Encountered some > [tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238] > within SqlOperatorTest file for the CAST operator on String to Datetime > conversions, which are found to be invalid time strings on some tested > instances of DBs like BQ, MySql, Postgres. > It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but > then updated to verify conversion performed by the CAST operator (refer to > JIRA ticket: CALCITE-5554 and > [commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119]) > Example test case (L1223): > Considering that multiple dialects catch these cases as invalid time strings > for conversion, code should be updated to handle them as exceptions and the > tests to be corrected to reflect this behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6092) Invalid test cases in CAST String to Time
[ https://issues.apache.org/jira/browse/CALCITE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerin John updated CALCITE-6092: Description: Encountered some [tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238] within SqlOperatorTest file for the CAST operator on String to Datetime conversions, which are found to be invalid time strings on some tested instances of DBs like BQ, MySql, Postgres. It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but then updated to verify conversion performed by the CAST operator (refer to JIRA ticket: CALCITE-5554 and [commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119]) Considering that multiple dialects catch these cases as invalid time strings for conversion, code should be updated to handle them as exceptions and the tests to be corrected to reflect this behavior. was: Encountered some [tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238] within SqlOperatorTest file for the CAST operator on String to Datetime conversions, which are found to be invalid time strings on some tested instances of DBs like BQ, MySql, Postgres. It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but then updated to verify conversion performed by the CAST operator (refer to JIRA ticket: CALCITE-5554 and [commit)|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119] Considering that multiple dialects catch these cases as invalid time strings for conversion, code should be updated to handle them as exceptions and the tests to be corrected to reflect this behavior. > Invalid test cases in CAST String to Time > - > > Key: CALCITE-6092 > URL: https://issues.apache.org/jira/browse/CALCITE-6092 > Project: Calcite > Issue Type: Bug >Reporter: Jerin John >Priority: Major > > Encountered some > [tests|https://github.com/apache/calcite/blob/590ec85f0fcff7173c288c350c3f60e640976a34/testkit/src/main/java/org/apache/calcite/test/SqlOperatorTest.java#L1237-L1238] > within SqlOperatorTest file for the CAST operator on String to Datetime > conversions, which are found to be invalid time strings on some tested > instances of DBs like BQ, MySql, Postgres. > It seems these tests were originally ignored as `BAD_DATETIME_MESSAGE` but > then updated to verify conversion performed by the CAST operator (refer to > JIRA ticket: CALCITE-5554 and > [commit|https://github.com/apache/calcite/commit/625a2e03c4c5583279350bf04e3db2a31b1ec411#diff-fdd0c725fc7c6fd56965f59b1d51e4c7a9b5b5be27da2e54b8b8273dc980cd64R1118-R1119]) > Considering that multiple dialects catch these cases as invalid time strings > for conversion, code should be updated to handle them as exceptions and the > tests to be corrected to reflect this behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
