As of version 0.6-4 all objects carry the time zone
under which they were created in a hidden
attribute names .indexTZ
.
Going forward from 0.7-4, the TZ variable is now
also stored in the index itself, in the tzone
attribute. This is to facilitate the transition to
removing the xts-specific attributes referenced by
indexTZ
, indexFormat
, and indexClass
.
These accessor functions will continue to behave the
same under the new internals. Additionally, there is a new
getter/setter method with tzone
and tzone<-
.
Internally, all time indexing is converted to
POSIXct, seconds since the epoch as defined
by a combination of the underlying OS
and the TZ variable setting at creation. The current
implementation of xts manages time zone information
as transparently as possible, delegating all
management to R, which is in turn managed
in most instances by the underlying operating system.
During printing, and subsetting by time strings
the internal POSIX representation is used to
identify in human-friendly terms the time
at each position.
This is different than previous versions of xts,
where the index was stored in its native format (i.e. class).
The ability to create an index using any of the supported
timeBased classes (POSIXct, Date, dates, chron, timeDate,
yearmon, yearqtr) is managed at the user-interaction point,
and the class is merely stored in another hidden attribute
names .indexCLASS
. This is accessible via
the indexClass
and indexClass(x)<-
functions.
In most cases, all of this makes the subsetting by time strings
possible, and also allows for consistent and fast manipulation
of the series internally.
Problems may arise when an object that had been created under
one TZ (time zone) are used in a session using another TZ. This
isn't usually a issue, but when it is a warning is given upon printing
or subsetting. This warning may be controlled with option("xts_check_TZ")
.