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.urba...@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@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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
