[R-SIG-Finance] is there a time-zone adjustment function in R that takes care of day-light saving?
Jeffrey Ryan
jeffrey.ryan at lemnica.com
Mon Jan 30 20:06:05 CET 2012
The catch is that you are really taking your life into your own hands,
but you should be ok.
The one real downside is all of that format(index()) stuff is going to
be costly from a systems standpoint, but is likely the only way to
solve your immediate request.
I'd advise more to think about normalizing to some consistent
timezone, and avoid the overhead and potential for confusion though.
Jeff
On Mon, Jan 30, 2012 at 12:48 PM, Michael <comtech.usa at gmail.com> wrote:
> Okay thanks a lot Jeff!
>
> Following your ideas and after some googling - I've explored the following:
>
>> aaa
> Bid
> 2001-01-03 06:00:00 109.92727
>> indexTZ(aaa)
> [1] ""
>> pb.date <- as.POSIXct(format(index(aaa), "%Y-%m-%d %H:%M:%OS"), tz="GMT")
>>
>> pb.date
> [1] "2001-01-03 06:00:00 GMT"
>> format(pb.date, tz="America/New_York", usetz=T)
> [1] "2001-01-03 01:00:00 EST"
>> index(aaa)=as.POSIXct(format(pb.date, tz="America/New_York", usetz=T))
>>
>> aaa
> Bid
> 2001-01-03 01:00:00 109.92727
>> indexTZ(aaa)
> [1] ""
> Looks okay now? The indices/timestamps had been physically and permanently
> changed...
>
> Could you guys please help reminder if there is any catch doing it this way
> and is it universally correct?
>
> Thanks a lot again!
>
>
>
>
> On Mon, Jan 30, 2012 at 12:30 PM, Jeffrey Ryan <jeffrey.ryan at lemnica.com>wrote:
>
>> This won't immediately "help" per se, but what you are asking about
>> *is* possible:
>>
>> > unclass(as.POSIXct("1970-01-01", tz="UTC"))
>> [1] 0
>> attr(,"tzone")
>> [1] "UTC"
>> > unclass(as.POSIXct("1970-01-01", tz="America/Chicago"))
>> [1] 21600
>> attr(,"tzone")
>> [1] "America/Chicago"
>> > unclass(as.POSIXct("1970-01-01", tz="Europe/London"))
>> [1] -3600
>> attr(,"tzone")
>> [1] "Europe/London"
>> > unclass(as.POSIXct("1970-01-01", tz="Asia/Hong_Kong"))
>> [1] -28800
>> attr(,"tzone")
>> [1] "Asia/Hong_Kong"
>>
>>
>> The 'trick' is the conversion from string representation initially.
>> The OS facilities are where the conversion is happening, and you can
>> effectively trick the system by setting the environment variable for
>> the duration of the C level call. Don't ask for details, as they
>> aren't "R" per se and far too complex for me to explain succinctly,
>> but note that it is possible.
>>
>> In fact, that is one way that xts can manipulate times so well, even
>> with objects that have different TZs assigned.
>>
>> HTH
>> Jeff
>> On Mon, Jan 30, 2012 at 12:07 PM, Michael <comtech.usa at gmail.com> wrote:
>> > Thanks a lot for the nice example! I should have used that to make a
>> > reproducible example. I always had trouble making reproducible example.
>> >
>> > Basically it explains why I couldn't physically change the
>> index/timestamps
>> > by either -5 or -4 hours...
>> >
>> > The indices are always in GMT/UTC internally...
>> >
>> > So the only way to physically change the timestamps is to manipulate them
>> > by hand or programmatically and externally.
>> >
>> > If there is no day-light saving stuff, I could just do align.time by
>> > 5*60*60; but the day-light saving complicated things... I could no longer
>> > do 5*60*60 universally to all data in the time series...
>> >
>> > Too bad...
>> >
>> > On Mon, Jan 30, 2012 at 11:59 AM, Jeffrey Ryan <jeffrey.ryan at lemnica.com
>> >wrote:
>> >
>> >> Take a look at the notion of TZ in R (and in general). The basic idea
>> >> is offset from UTC. The POSIXct [R] representation is _always_ UTC
>> >> internally. The stuff you 'see' is merely an adjustment on print.
>> >>
>> >> You are confounding TZ and OS behavior likely. Some systems (wonder
>> >> which ones?) really screw up TZ handling.
>> >>
>> >> A search of the list archives, the internals of POSIXct, OS
>> >> documentation for TZ, etc will get you thinking clearly I hope. It
>> >> isn't easy though - xts abstracts away a lot of very very painful
>> >> ugliness.
>> >>
>> >> > ?indexTZ
>> >> > x <- xts(NA, Sys.time())
>> >> > x
>> >> [,1]
>> >> 2012-01-30 11:57:53 NA
>> >> > indexTZ(x)
>> >> [1] "America/Chicago"
>> >> > Sys.setenv(TZ="America/New_York")
>> >> > x
>> >> [,1]
>> >> 2012-01-30 11:57:53 NA
>> >> Warning message:
>> >> timezone of object (America/Chicago) is different than current
>> >> timezone (America/New_York).
>> >> > indexTZ(x)
>> >> [1] "America/Chicago"
>> >> > .index(x)
>> >> [1] 1327946273
>> >> attr(,"tzone")
>> >> [1] "America/Chicago"
>> >> attr(,"tclass")
>> >> [1] "POSIXct" "POSIXt"
>> >> > indexTZ(x) <- "America/New_York"
>> >> > indexTZ(x)
>> >> TZ
>> >> "America/New_York"
>> >> > x
>> >> [,1]
>> >> 2012-01-30 12:57:53 NA
>> >> > .index(x)
>> >> [1] 1327946273
>> >> attr(,"tzone")
>> >> TZ
>> >> "America/New_York"
>> >> attr(,"tclass")
>> >> [1] "POSIXct" "POSIXt"
>> >>
>> >> HTH
>> >> Jeff
>> >>
>> >> On Mon, Jan 30, 2012 at 11:31 AM, Michael <comtech.usa at gmail.com>
>> wrote:
>> >> > I have certainly read the doc before I asked.
>> >> >
>> >> > But I guess it doesnt do what I want and I should have made myself
>> >> clear...
>> >> > sorry for that:
>> >> >
>> >> > I created someintraday timeseries with notime zone initially.
>> >> >
>> >> > And then we would like to treat the time series as GMT and convert all
>> >> the
>> >> > timestamps into EST/EDT, taking into account of daylight saving stuff.
>> >> >
>> >> > And then we will do some subsetting and get a new time series.
>> >> >
>> >> > And the we will remove the time zone attributes and from then on treat
>> >> the
>> >> > series as under GMT.
>> >> >
>> >> > I have played with indexTZ yesterday but couldnt find a way to
>> physically
>> >> > change the time stamps to the correct one - the index should be
>> adjusted
>> >> by
>> >> > -5hours in winters and -4hours in summers... but my index just didnot
>> >> > change at all...
>> >> >
>> >> > What could be the problem? There must be some tricks I didnt know...
>> >> Please
>> >> > shed lights on me Thanks a lot!
>> >> > On Jan 30, 2012 11:01 AM, "Jeffrey Ryan" <jeffrey.ryan at lemnica.com>
>> >> wrote:
>> >> >
>> >> > [[alternative HTML version deleted]]
>> >> >
>> >> > _______________________________________________
>> >> > R-SIG-Finance at r-project.org mailing list
>> >> > https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>> >> > -- Subscriber-posting only. If you want to post, subscribe first.
>> >> > -- Also note that this is not the r-help list where general R
>> questions
>> >> should go.
>> >>
>> >>
>> >>
>> >> --
>> >> Jeffrey Ryan
>> >> jeffrey.ryan at lemnica.com
>> >>
>> >> www.lemnica.com
>> >> www.esotericR.com <http://www.esotericr.com/> <
>> http://www.esotericr.com/>
>> >>
>> >> R/Finance 2012: Applied Finance with R
>> >> www.RinFinance.com <http://www.rinfinance.com/> <
>> http://www.rinfinance.com/>
>> >>
>> >> See you in Chicago!!!!
>> >>
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > _______________________________________________
>> > R-SIG-Finance at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>> > -- Subscriber-posting only. If you want to post, subscribe first.
>> > -- Also note that this is not the r-help list where general R questions
>> should go.
>>
>>
>>
>> --
>> Jeffrey Ryan
>> jeffrey.ryan at lemnica.com
>>
>> www.lemnica.com
>> www.esotericR.com <http://www.esotericr.com/>
>>
>> R/Finance 2012: Applied Finance with R
>> www.RinFinance.com <http://www.rinfinance.com/>
>>
>> See you in Chicago!!!!
>>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-SIG-Finance at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> -- Subscriber-posting only. If you want to post, subscribe first.
> -- Also note that this is not the r-help list where general R questions should go.
--
Jeffrey Ryan
jeffrey.ryan at lemnica.com
www.lemnica.com
www.esotericR.com
R/Finance 2012: Applied Finance with R
www.RinFinance.com
See you in Chicago!!!!
More information about the R-SIG-Finance
mailing list