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

feat: New UNIX_TIMESTAMP and UNIX_DATE datetime functions #2459

Merged
merged 13 commits into from
Jun 27, 2019

Conversation

mmolimar
Copy link
Contributor

@mmolimar mmolimar commented Feb 20, 2019

Description

This PR adds two new datetime functions: UNIX_TIMESTAMP and UNIX_DATE.
The issue related with this is #2412 by @rmoff.

Testing done

Added new unit tests

Reviewer checklist

  • Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
  • Ensure relevant issues are linked (description should include text like "Fixes #")

@mmolimar mmolimar requested review from JimGalasyn and a team as code owners February 20, 2019 06:09
@ghost
Copy link

ghost commented Feb 20, 2019

It looks like @mmolimar hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement here.

Once you've signed reply with [clabot:check] to prove it.

Appreciation of efforts,

clabot

@mmolimar
Copy link
Contributor Author

[clabot:check]

@ghost
Copy link

ghost commented Feb 20, 2019

@confluentinc It looks like @mmolimar just signed our Contributor License Agreement. 👍

Always at your service,

clabot

@spena
Copy link
Member

spena commented Feb 20, 2019

Thanks @mmolimar for the patch. I was looking at other SQL systems, and all of them use a CURRENT_DATE and CURRENT_TIMESTAMP functions and return different results other than a number. Should we follow the same standard?

Btw, I think it is useful to return a DATE and TIMESTAMP data types (like other SQL do) to allow for date/time calculations but KSQL does not support those types yet. Would it be useful to have those first?

If you want to return a timestamp number instead for current date/time support, perhaps having a different UDF name would be ideal? So we don't have compatibility troubles in the future if we want to use these UDF to return date/time types.

For instance, Apache Hive has a unix_timestamp() that returns an integer.

Copy link
Member

@JimGalasyn JimGalasyn left a comment

Choose a reason for hiding this comment

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

Looks good, just a few doc suggestions.

@mmolimar
Copy link
Contributor Author

Totally agree @spena.
In case of CURRENTTIMESTAMP, I could rename it to UNIXTIMESTAMP (btw, with underscores? Following the pattern in other functions, most of them don't have it), but what about the CURRENTDATE?

On the other hand, we have other functions such as STRINGTOTIMESTAMP or STRINGTODATE in which the thing related with the data type happens too. That's why I implemented those functions in the same way so, what do you say?

Copy link
Contributor

@hjafarpour hjafarpour left a comment

Choose a reason for hiding this comment

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

Thanks for the PR, @mmolimar.
I agree with @spena 's suggestion on the name. Also since currently we don't have DATE and TIME types in KSQL, so these UDFs don't have to follow the semantics of the other SQL systems.
One important point to add to the documentation is to clarify that the returned time is from the local KSQL server and if we a cluster with more than one server the local time for the servers may not be synchronized.

@spena
Copy link
Member

spena commented Mar 8, 2019

@mmolimar @hjafarpour I did not find a current_date() function in any SQL database, however, I wonder what would be the difference between current_timestamp (or unix_timestamp) and current_date? I think a user can get the # of days based on the value of unix_timestamp(), right? They can get the difference between unix_timestamp() - epoc and calculate the days if necessary.

Btw, I came to this problem:
SELECT c1 + unix_timestamp(), c2 + unix_timestamp() FROM t1;

Would both unix_timestamp() return different timestamp values? If the idea is to add the current timestamp to those columns, then one column might be a few milliseconds greater than the other. Some systems do return the same timestamp value in the same query to avoid such problem.

It's hard to test this in Mysql because it is too fast and I always get the same values, but in KSQL there might be operations in the query that would make the next timestamp to be different.

@mmolimar
Copy link
Contributor Author

mmolimar commented Mar 15, 2019

@hjafarpour @spena I renamed the function CURRENTTIMESTAMP to UNIX_TIMESTAMP as suggested.
On the other hand, I did find the current_date function, for instance, in MySQL and PostgreSQL so, what do you think?

@HLmohammed
Copy link

HLmohammed commented Apr 25, 2019

@JimGalasyn , @mmolimar , waiting on these functions to be merged bigtime. Hope it happens soon.

| | | ``java.util.TimeZone`` ID format, for example: |
| | | "UTC", "America/Los_Angeles", "PDT", |
| | | "Europe/London". |
| | | Notice that the returned timestamp might be |
Copy link
Member

@JimGalasyn JimGalasyn Apr 25, 2019

Choose a reason for hiding this comment

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

Suggest: "The returned timestamp may differ depending on the local time of different KSQL Server instances."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Copy link
Member

@JimGalasyn JimGalasyn left a comment

Choose a reason for hiding this comment

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

LGTM, with one suggestion.

@vcrfxia vcrfxia requested review from spena, hjafarpour and a team and removed request for hjafarpour May 7, 2019 20:51
Copy link
Contributor

@hjafarpour hjafarpour left a comment

Choose a reason for hiding this comment

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

LGTM with one suggestion.

// Given:
final long before = System.currentTimeMillis();

// When:
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be good if you refactor the code so that you could mock the timestamp generation and make the tests more deterministic.

Copy link
Contributor

@big-andy-coates big-andy-coates Jun 19, 2019

Choose a reason for hiding this comment

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

Normally I'd agree, but in this case if we change the test to inject the time we're not really testing the class anymore, given its sole purpose is to provide the time!

(Note, this is in response to @hjafarpour's comment above)

Copy link
Contributor

@big-andy-coates big-andy-coates left a comment

Choose a reason for hiding this comment

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

Thanks @mmolimar, really appreciate you taking the time to add this in.

However, as I've commented below, I don't think it makes sense to have a timezone parameter on the UNIX_TIMESTAMP function, as the timestamp is independent of any tz.

If we can clear this up I think we can get this merged.

Thanks

docs/developer-guide/syntax-reference.rst Outdated Show resolved Hide resolved
docs/developer-guide/syntax-reference.rst Outdated Show resolved Hide resolved
// Given:
final long before = System.currentTimeMillis();

// When:
Copy link
Contributor

@big-andy-coates big-andy-coates Jun 19, 2019

Choose a reason for hiding this comment

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

Normally I'd agree, but in this case if we change the test to inject the time we're not really testing the class anymore, given its sole purpose is to provide the time!

(Note, this is in response to @hjafarpour's comment above)

@mmolimar
Copy link
Contributor Author

Totally agree @big-andy-coates
Changes done!

@big-andy-coates
Copy link
Contributor

big-andy-coates commented Jun 27, 2019

Brilliant - thanks @mmolimar. Really appreciate your contribution. Will merge once build is green.

Copy link
Contributor

@big-andy-coates big-andy-coates left a comment

Choose a reason for hiding this comment

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

LGTM

@vcrfxia vcrfxia changed the title New CURRENTIMESTAMP and CURRENTDATE datetime functions feat: New CURRENTIMESTAMP and CURRENTDATE datetime functions Jun 27, 2019
@vcrfxia vcrfxia changed the title feat: New CURRENTIMESTAMP and CURRENTDATE datetime functions feat: New UNIX_TIMESTAMP and UNIX_DATE datetime functions Jun 27, 2019
@vcrfxia vcrfxia merged commit 39ce7f4 into confluentinc:master Jun 27, 2019
@vcrfxia vcrfxia added this to the 5.4 milestone Jul 18, 2019
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.

None yet

7 participants