Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
Nov 22, 2024

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
Copy link

sonarcloud bot commented Nov 22, 2024

@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
16 of 19 checks passed
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