-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-9136][SQL] fix several bugs in DateTimeUtils.stringToTimestamp #7473
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
|
cc @tarekauel @davies |
|
LGTM |
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.
I don't know why you have changed this. I divided by 1000 first in order to remove the call of c.set(Calendar.MILLISECOND, 0) in Line 323. But I am fine with this, I guess it's a personal preference.
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.
divide by 1000 is not right when c.getTimeInMillis is negative.
I'm really confused why jenkins didn't report test error for this case...
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.
Sorry I didn't get this. Why is divide by 1000 a problem, if the date is before 1.1.1970? It's a long value and the last three digits are the millis. In order to cut them off, I divide by 1000. This has no impact on the sign or anything else, does it?
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.
Let's say now is a second before 1970-1-1:
val c = Calendar.getInstance(TimeZone.getTimeZone("GMT"))
c.set(1969, 11, 31, 23, 59, 59)
c.getTimeInMillis // something bigger than -1000, maybe -700
c.getTimeInMillis / 1000 * 1000000 == 0
c.set(Calendar.MILLISECOND, 0)
c.getTimeInMillis // exactly -1000
c.getTimeInMillis * 1000 == -1000000In the test case we were testing "1969-12-31 16:00:00", so if the time zone in jenkins test environment is less than GMT-8, c.getTimeInMillis will be positive and this bug will be hidden.
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.
Got it! Thanks for the explanation.
|
LGTM
|
|
Test build #1096 has finished for PR 7473 at commit
|
|
Test build #37644 has finished for PR 7473 at commit
|
a follow up of #7353
Calendar.HOUR_OF_DAYinstead ofCalendar.HOUR(this is for AM, PM).c.set(Calendar.MILLISECOND, 0)afterCalendar.getInstanceI'm not sure why the tests didn't fail in jenkins, but I ran latest spark master branch locally and
DateTimeUtilsSuitefailed.