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

SNOW-1032874: Fix an Overflow Issue for Integer-store Timestamp #673

Merged
merged 5 commits into from
Feb 5, 2024

Conversation

sfc-gh-tzhang
Copy link
Contributor

According to https://docs.snowflake.com/en/sql-reference/functions/to_timestamp#usage-notes:

  • If the integer is less than 31536000000 (the number of milliseconds in a year), then the value is treated as a number of seconds.
  • If the value is greater than or equal to 31536000000 and less than 31536000000000, then the value is treated as milliseconds.
  • If the value is greater than or equal to 31536000000000 and less than 31536000000000000, then the value is treated as microseconds.
  • If the value is greater than or equal to 31536000000000000, then the value is treated as nanoseconds.

Due to the multiplication logic in the code, we run into an overflow issue when the input is bigger than a certain value (for example: 31535999999999) and it causes silent corrupted values in the table, this change updates the code to use BigInteger instead of long to resolve the overflow issue.

@sfc-gh-tzhang sfc-gh-tzhang requested review from a team as code owners February 2, 2024 06:54
long val = Long.parseLong(input);

if (val > -SECONDS_LIMIT_FOR_EPOCH && val < SECONDS_LIMIT_FOR_EPOCH) {
epochNanos = BigInteger.valueOf(val).multiply(BigInteger.valueOf(Power10.intTable[9]));
Copy link
Contributor

Choose a reason for hiding this comment

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

nit, use Power10.sb16Table[9]

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated

Assert.assertEquals(123000000, wrapper.getFraction());
Assert.assertEquals(new BigInteger("1609462800123000000"), wrapper.toBinary(false));

// Test integer-stored time and scale guessing
SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we also need integration test coverage, which would test JDBC compatibility. We have a bunch of IT tests for scale guessing in DateTimeIT.java, just not for these edge cases. Could you add tests along the lines of these?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added

Copy link
Collaborator

@sfc-gh-japatel sfc-gh-japatel left a comment

Choose a reason for hiding this comment

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

lgtm! thank you

Copy link
Contributor

@sfc-gh-lsembera sfc-gh-lsembera left a comment

Choose a reason for hiding this comment

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

Thank you!

@sfc-gh-tzhang
Copy link
Contributor Author

Will merge this one first, we might need to update the logic again once we hear back from SQL folks about the behavior for negative timestamps.

@sfc-gh-tzhang sfc-gh-tzhang merged commit a9ed16d into master Feb 5, 2024
15 checks passed
@sfc-gh-tzhang sfc-gh-tzhang deleted the tzhang-si-overflow branch February 5, 2024 20:25
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.

4 participants