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
