[
https://issues.apache.org/jira/browse/ARROW-15798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499115#comment-17499115
]
Rok Mihevc commented on ARROW-15798:
------------------------------------
Yeah, I think your suggestion is valid. We can use temporal subtract kernel:
`subtract(timestamp, subtract(1970-01-01 - origin))`. This is pretty harmless
and clean.
However maybe there are cases in lubridate where origin of a timestamp changes
output of a function? I don't know how common origin is in lubridate, but I see
it is in clock where [e.g. flooring uses
it|https://clock.r-lib.org/articles/recipes.html#flooring-by-days]. Do we know
of such things in lubridate?
> [R][C++] Discussion: Plans for date casting from int to support an origin
> option?
> ---------------------------------------------------------------------------------
>
> Key: ARROW-15798
> URL: https://issues.apache.org/jira/browse/ARROW-15798
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++, R
> Reporter: Dragoș Moldovan-Grünfeld
> Priority: Major
>
> 2 questions:
> * plans to support an origin option for int -> date32 casting?
> * plans to support double -> date32 casting?
> =======================
> Currently the casting from integer to date works, but assumes epoch
> (1970-01-01) as the origin.
> {code:r}
> > a <- Array$create(32L)
> > a$cast(date32())
> Array
> <date32[day]>
> [
> 1970-02-02
> ]
> {code}
> Would it make sense to have an {{origin}} option that would allow the user to
> fine tune the casting? For example, in R the {{base::as.Date()}} function has
> such an argument
> {code:r}
> > as.Date(32, origin = "1970-01-02")
> [1] "1970-02-03"
> {code}
> We have a potential workaround in R (once we support date & duration
> arithmetic), but I was wondering if there might me more general interest for
> this.
> A secondary aspect (as my R example shows) R support casting to date not only
> from integers, but also doubles. Would there be interesting in that? Need be
> I can split this into several tickets.
> Are there any plans in either of these 2 directions?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
