Skip to content
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

[SPARK-32949][R][SQL] Add timestamp_seconds to SparkR #29822

Closed
wants to merge 1 commit into from

Conversation

zero323
Copy link
Member

@zero323 zero323 commented Sep 21, 2020

What changes were proposed in this pull request?

This PR adds R wrapper for timestamp_seconds function.

Why are the changes needed?

Feature parity.

Does this PR introduce any user-facing change?

Yes, it adds a new R function.

How was this patch tested?

New unit tests.

@SparkQA
Copy link

SparkQA commented Sep 21, 2020

Test build #128940 has finished for PR 29822 at commit 645f4c1.

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

@zero323 zero323 marked this pull request as ready for review September 21, 2020 17:10
Copy link
Member

@dongjoon-hyun dongjoon-hyun left a comment

Choose a reason for hiding this comment

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

+1, LGTM. Thank you, @zero323 .
Merged to master for Apache Spark 3.1.0 on December 2020.

Could you make a PR for the other functions of SPARK-31797?

Copy link
Member

@HyukjinKwon HyukjinKwon left a comment

Choose a reason for hiding this comment

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

LGTM too

@zero323
Copy link
Member Author

zero323 commented Sep 22, 2020

Thanks @dongjoon-hyun @HyukjinKwon

About that:

Could you make a PR for the other functions of SPARK-31797?

Do you meaning adding TIMESTAMP_{MILLIS|MICROS} for all supported APIs?

@dongjoon-hyun
Copy link
Member

dongjoon-hyun commented Sep 22, 2020

This PR aims the following. I thought you may want it. If you don't want, never mind. :)

### Why are the changes needed?

Feature parity.

@zero323
Copy link
Member Author

zero323 commented Sep 22, 2020

Wrapping all three was my initial intention, hence the question under another PR, but I see a merit in limiting language APIs to the commonly used functions (if that was the intention for not having a wrapper).

Personally I don't have strong opinion here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants