[Rd] c.POSIXct

[Spencer Graves]

        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