Skip to content

Conversation

@cloud-fan
Copy link
Contributor

a follow up of #7353

  1. we should use Calendar.HOUR_OF_DAY instead of Calendar.HOUR(this is for AM, PM).
  2. we should call c.set(Calendar.MILLISECOND, 0) after Calendar.getInstance

I'm not sure why the tests didn't fail in jenkins, but I ran latest spark master branch locally and DateTimeUtilsSuite failed.

@cloud-fan
Copy link
Contributor Author

cc @tarekauel @davies

@davies
Copy link
Contributor

davies commented Jul 17, 2015

LGTM

Copy link
Contributor

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.

Copy link
Contributor Author

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...

Copy link
Contributor

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?

Copy link
Contributor Author

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 == -1000000

In 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.

Copy link
Contributor

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.

@tarekbecker
Copy link
Contributor

LGTM

  1. yes that was a bug. Thanks for fixing it.
  2. see my comment.

@SparkQA
Copy link

SparkQA commented Jul 17, 2015

Test build #1096 has finished for PR 7473 at commit 66cdaf2.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds the following public classes (experimental):
    • logDebug("isMulticlass = " + metadata.isMulticlass)
    • * (i.e., if isMulticlass && isSpaceSufficientForAllCategoricalSplits),
    • logDebug("isMulticlass = " + metadata.isMulticlass)
    • abstract class UnsafeProjection extends Projection
    • case class FromUnsafeProjection(fields: Seq[DataType]) extends Projection
    • abstract class BaseProjection extends Projection
    • class SpecificProjection extends $
    • class SpecificProjection extends $

@SparkQA
Copy link

SparkQA commented Jul 17, 2015

Test build #37644 has finished for PR 7473 at commit 66cdaf2.

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

@asfgit asfgit closed this in 074085d Jul 17, 2015
@cloud-fan cloud-fan deleted the datetime branch July 18, 2015 02:12
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