[
https://issues.apache.org/jira/browse/IGNITE-25049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-25049:
--------------------------------------
Description:
This issue was previously reported in IGNITE-22250.
{{itSqlClientSynchronousApiTest.testTimeZoneId}} has ultra low flaky rate.
Fails with something like this
{noformat}
org.opentest4j.AssertionFailedError: expected: <1.74402188E12> but was:
<1.74402175E12>
at
app//org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.testTimeZoneId(ItSqlApiBaseTest.java:908)
{noformat}
This test tries to compare the value of {{CURRENT_TIMESTAMP}} across time
zones, and a possible reason for this failure is that the timestamp value
(long) is converted to a float to calculate the difference.
{code:java}
float tsMillis =
ts.atZone(ZoneId.systemDefault()).toInstant().toEpochMilli();
float nowMillis =
LocalDateTime.now(zoneId).atZone(ZoneId.systemDefault()).toInstant().toEpochMilli();
float deltaMillis = 5000;
assertEquals(nowMillis, tsMillis, deltaMillis);
{code}
We can easily find lot of timestamps that will not pass such check.
Example:
{code:java}
Instant ts1 = Instant.parse("2025-04-24T21:01:27.935Z");
Instant ts2 = ts1.plusMillis(1); // just 1 millisecond difference
float float1 = ts1.toEpochMilli();
float float2 = ts2.toEpochMilli();
System.out.println(Math.abs(float2 - float1)); // 131072.0
{code}
Test should be reworked similarly that we have in
testCurrentDateTimeTimeStamp.... or at least {{double}} should be used instead
of {{float}}.
was:
This issue was previously reported in IGNITE-22250.
{{itSqlClientSynchronousApiTest.testTimeZoneId}} has ultra low flaky rate.
But sometimes it fails with something like that
{noformat}
org.opentest4j.AssertionFailedError: expected: <1.74402188E12> but was:
<1.74402175E12>
at
app//org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.testTimeZoneId(ItSqlApiBaseTest.java:908)
{noformat}
This test tries to compare the value of {{CURRENT_TIMESTAMP}} across time
zones, and a possible reason for this failure is that the timestamp value
(long) is converted to a float to calculate the difference.
{code:java}
float tsMillis =
ts.atZone(ZoneId.systemDefault()).toInstant().toEpochMilli();
float nowMillis =
LocalDateTime.now(zoneId).atZone(ZoneId.systemDefault()).toInstant().toEpochMilli();
float deltaMillis = 5000;
assertEquals(nowMillis, tsMillis, deltaMillis);
{code}
We can easily find lot of timestamps that will not pass such check.
Example:
{code:java}
Instant ts1 = Instant.parse("2025-04-24T21:01:27.935Z");
Instant ts2 = ts1.plusMillis(1); // just 1 millisecond difference
float float1 = ts1.toEpochMilli();
float float2 = ts2.toEpochMilli();
System.out.println(Math.abs(float2 - float1)); // 131072.0
{code}
Test should be reworked similarly that we have in
testCurrentDateTimeTimeStamp.... or at least {{double}} should be used instead
of {{float}}.
> Sql. Improve itSqlClientSynchronousApiTest.testTimeZoneId test
> --------------------------------------------------------------
>
> Key: IGNITE-25049
> URL: https://issues.apache.org/jira/browse/IGNITE-25049
> Project: Ignite
> Issue Type: Bug
> Components: sql, thin client
> Reporter: Pavel Pereslegin
> Priority: Major
> Labels: ignite-3
>
> This issue was previously reported in IGNITE-22250.
> {{itSqlClientSynchronousApiTest.testTimeZoneId}} has ultra low flaky rate.
> Fails with something like this
> {noformat}
> org.opentest4j.AssertionFailedError: expected: <1.74402188E12> but was:
> <1.74402175E12>
> at
> app//org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.testTimeZoneId(ItSqlApiBaseTest.java:908)
> {noformat}
> This test tries to compare the value of {{CURRENT_TIMESTAMP}} across time
> zones, and a possible reason for this failure is that the timestamp value
> (long) is converted to a float to calculate the difference.
> {code:java}
> float tsMillis =
> ts.atZone(ZoneId.systemDefault()).toInstant().toEpochMilli();
> float nowMillis =
> LocalDateTime.now(zoneId).atZone(ZoneId.systemDefault()).toInstant().toEpochMilli();
> float deltaMillis = 5000;
> assertEquals(nowMillis, tsMillis, deltaMillis);
> {code}
> We can easily find lot of timestamps that will not pass such check.
> Example:
> {code:java}
> Instant ts1 = Instant.parse("2025-04-24T21:01:27.935Z");
> Instant ts2 = ts1.plusMillis(1); // just 1 millisecond difference
> float float1 = ts1.toEpochMilli();
> float float2 = ts2.toEpochMilli();
> System.out.println(Math.abs(float2 - float1)); // 131072.0
> {code}
> Test should be reworked similarly that we have in
> testCurrentDateTimeTimeStamp.... or at least {{double}} should be used
> instead of {{float}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
