Spencer Graves writes:
>I'm with Gabor on this. I naively would not expect c() to strip
> attributes generally, and I've been
> surprise more than once to find the time zone attribute stripped when I did
> not expect that.
>
>
> Might it make sense to add an argument like "keepAt
On Thu, Aug 19, 2010 at 12:15 PM, Spencer Graves
wrote:
> Hi, Gabor, et al.:
>
>
> I'm suggesting adding "checkAttributes" to "ca", NOT to "c".
>
Yes, that would be a good idea.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/l
Hi, Gabor, et al.:
I'm suggesting adding "checkAttributes" to "ca", NOT to "c".
Spencer
On 8/19/2010 8:50 AM, Gabor Grothendieck wrote:
On Thu, Aug 19, 2010 at 11:43 AM, Spencer Graves
wrote:
Hi, Gabor, Paul, et al.:
For classes that did not supply a "ca" method, I
On Thu, Aug 19, 2010 at 11:43 AM, Spencer Graves
wrote:
> Hi, Gabor, Paul, et al.:
>
>
> For classes that did not supply a "ca" method, I'd rather see the
> default being to start with the corresponding "c" method followed by an
> effort to preserve attributes to the maximum extent feasible
Hi, Gabor, Paul, et al.:
For classes that did not supply a "ca" method, I'd rather see the
default being to start with the corresponding "c" method followed by an
effort to preserve attributes to the maximum extent feasible. I'm not
sure the best defaults, but at the moment, I would
On Thu, Aug 19, 2010 at 10:16 AM, Paul Gilbert
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. W
new function, ca()
maybe?
Paul
>-Original Message-
>From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
>project.org] On Behalf Of Gabor Grothendieck
>Sent: August 18, 2010 6:23 PM
>To: r-devel@r-project.org
>Subject: Re: [Rd] c.POSIXct
>
>No one answere
I'm with Gabor on this. I naively would not expect c() to strip
attributes generally, and I've been surprise more than once to find the
time zone attribute stripped when I did not expect that.
Might it make sense to add an argument like
"keepAttributes=FALSE" to the "c" function
On Wed, Aug 18, 2010 at 10:34 PM, Simon Urbanek
wrote:
>
> On Aug 18, 2010, at 6:23 PM, Gabor Grothendieck wrote:
>
>> 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 p
On Aug 18, 2010, at 6:23 PM, Gabor Grothendieck wrote:
> 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.
>
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
wrote:
> Curre
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")
length
12 matches
Mail list logo
