-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-30925][SQL] Prevent overflow/round errors in conversions of milliseconds to/from microseconds #27676
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
Conversation
|
Test build #118820 has finished for PR 27676 at commit
|
|
Test build #118828 has finished for PR 27676 at commit
|
|
Test build #118829 has finished for PR 27676 at commit
|
|
jenkins, retest this, please |
|
Test build #118830 has finished for PR 27676 at commit
|
|
thanks, merging to master/3.0! |
…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]>
|
Is it a behavior change? |
@gatorsmile Yes, this can change results but previous behavior is wrong, most likely. |
…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]>
What changes were proposed in this pull request?
Math.multiplyExact()inDateTimeUtils.fromMillis()to prevent silent overflow in conversion milliseconds to microseconds.DateTimeUtils.fromMillis()in all places where milliseconds are converted to microsecondsDateTimeUtils.toMillis()in all places where microseconds are converted to millisecondsWhy are the changes needed?
fromMillis(). Instead of it,new ArithmeticException("long overflow")will be thrown, and handled accordantly.1965-01-01 10:11:12.123456is represented as-157700927876544in micro precision. In milliseconds precision the above needs to be represented as-157700927877or1965-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