Skip to content

Conversation

@MaxGekk
Copy link
Member

@MaxGekk MaxGekk commented Feb 22, 2020

What changes were proposed in this pull request?

  • Use Math.multiplyExact() in DateTimeUtils.fromMillis() to prevent silent overflow in conversion milliseconds to microseconds.
  • Use DateTimeUtils.fromMillis() in all places where milliseconds are converted to microseconds
  • Use DateTimeUtils.toMillis() in all places where microseconds are converted to milliseconds

Why are the changes needed?

  1. To prevent silent arithmetic overflow while multiplying by 1000 in fromMillis(). Instead of it, new ArithmeticException("long overflow") will be thrown, and handled accordantly.
  2. To correctly round microseconds in conversion to milliseconds. For example, 1965-01-01 10:11:12.123456 is represented as -157700927876544 in micro precision. In milliseconds precision the above needs to be represented as -157700927877 or 1965-01-01 10:11:12.123.

Does this PR introduce any user-facing change?

Yes

How was this patch tested?

By TimestampFormatterSuite, CastSuite, DateExpressionsSuite, IntervalExpressionsSuite, ExpressionParserSuite, ExpressionParserSuite, DateTimeUtilsSuite, IntervalUtilsSuite

@SparkQA
Copy link

SparkQA commented Feb 23, 2020

Test build #118820 has finished for PR 27676 at commit 561911a.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Feb 23, 2020

Test build #118828 has finished for PR 27676 at commit 52234d6.

  • This patch fails due to an unknown error code, -9.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Feb 23, 2020

Test build #118829 has finished for PR 27676 at commit 8179c16.

  • This patch fails due to an unknown error code, -9.
  • This patch merges cleanly.
  • This patch adds no public classes.

@MaxGekk
Copy link
Member Author

MaxGekk commented Feb 23, 2020

jenkins, retest this, please

@MaxGekk MaxGekk changed the title [WIP][SQL] Prevent overflow in conversions of milliseconds to/from microseconds [WIP][SQL] Prevent overflow/round errors in conversions of milliseconds to/from microseconds Feb 23, 2020
@MaxGekk MaxGekk changed the title [WIP][SQL] Prevent overflow/round errors in conversions of milliseconds to/from microseconds [SPARK-30925][SQL] Prevent overflow/round errors in conversions of milliseconds to/from microseconds Feb 23, 2020
@MaxGekk MaxGekk requested a review from cloud-fan February 23, 2020 09:04
@SparkQA
Copy link

SparkQA commented Feb 23, 2020

Test build #118830 has finished for PR 27676 at commit 8179c16.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@cloud-fan cloud-fan closed this in c41ef39 Feb 24, 2020
@cloud-fan
Copy link
Contributor

thanks, merging to master/3.0!

cloud-fan pushed a commit that referenced this pull request Feb 24, 2020
…lliseconds to/from microseconds

### What changes were proposed in this pull request?
- Use `Math.multiplyExact()` in `DateTimeUtils.fromMillis()` to prevent silent overflow in conversion milliseconds to microseconds.
- Use `DateTimeUtils.fromMillis()` in all places where milliseconds are converted to microseconds
- Use `DateTimeUtils.toMillis()` in all places where microseconds are converted to milliseconds

### Why are the changes needed?

1. To prevent silent arithmetic overflow while multiplying by 1000 in `fromMillis()`. Instead of it, `new ArithmeticException("long overflow")` will be thrown, and handled accordantly.
2. To correctly round microseconds in conversion to milliseconds. For example, `1965-01-01 10:11:12.123456` is represented as `-157700927876544` in micro precision. In milliseconds precision the above needs to be represented as `-157700927877` or `1965-01-01 10:11:12.123`.

### Does this PR introduce any user-facing change?
Yes

### How was this patch tested?
By `TimestampFormatterSuite`, `CastSuite`, `DateExpressionsSuite`, `IntervalExpressionsSuite`, `ExpressionParserSuite`, `ExpressionParserSuite`, `DateTimeUtilsSuite`, `IntervalUtilsSuite`

Closes #27676 from MaxGekk/millis-2-micros-overflow.

Authored-by: Maxim Gekk <[email protected]>
Signed-off-by: Wenchen Fan <[email protected]>
(cherry picked from commit c41ef39)
Signed-off-by: Wenchen Fan <[email protected]>
@gatorsmile
Copy link
Member

Is it a behavior change?

@MaxGekk
Copy link
Member Author

MaxGekk commented Feb 26, 2020

Is it a behavior change?

@gatorsmile Yes, this can change results but previous behavior is wrong, most likely.

sjincho pushed a commit to sjincho/spark that referenced this pull request Apr 15, 2020
…lliseconds to/from microseconds

### What changes were proposed in this pull request?
- Use `Math.multiplyExact()` in `DateTimeUtils.fromMillis()` to prevent silent overflow in conversion milliseconds to microseconds.
- Use `DateTimeUtils.fromMillis()` in all places where milliseconds are converted to microseconds
- Use `DateTimeUtils.toMillis()` in all places where microseconds are converted to milliseconds

### Why are the changes needed?

1. To prevent silent arithmetic overflow while multiplying by 1000 in `fromMillis()`. Instead of it, `new ArithmeticException("long overflow")` will be thrown, and handled accordantly.
2. To correctly round microseconds in conversion to milliseconds. For example, `1965-01-01 10:11:12.123456` is represented as `-157700927876544` in micro precision. In milliseconds precision the above needs to be represented as `-157700927877` or `1965-01-01 10:11:12.123`.

### Does this PR introduce any user-facing change?
Yes

### How was this patch tested?
By `TimestampFormatterSuite`, `CastSuite`, `DateExpressionsSuite`, `IntervalExpressionsSuite`, `ExpressionParserSuite`, `ExpressionParserSuite`, `DateTimeUtilsSuite`, `IntervalUtilsSuite`

Closes apache#27676 from MaxGekk/millis-2-micros-overflow.

Authored-by: Maxim Gekk <[email protected]>
Signed-off-by: Wenchen Fan <[email protected]>
@MaxGekk MaxGekk deleted the millis-2-micros-overflow branch June 5, 2020 19:46
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