MaxGekk commented on a change in pull request #25981: [SPARK-28420][SQL]
Support the `INTERVAL` type in `date_part()`
URL: https://github.com/apache/spark/pull/25981#discussion_r332393344
##########
File path:
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/datetimeExpressions.scala
##########
@@ -2067,6 +2082,10 @@ object DatePart {
224
> SELECT _FUNC_('SECONDS', timestamp'2019-10-01 00:00:01.000001');
1.000001
+ > SELECT _FUNC_('days', interval 1 year 10 months 5 days);
Review comment:
> Shouldn't it be 30?
I agree with you that `seconds` should be `30`, `milliseconds` should be
`1`, and `microseconds` is `1` but PostgreSQL developers decided to implement
this in different way. Maybe this is because `seconds`, `milliseconds` are
always have the fractional part in other PostgreSQL functions.
For `seconds`, it looks reasonable but I don't know what PostgreSQL
developers thought of when they defined `milliseconds` as milliseconds in a
minute:
```sql
maxim=# select date_part('milliseconds', interval '30 seconds 1 milliseconds
1 microseconds');
date_part
-----------
30001.001
```
```sql
maxim=# select date_part('microseconds', interval '30 seconds 1 milliseconds
1 microseconds');
date_part
-----------
30001001
```
I interpret this as the `second`, `millisecond`, `microsecond` form one
interval component with values in the range `[0, 6000000)` where 0-1 digits
belongs to seconds, 2-4 digits to milliseconds, and 5-7 digits to microseconds.
Precisely follow PostgreSQL implementation is still open question for me. I
believe PostgreSQL has badly designed date-time API. As you can see similar
`date_part('HOUR', <interval>)` and `date_part('MILLISECONDS', <interval>)`
must have similar semantic but they don't.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
