c.POSIXct
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? Then people like Gabor and
me would know that we would have to specify "keepAttributes = TRUE" if
we wanted attributes to be kept. Having this in the documentation would
also help advertise the default behavior. I would expect that
attributes like "dim" and "dimnames" should always be dropped,
regardless of the value of "keepAttributes". With "keepAttributes =
TRUE", "names" would be concatenated, and other attributes would be
taken from the first argument with other attributes of later arguments
ignored.
QUESTIONS:
1. With POSIXct, isn't the numeric part always in GMT,
regardless of time zone? Then the "tzone" attribute only affects the
display? Consider the following:
> (z <- Sys.time())
[1] "2010-08-18 21:16:38 PDT"
> as.numeric(z)
[1] 1282191399
> attr(z, 'tzone') <- 'GMT'
> as.numeric(z)
[1] 1282191399
> z
[1] "2010-08-19 04:16:38 GMT"
2. How can one specify a time zone other than "GMT" and the
default local time zone?
> attr(z, 'tzone') <- Sys.timezone()
> z
[1] "2010-08-19 04:16:38 GMT"
Warning message:
In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'PDT'
Thanks,
Spencer Graves
On 8/18/2010 7:53 PM, Gabor Grothendieck wrote:
On Wed, Aug 18, 2010 at 10:34 PM, Simon Urbanek <simon.urbanek at r-project.org> 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 point -- its undesirable that tzone is lost when using c.
That's one man's opinion - from docs if you want to specify an object in a particular timezone but to be printed in the current timezone you may want to remove the ?"tzone"? attribute (e.g. by ?c(x)?). so apparently that is a design choice and hence I doubt it can be changed as it would break code that uses that feature. As many things in R whether it was a good choice is up for debate but it has been made already. (Think about how you would combine different times with different tzones - there is no "right" way to do so and thus stripping is very plausible and consistent)
I did already address the ambiguity point in the suggested code that I posted. It only maintains the tzone if there is no ambiguity. Note that there have been significant changes in POSIXt relatively recently, namely switching POSIXt and POSIXct class order, so it seems that such changes are not beyond possibility. At any rate, the underlying objective of getting time zones to work in the expected way still seems desirable. If backward compatibility is to be invoked (even though it wasnt in the case I just cited) then it would still be possible to address this with a new core class or subclass.
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San Jos?, CA 95126 ph: 408-655-4567