-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add allowOverflow flag to Timestamp::toTimezone #9836
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -898,6 +898,15 @@ TEST_F(DateTimeFunctionsTest, fromUnixtime) { | |
|
||
// 8 hours ahead UTC. | ||
setQueryTimeZone("Asia/Shanghai"); | ||
NEUpanning marked this conversation as resolved.
Show resolved
Hide resolved
|
||
// In debug mode, Timestamp constructor will throw exception if range check | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a deeper problem here that Timestamp cannot represent values representable in Spark? If not, then, perhaps there is some issue with the implementation where it attempts to create an "invalid" Timestamp. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Presto's Timestamp is stored in one 64-bit signed integer for milliseconds, but Spark's Timestamp is stored in 64-bit signed integer for seconds, so this test attempts to create an "invalid" Timestamp. Maybe we should remove the range check for Timestamp since it's also used by Spark now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be nice to follow-up on that. CC: @rui-mo There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will work on it when i have time. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @NEUpanning Do we need to create an issue to track this follow-up? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
// fails. | ||
#ifdef NDEBUG | ||
// Integer overflow in the internal conversion from seconds to milliseconds. | ||
EXPECT_EQ( | ||
fromUnixTime(std::numeric_limits<int64_t>::max(), "yyyy-MM-dd HH:mm:ss"), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The example in the documentation shows a different result: https://facebookincubator.github.io/velox/functions/spark/datetime.html#from_unixtime
Which one is the "right" one? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Both are right. The example in the documentation doesn't set query time zone configuration, but this test sets time zone to "Asia/Shanghai" , so the results are different. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe we should add another example in document for query with time zone. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added example in document : 59968ef |
||
"1970-01-01 07:59:59"); | ||
NEUpanning marked this conversation as resolved.
Show resolved
Hide resolved
|
||
#endif | ||
|
||
EXPECT_EQ(fromUnixTime(0, "yyyy-MM-dd HH:mm:ss"), "1970-01-01 08:00:00"); | ||
EXPECT_EQ(fromUnixTime(120, "yyyy-MM-dd HH:mm"), "1970-01-01 08:02"); | ||
EXPECT_EQ(fromUnixTime(-59, "yyyy-MM-dd HH:mm:ss"), "1970-01-01 07:59:01"); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to include all 3 queries above, but in this time zone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. See 15e85ed