indexTZ
Query the TimeZone of an xts object
Get the TimeZone of an xts
object.
- Keywords
- misc
Usage
indexTZ(x, ...)
tzone(x, ...)indexTZ(x) <- value
tzone(x) <- value
Arguments
- x
an
xts
object- value
a valid TZ object
- …
unused
Details
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")
.
Value
A named vector of length one, giving the objects TZ at creation.
Note
Timezones are a difficult issue to manage. If intraday granularity is not needed, it is often best to set the system TZ to "GMT" or "UTC".
See Also
Examples
library(xts)
# NOT RUN {
x <- xts(1:10, Sys.Date()+1:10)
indexTZ(x)
# same, preferred as of 0.9-1
tzone(x)
str(x)
x
# now set TZ to something different...
# }
# NOT RUN {
Old.TZ <- Sys.getenv("TZ")
Sys.setenv(TZ="America/Chicago")
x
Sys.setenv(TZ=Old.TZ)
# }
Community examples
## Setting time-zones using tzone This example is derived from the **Intro to Time Series: The Power of xts and zoo** from (DataCamp)[datacamp.com]. First we'll construct a vector of times to be used in constructing our xts object. ```r require(xts) times <- Sys.time() + seq(1, 1000, 100) ``` Next we can use these times to actually create an **xts** object. ```r times_xts <- xts(1:10, order.by = times) ``` Now we can actually play with the time zones using the function `tzone()`. `tzone()`, in my mind, works similar to the base `names()` function. You can use `names()` on an object to extract the names OR you can set names with the following syntax: `names(x) <- c("a", "b", "c")`. `tzone()` wokrs similarly. We can extract the time-zone of our times_xts object, or set it using `tzone()`. We can extract the system time (the time that was used to create `times`). ```r tzone(times_xts) ``` Well, what if you wanted to set your time zone to Hong Kong? Well: ```r tzone(times_xts) <- "Asia/Hong_Kong" ```