Skip to content

Conversation

@MaxGekk
Copy link
Member

@MaxGekk MaxGekk commented Feb 27, 2019

What changes were proposed in this pull request?

In the PR, I propose to add new Catalyst type converter for DateType. It should be able to convert java.time.LocalDate to/from DateType.

Main motivations for the changes:

  • Smoothly support Java 8 time API
  • Avoid inconsistency of calendars used inside of Spark 3.0 (Proleptic Gregorian calendar) and java.sql.Date (hybrid calendar - Julian + Gregorian).
  • Make conversion independent from current system timezone.

By default, Spark converts values of DateType to java.sql.Date instances but the SQL config spark.sql.datetime.java8API.enabled can change the behavior. If it is set to true, Spark uses java.time.LocalDate as external type for DateType.

How was this patch tested?

Added new testes to CatalystTypeConvertersSuite to check conversion of DateType to/from java.time.LocalDate, JavaUDFSuite/ UDFSuite to test usage of LocalDate type in Scala/Java UDFs.

@HeartSaVioR
Copy link
Contributor

Just FYI: in #23908 I'm proposing refactor of serializerFor so either this or #23908 may need to apply other's chance once other one gets merged first.

@MaxGekk
Copy link
Member Author

MaxGekk commented Feb 27, 2019

@HeartSaVioR I see, I will rebase.

@HeartSaVioR
Copy link
Contributor

Yeah if your patch gets in first I'll apply the change too. Thanks!

@SparkQA
Copy link

SparkQA commented Feb 28, 2019

Test build #102835 has finished for PR 23913 at commit 3ab2851.

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

@MaxGekk
Copy link
Member Author

MaxGekk commented Feb 28, 2019

@cloud-fan @HeartSaVioR Please, review the PR.

@cloud-fan
Copy link
Contributor

LGTM

@SparkQA
Copy link

SparkQA commented Feb 28, 2019

Test build #102862 has finished for PR 23913 at commit 86cd4a0.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Feb 28, 2019

Test build #102859 has finished for PR 23913 at commit 7fbf674.

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

@MaxGekk
Copy link
Member Author

MaxGekk commented Feb 28, 2019

jenkins, retest this, please

Copy link
Contributor

@HeartSaVioR HeartSaVioR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@SparkQA
Copy link

SparkQA commented Feb 28, 2019

Test build #102870 has finished for PR 23913 at commit 86cd4a0.

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

@cloud-fan
Copy link
Contributor

thanks, merging to master!

@HyukjinKwon
Copy link
Member

Nice, +1!

cloud-fan pushed a commit that referenced this pull request Mar 21, 2019
## What changes were proposed in this pull request?

In the PR, I propose to extend `Literal.apply` to support constructing literals of `TimestampType` and `DateType` from `java.time.Instant` and `java.time.LocalDate`. The java classes have been already supported as external types for `TimestampType` and `DateType` by the PRs #23811  and #23913.

## How was this patch tested?

Added new tests to `LiteralExpressionSuite`.

Closes #24161 from MaxGekk/literal-instant-localdate.

Authored-by: Maxim Gekk <[email protected]>
Signed-off-by: Wenchen Fan <[email protected]>
@MaxGekk MaxGekk deleted the date-localdate branch September 18, 2019 15:57
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.

5 participants