You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Neal Richardson (Jira)" <ji...@apache.org> on 2021/09/28 12:49:00 UTC

[jira] [Resolved] (ARROW-14124) [R] Timezone support in R <= 3.4

     [ https://issues.apache.org/jira/browse/ARROW-14124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Neal Richardson resolved ARROW-14124.
-------------------------------------
    Fix Version/s: 6.0.0
       Resolution: Fixed

Issue resolved by pull request 11250
[https://github.com/apache/arrow/pull/11250]

> [R] Timezone support in R <= 3.4
> --------------------------------
>
>                 Key: ARROW-14124
>                 URL: https://issues.apache.org/jira/browse/ARROW-14124
>             Project: Apache Arrow
>          Issue Type: Bug
>          Components: R
>            Reporter: Jonathan Keane
>            Assignee: Jonathan Keane
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 6.0.0
>
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> The error is: https://github.com/ursacomputing/crossbow/runs/3696604088#step:7:15209
> {code}
>  Timezone not present, cannot convert to string with timezone: %Y-%m-%d%z
> {code}
> Ok, I think I’ve got close to the source of the issue (though let me tell you neither the source nor the docs for R are accurate [1] on this…)
> 3.4 (and earlier):
> {code:r}
> > attributes(c(lubridate::ymd_hms("2018-10-07 19:04:05", tz = "Etc/GMT+6"), NA)) 
> $class
> [1] "POSIXct" "POSIXt" 
> {code}
> 3.5 (and later):
> {code:r}
> > attributes(c(lubridate::ymd_hms("2018-10-07 19:04:05", tz = "Etc/GMT+6"), NA)) 
> $class
> [1] "POSIXct" "POSIXt" 
> $tzone
> [1] "Etc/GMT+6"
> {code}
> So R itself is dropping the {{tzone}} attribute when we use {{c()}}, that is being passed to Arrow as such, and then when Arrow goes to print a timezone it (rightfully!) complains that there is no timezone to be formatted into the string. 
> This behavior actually sounds right (given the inputs), so I propose that we catch the error R <=3.4 (or skip the test in r<=3.4)
> [1] - The documented behavior is current, but it didn't change at the same time as the actual behavior.
> The docs starting in 4.1.0 state:
>  Using \code{\link{c}} on \code{"POSIXlt"} objects converts them to the
>   current time zone, and on \code{"POSIXct"} objects drops any
>   \code{"tzone"} attributes, unless they are all marked with the same
>   time zone.
> https://github.com/wch/r-source/blob/tags/R-4-1-0/src/library/base/man/DateTimeClasses.Rd#L180-L183
> The docs before that state:
>   Using \code{\link{c}} on \code{"POSIXlt"} objects converts them to the
>   current time zone, and on \code{"POSIXct"} objects drops any
>   \code{"tzone"} attributes (even if they are all marked with the same
>   time zone).
> https://github.com/wch/r-source/blob/tags/R-4-0-5/src/library/base/man/DateTimeClasses.Rd



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