Currently if x1 and x2 are POSIXct then c(x1, x2) will not have a
tzone attribute even if x1 or x2 or both do but it should.
This could be fixed with the following c.POSIXct:
c.POSIXct <- function (..., recursive = FALSE) {
tzones <- lapply(list(...), attr, which = "tzone")
lengths <- sapply(tzones, length)
if (any(lengths > 1)) stop("tzone cannot have length greater than
1")
which <- sapply(tzones, length) == 1
tzone <- unique(unlist(tzones[which]))
if (length(tzone) != 1) tzone <- NULL
structure(c(unlist(lapply(list(...), unclass))), class = c("POSIXt",
"POSIXct"), tzone = tzone)
}
# test
x1 <- Sys.time()
x2 <- structure(x1, tzone = "UTC")
x3 <- structure(x1, tzone = "other")
# these all currently give NULL but with
# above give indicated value
attr(c(x1, x1), "tzone") # NULL
attr(c(x2, x2), "tzone") # "UTC"
attr(c(x1, x2), "tzone") # "UTC"
attr(c(x2, x1), "tzone") # "UTC"
attr(c(x1, x2, x3), "tzone") # NULL
No one answered this so I submitted it to the bugs system and there I got the response that it is documented behavior; however, whether its documented or not is hardly the point -- its undesirable that tzone is lost when using c. On Thu, Aug 12, 2010 at 11:33 AM, Gabor Grothendieck <ggrothendieck at gmail.com> wrote:> Currently if x1 and x2 are POSIXct then c(x1, x2) will not have a > tzone attribute even if x1 or x2 or both do but it should. > > This could be fixed with the following c.POSIXct: > > c.POSIXct <- function (..., recursive = FALSE) { > ? ? ? ?tzones <- lapply(list(...), attr, which = "tzone") > ? ? ? ?lengths <- sapply(tzones, length) > ? ? ? ?if (any(lengths > 1)) stop("tzone cannot have length greater than 1") > ? ? ? ?which <- sapply(tzones, length) == 1 > ? ? ? ?tzone <- unique(unlist(tzones[which])) > ? ? ? ?if (length(tzone) != 1) tzone <- NULL > structure(c(unlist(lapply(list(...), unclass))), class = c("POSIXt", > ? ?"POSIXct"), tzone = tzone) > } > > # test > x1 <- Sys.time() > x2 <- structure(x1, tzone = "UTC") > x3 <- structure(x1, tzone = "other") > > # these all currently give NULL but with > # above give indicated value > > attr(c(x1, x1), "tzone") # NULL > attr(c(x2, x2), "tzone") # "UTC" > attr(c(x1, x2), "tzone") # "UTC" > attr(c(x2, x1), "tzone") # "UTC" > attr(c(x1, x2, x3), "tzone") # NULL >
I used to get caught by this c() behaviour often, but now I do expect it to drop attributes. I think it would break many things if you change it, and force people to write different code when they really do want to drop attributes. When you want new behaviour it is usually better to define a new function, ca() maybe? Paul>-----Original Message----- >From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r- >project.org] On Behalf Of Gabor Grothendieck >Sent: August 18, 2010 6:23 PM >To: r-devel at r-project.org >Subject: Re: [Rd] c.POSIXct > >No one answered this so I submitted it to the bugs system and there I >got the response that it is documented behavior; however, whether its >documented or not is hardly the point -- its undesirable that tzone is >lost when using c. > >On Thu, Aug 12, 2010 at 11:33 AM, Gabor Grothendieck ><ggrothendieck at gmail.com> wrote: >> Currently if x1 and x2 are POSIXct then c(x1, x2) will not have a >> tzone attribute even if x1 or x2 or both do but it should. >> >> This could be fixed with the following c.POSIXct: >> >> c.POSIXct <- function (..., recursive = FALSE) { >> ? ? ? ?tzones <- lapply(list(...), attr, which = "tzone") >> ? ? ? ?lengths <- sapply(tzones, length) >> ? ? ? ?if (any(lengths > 1)) stop("tzone cannot have length greater >than 1") >> ? ? ? ?which <- sapply(tzones, length) == 1 >> ? ? ? ?tzone <- unique(unlist(tzones[which])) >> ? ? ? ?if (length(tzone) != 1) tzone <- NULL >> structure(c(unlist(lapply(list(...), unclass))), class = c("POSIXt", >> ? ?"POSIXct"), tzone = tzone) >> } >> >> # test >> x1 <- Sys.time() >> x2 <- structure(x1, tzone = "UTC") >> x3 <- structure(x1, tzone = "other") >> >> # these all currently give NULL but with >> # above give indicated value >> >> attr(c(x1, x1), "tzone") # NULL >> attr(c(x2, x2), "tzone") # "UTC" >> attr(c(x1, x2), "tzone") # "UTC" >> attr(c(x2, x1), "tzone") # "UTC" >> attr(c(x1, x2, x3), "tzone") # NULL >> > >______________________________________________ >R-devel at r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel=================================================================================== La version fran?aise suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential in...{{dropped:26}}
On Thu, Aug 19, 2010 at 10:16 AM, Paul Gilbert <pgilbert at bank-banque-canada.ca> wrote:> I used to get caught by this c() behaviour often, but now I do expect it to drop attributes. I think it would break many things if you change it, and force people to write different code when they really do want to drop attributes. When you want new behaviour it is usually better to define a new function, ca() maybe? >That would work if ca defaulted to c for those classes that did not supply a ca method.