You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Dragoș Moldovan-Grünfeld (Jira)" <ji...@apache.org> on 2022/03/29 12:40:00 UTC
[jira] [Updated] (ARROW-16060) [C++] subtract_checked support for timestamp("s") and date32
[ https://issues.apache.org/jira/browse/ARROW-16060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dragoș Moldovan-Grünfeld updated ARROW-16060:
---------------------------------------------
Description:
This issue surfaced in R. Subtraction between a timestamp and a date only errors when the date is {{Date32}} and the {{timestamp}} is expressed in seconds.
While I understand the {{subtract kernel}} doesn't natively support operations between the various temporal types and some magic (aka implicit casting) is taking place (via {{DispatchBest}}), I think this is an unexpected behaviour. If date32 (expressed in days) cannot be converted into seconds, then I would expect all combinations of date32 and timestamp units to fail. I hope this makes sense.
Reprex:
{code:r}
a <- Array$create(as.Date("2022-03-25"))
b <- Array$create(as.POSIXct("2022-03-26"))
# it only errors when a is date32() and b is timestamp("s")
a$cast(date32()) - b$cast(timestamp("s"))
#> Error: NotImplemented: Function 'subtract_checked' has no kernel matching input types (array[date32[day]], array[timestamp[s]])
#> /Users/dragos/Documents/arrow/cpp/src/arrow/compute/function.cc:231 DispatchBest(&inputs)
# it works fine in all other cases
a$cast(date32()) - b$cast(timestamp("ms"))
#> Array
#> <duration[ms]>
#> [
#> -86400000
#> ]
a$cast(date32()) - b$cast(timestamp("us"))
#> Array
#> <duration[us]>
#> [
#> -86400000000
#> ]
a$cast(date32()) - b$cast(timestamp("ns"))
#> Array
#> <duration[ns]>
#> [
#> -86400000000000
#> ]
# a is date64() and b is timestamp()
a$cast(date64()) - b$cast(timestamp("s"))
#> Array
#> <duration[ms]>
#> [
#> -86400000
#> ]
a$cast(date64()) - b$cast(timestamp("ms"))
#> Array
#> <duration[ms]>
#> [
#> -86400000
#> ]
a$cast(date64()) - b$cast(timestamp("us"))
#> Array
#> <duration[us]>
#> [
#> -86400000000
#> ]
a$cast(date64()) - b$cast(timestamp("ns"))
#> Array
#> <duration[ns]>
#> [
#> -86400000000000
#> ]
{code}
was:
This issue surfaced in R. Subtraction between a timestamp and a date only errors when the date is date32 and the timestamp is expressed in seconds.
While I understand the {{subtract kernel}} doesn't natively support operations between the various temporal types and some magic (aka implicit casting) is taking place (via {{DispatchBest}}), I think this is an unexpected behaviour. If date32 (expressed in days) cannot be converted into seconds, then I would expect all combinations of date32 and timestamp units to fail. I hope this makes sense.
Reprex:
{code:r}
a <- Array$create(as.Date("2022-03-25"))
b <- Array$create(as.POSIXct("2022-03-26"))
# it only errors when a is date32() and b is timestamp("s")
a$cast(date32()) - b$cast(timestamp("s"))
#> Error: NotImplemented: Function 'subtract_checked' has no kernel matching input types (array[date32[day]], array[timestamp[s]])
#> /Users/dragos/Documents/arrow/cpp/src/arrow/compute/function.cc:231 DispatchBest(&inputs)
# it works fine in all other cases
a$cast(date32()) - b$cast(timestamp("ms"))
#> Array
#> <duration[ms]>
#> [
#> -86400000
#> ]
a$cast(date32()) - b$cast(timestamp("us"))
#> Array
#> <duration[us]>
#> [
#> -86400000000
#> ]
a$cast(date32()) - b$cast(timestamp("ns"))
#> Array
#> <duration[ns]>
#> [
#> -86400000000000
#> ]
# a is date64() and b is timestamp()
a$cast(date64()) - b$cast(timestamp("s"))
#> Array
#> <duration[ms]>
#> [
#> -86400000
#> ]
a$cast(date64()) - b$cast(timestamp("ms"))
#> Array
#> <duration[ms]>
#> [
#> -86400000
#> ]
a$cast(date64()) - b$cast(timestamp("us"))
#> Array
#> <duration[us]>
#> [
#> -86400000000
#> ]
a$cast(date64()) - b$cast(timestamp("ns"))
#> Array
#> <duration[ns]>
#> [
#> -86400000000000
#> ]
{code}
> [C++] subtract_checked support for timestamp("s") and date32
> ------------------------------------------------------------
>
> Key: ARROW-16060
> URL: https://issues.apache.org/jira/browse/ARROW-16060
> Project: Apache Arrow
> Issue Type: Bug
> Components: C++
> Reporter: Dragoș Moldovan-Grünfeld
> Priority: Critical
>
> This issue surfaced in R. Subtraction between a timestamp and a date only errors when the date is {{Date32}} and the {{timestamp}} is expressed in seconds.
> While I understand the {{subtract kernel}} doesn't natively support operations between the various temporal types and some magic (aka implicit casting) is taking place (via {{DispatchBest}}), I think this is an unexpected behaviour. If date32 (expressed in days) cannot be converted into seconds, then I would expect all combinations of date32 and timestamp units to fail. I hope this makes sense.
> Reprex:
> {code:r}
> a <- Array$create(as.Date("2022-03-25"))
> b <- Array$create(as.POSIXct("2022-03-26"))
> # it only errors when a is date32() and b is timestamp("s")
> a$cast(date32()) - b$cast(timestamp("s"))
> #> Error: NotImplemented: Function 'subtract_checked' has no kernel matching input types (array[date32[day]], array[timestamp[s]])
> #> /Users/dragos/Documents/arrow/cpp/src/arrow/compute/function.cc:231 DispatchBest(&inputs)
> # it works fine in all other cases
> a$cast(date32()) - b$cast(timestamp("ms"))
> #> Array
> #> <duration[ms]>
> #> [
> #> -86400000
> #> ]
> a$cast(date32()) - b$cast(timestamp("us"))
> #> Array
> #> <duration[us]>
> #> [
> #> -86400000000
> #> ]
> a$cast(date32()) - b$cast(timestamp("ns"))
> #> Array
> #> <duration[ns]>
> #> [
> #> -86400000000000
> #> ]
> # a is date64() and b is timestamp()
> a$cast(date64()) - b$cast(timestamp("s"))
> #> Array
> #> <duration[ms]>
> #> [
> #> -86400000
> #> ]
> a$cast(date64()) - b$cast(timestamp("ms"))
> #> Array
> #> <duration[ms]>
> #> [
> #> -86400000
> #> ]
> a$cast(date64()) - b$cast(timestamp("us"))
> #> Array
> #> <duration[us]>
> #> [
> #> -86400000000
> #> ]
> a$cast(date64()) - b$cast(timestamp("ns"))
> #> Array
> #> <duration[ns]>
> #> [
> #> -86400000000000
> #> ]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)