[ 
https://issues.apache.org/jira/browse/ARROW-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419443#comment-17419443
 ] 

Weston Pace commented on ARROW-14108:
-------------------------------------

I was basing my understanding of ARROW-13548 on SQL's DATEDIFF (which requires 
you to specify a time unit and only returns an integer).  I see now the 
month_day_nano between which is very cool.

In a certain sense this is not needed for full postgres compatibility.  A user 
that want's that behavior can just grab a duration from two timestamptz objects 
and do the math themselves.  However, it would make postgres compatibility much 
easier.

That being said, isn't this just another flavor of the extraction kernels?  It 
can be day_nano_between.

It's hard to say one is more canonical than the other when someone could also 
presumably ask for year_month_day_nano_between.


> [C++] interval_between(timestamptz, timestamptz) -> interval kernel
> -------------------------------------------------------------------
>
>                 Key: ARROW-14108
>                 URL: https://issues.apache.org/jira/browse/ARROW-14108
>             Project: Apache Arrow
>          Issue Type: Sub-task
>            Reporter: Weston Pace
>            Priority: Major
>
> Given two timestamps that each have time zones this function should return an 
> interval from the first timestamp to the second timestamp according to the 
> following rules (postgres rules):
> * 1 day is 24 physical hours (which may not exactly equal 1 calendar day).
> * Intervals returned will never contain a months/years field
> Examples:
> interval_between('2021-03-14 00:00:00 America/Denver', '2021-03-15 00:00:00 
> America/Denver') => { "hours": 23 }
> interval_between('2021-03-14 00:00:00 UTC', '2021-03-15 00:00:00 UTC') => { 
> "days": 1}
> interval_between('2021-03-14 00:00:00 UTC', '2020-03-14 00:00:00 UTC') => { 
> "days": 365}
> If the first timestamp is larger than the second timestamp then the interval 
> will be negative.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to