-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Conversation
It looks like @mmolimar hasn't signed our Contributor License Agreement, yet.
You can read and sign our full Contributor License Agreement here. Once you've signed reply with Appreciation of efforts, clabot |
[clabot:check] |
@confluentinc It looks like @mmolimar just signed our Contributor License Agreement. 👍 Always at your service, clabot |
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. |
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.
Looks good, just a few doc suggestions.
Totally agree @spena. On the other hand, we have other functions such as |
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.
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.
ksql-engine/src/main/java/io/confluent/ksql/function/udf/datetime/CurrentTimestamp.java
Outdated
Show resolved
Hide resolved
ksql-engine/src/test/java/io/confluent/ksql/function/udf/datetime/CurrentTimestampTest.java
Outdated
Show resolved
Hide resolved
@mmolimar @hjafarpour I did not find a Btw, I came to this problem: 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. |
@hjafarpour @spena I renamed the function |
@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 | |
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.
Suggest: "The returned timestamp may differ depending on the local time of different KSQL Server instances."
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.
Done
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.
LGTM, with one suggestion.
…ature-datetimefn
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.
LGTM with one suggestion.
// Given: | ||
final long before = System.currentTimeMillis(); | ||
|
||
// When: |
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.
It would be good if you refactor the code so that you could mock the timestamp generation and make the tests more deterministic.
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.
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)
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.
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
ksql-engine/src/main/java/io/confluent/ksql/function/udf/datetime/UnixTimestamp.java
Outdated
Show resolved
Hide resolved
// Given: | ||
final long before = System.currentTimeMillis(); | ||
|
||
// When: |
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.
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)
Totally agree @big-andy-coates |
Brilliant - thanks @mmolimar. Really appreciate your contribution. Will merge once build is green. |
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.
LGTM
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