-
Notifications
You must be signed in to change notification settings - Fork 13.9k
[FLINK-36941][docs] Update DATE_FORMAT Doc and Python Tests #25828
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -350,14 +350,21 @@ def temporal_overlaps(left_time_point, | |
| def date_format(timestamp, format) -> Expression: | ||
| """ | ||
| Formats a timestamp as a string using a specified format. | ||
| The format must be compatible with MySQL's date formatting syntax as used by the | ||
| date_parse function. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if this has been removed - do we not need to deprecate first before replacing?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @davidradl , the comment I deleted is not accurate. |
||
|
|
||
| For example `date_format(col("time"), "%Y, %d %M")` results in strings formatted as | ||
| "2017, 05 May". | ||
| Supported functions: | ||
| 1. date_format(TIMESTAMP, STRING) -> STRING | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we should mention the difference between the supported format strings. |
||
| Converts timestamp to a string, using a format string. | ||
| The format string is compatible with Java's DateTimeFormatter. | ||
| 2. date_format(STRING, STRING) -> STRING | ||
| Converts timestamp string, using a format string. | ||
| The format string is compatible with Java's SimpleDateFormat. | ||
|
|
||
| Example: | ||
| :: | ||
|
|
||
| >>> table.select(date_format(to_timestamp('2020-04-15'), "yyyy/MM/dd")) | ||
| >>> table.select(date_format("2020-04-15", "MM/dd/yyyy")) | ||
|
|
||
| :param timestamp: The timestamp to format as string. | ||
| :param format: The format of the string. | ||
| :return: The formatted timestamp as string. | ||
| """ | ||
| return _binary_op("dateFormat", timestamp, format) | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -299,6 +299,15 @@ def test_expressions(self): | |
| lit(2).hours))) | ||
| self.assertEqual("dateFormat(time, '%Y, %d %M')", | ||
| str(date_format(col("time"), "%Y, %d %M"))) | ||
| self.assertEqual("dateFormat(toTimestamp('1970-01-01 08:01:40'), 'yyyy-MM-dd HH:mm:ss')", | ||
| str(date_format(to_timestamp('1970-01-01 08:01:40'), | ||
| "yyyy-MM-dd HH:mm:ss"))) | ||
| self.assertEqual("DATE_FORMAT(TO_TIMESTAMP('1970-01-01 08:01:40.123456+02:00'), " | ||
| "'yyyy-MM-dd HH:mm:ss.SSSSSS z')", | ||
| str(date_format(to_timestamp('1970-01-01 08:01:40.123456+02:00'), | ||
| 'yyyy-MM-dd HH:mm:ss.SSSSSS z'))) | ||
| self.assertEqual("dateFormat('1970-01-01 08:01:40', 'yyyy-MM-dd HH:mm:ss')", | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. could you add a test with the format that the DateTimeFormatter could cope with - with precision and timezone
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi @davidradl , sure I can add that. |
||
| str(date_format("1970-01-01 08:01:40", "yyyy-MM-dd HH:mm:ss"))) | ||
| self.assertEqual("timestampDiff(DAY, cast('2016-06-15', DATE), cast('2016-06-18', DATE))", | ||
| str(timestamp_diff( | ||
| TimePointUnit.DAY, | ||
|
|
||
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.
Could we do the same for
UNIX_TIMESTAMP(string1[, string2])(https://github.com/apache/flink/pull/25828/files#diff-539fb22ee6aeee4cf07230bb4155500c6680c4cc889260e2c58bfa9d63fb7de5R662) please?flink/flink-table/flink-table-common/src/main/java/org/apache/flink/table/utils/DateTimeUtils.java
Line 1468 in 7fa4f78
flink/flink-table/flink-table-common/src/main/java/org/apache/flink/table/utils/DateTimeUtils.java
Line 960 in 7fa4f78
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.
Assuming I've read
flink/flink-table/flink-table-common/src/main/java/org/apache/flink/table/functions/BuiltInFunctionDefinitions.java
Line 2304 in 7fa4f78
unixTimestamp(dateStr, format, null)as there is notzthird parameter in the SQL function.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.
@nictownsend sounds like a reasonable idea, @snuyanzin @yiyutian1 if you agree we could raise this separately.
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.
Apologies, I hadn't appreciated the scope of the underlying Flink issue, happy to raise a new one if it's not appropriate to fix here
Uh oh!
There was an error while loading. Please reload this page.
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.
I have a slightly different thought
Since it is Flink 2.0 and anyway it brings some breaking changes. May be we can completely switch to DateTimeFormatter in 2.0 while for 1.19 and 1.20 we just fix documentation.
However this option requires a discussion in ML
i can start one if no objections
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.
@snuyanzin I like the idea.
Before that happens, should we fix the current doc?
If to only commit for 1.19 and 1.20, should I create PR against release-1.19 and release-1.20?