[
https://issues.apache.org/jira/browse/ARROW-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511237#comment-17511237
]
Joris Van den Bossche edited comment on ARROW-15996 at 3/23/22, 1:01 PM:
-------------------------------------------------------------------------
I suppose a division might only be needed if you directly want a specific unit?
If you take the unit that matches the resolution of the time32/time64, I don't
think a division is needed:
{code}
In [9]: pa.array([1, 2], pa.time32('s'))
Out[9]:
<pyarrow.lib.Time32Array object at 0x7fc37dd5de80>
[
00:00:01,
00:00:02
]
In [10]: pa.array([1, 2],
pa.time32('s')).cast(pa.int32()).cast(pa.int64()).cast(pa.duration('s'))
Out[10]:
<pyarrow.lib.DurationArray object at 0x7fc37dd061c0>
[
1,
2
]
In [11]: pa.array([1, 2], pa.time64('us'))
Out[11]:
<pyarrow.lib.Time64Array object at 0x7fc37db8be80>
[
00:00:00.000001,
00:00:00.000002
]
In [12]: pa.array([1, 2],
pa.time64('us')).cast(pa.int64()).cast(pa.duration('us'))
Out[12]:
<pyarrow.lib.DurationArray object at 0x7fc37dbe5880>
[
1,
2
]
{code}
It's true that you get a chain of casting, but I think otherwise that would
happen under the hood as well. And this is meant to be done internally in the R
bindings, and not by the end user?
(to be clear, I am not really opposed enabling such a cast on the C++ level, I
can see it being useful for python as well, but just want to point out that it
should be easy to already workaround this in the R bindings right now)
was (Author: jorisvandenbossche):
I suppose a division might only be needed if you directly want a specific unit?
If you take the unit that matches the resolution of the time32/time64, I don't
think a division is needed:
{code}
In [9]: pa.array([1, 2], pa.time32('s'))
Out[9]:
<pyarrow.lib.Time32Array object at 0x7fc37dd5de80>
[
00:00:01,
00:00:02
]
In [10]: pa.array([1, 2],
pa.time32('s')).cast(pa.int32()).cast(pa.int64()).cast(pa.duration('s'))
Out[10]:
<pyarrow.lib.DurationArray object at 0x7fc37dd061c0>
[
1,
2
]
In [11]: pa.array([1, 2], pa.time64('us'))
Out[11]:
<pyarrow.lib.Time64Array object at 0x7fc37db8be80>
[
00:00:00.000001,
00:00:00.000002
]
In [12]: pa.array([1, 2],
pa.time64('us')).cast(pa.int64()).cast(pa.duration('us'))
Out[12]:
<pyarrow.lib.DurationArray object at 0x7fc37dbe5880>
[
1,
2
]
{code}
It's true that you get a chain of casting, but I think otherwise that would
happen under the hood as well. And this is meant to be done internally in the R
bindings, and not by the end user?
> [C++] Support casting from time32 and time64 to duration
> --------------------------------------------------------
>
> Key: ARROW-15996
> URL: https://issues.apache.org/jira/browse/ARROW-15996
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++
> Reporter: Dragoș Moldovan-Grünfeld
> Priority: Critical
>
> It would be really helpful if we could convert {{time32}} and {{time64}} to
> {{duration}}. For example, it could simplify the implementation of some of
> the R bindings (e.g. {{difftime}}).
> {code:r}
> library(arrow, warn.conflicts = FALSE)
> a <- Array$create(32000L)
> a
> #> Array
> #> <int32>
> #> [
> #> 32000
> #> ]
> a$cast(time32())
> #> Array
> #> <time32[ms]>
> #> [
> #> 00:00:32.000
> #> ]
> a$cast(int64())$cast(time64())
> #> Array
> #> <time64[ns]>
> #> [
> #> 00:00:00.000032000
> #> ]
> a$cast(time32())$cast(duration())
> #> Error: NotImplemented: Unsupported cast from time32[ms] to duration using
> function cast_duration
> a$cast(int64())$cast(time64())$cast(duration())
> #> Error: NotImplemented: Unsupported cast from time64[ns] to duration using
> function cast_duration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
