Skip to content

[CALCITE-6703] RelJson cannot handle timestamps prior to 1970-01-25 2…#4060

Merged
tanclary merged 1 commit intoapache:mainfrom
tanclary:6703-reljson
Nov 22, 2024
Merged

[CALCITE-6703] RelJson cannot handle timestamps prior to 1970-01-25 2…#4060
tanclary merged 1 commit intoapache:mainfrom
tanclary:6703-reljson

Conversation

@tanclary
Copy link
Contributor

…0:31:23.648

+ " }\n"
+ "}\n";

assertThatReadExpressionResult(timestampRepresentedAsInt, is("1970-01-25 15:30:00"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this supposed to work for dates before the epoch or the Gregorian calendar cutoff?
maybe you can add tests for these too - if they are not supposed to work, the errors can be tested.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the mechanism going from millis->timestamp String actually lives in DateTimeUtils in Avatica and is pretty well-tested in DateTimeUtilsTest (let me know if you need links.) The real bug here is that JSON doesn't distinguish the numeric types so we have to ensure it's a Long (or convert) it. So that's the scope I'm trying to test here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have approved, I leave to you this decision.

+ " }\n"
+ "}\n";
final String timestampRepresentedAsLong = "{\n"
+ " \"literal\": 3129400000,\n"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not easy to check that this value corresponds to the date below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I also wasn't sure about this.. the point I was trying to illustrate is that one case is below Integer.MAX_VALUE and the other is above, any suggestions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

putting this in a comment will help a bit - the purpose of this choice is clearer
but if you have validated this using other external means, like another DB, you can also mention it in a comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok i've added some comments

@tanclary tanclary force-pushed the 6703-reljson branch 3 times, most recently from 6a9be62 to 9a43fe6 Compare November 22, 2024 19:18
@sonarqubecloud
Copy link

@tanclary
Copy link
Contributor Author

@mihaibudiu have you seen the Windows failures like the ones on this PR before? They look unrelated but thought I'd ask?

@mihaibudiu
Copy link
Contributor

I have seen similar errors in windows builds, but not this many... they usually go away if you rerun the failed jobs.
Must be some problem with the build machines.

@tanclary tanclary merged commit 72e689e into apache:main Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants