1

I have the same problem as https://stackoverflow.com/questions/15575713/modifying-timezone-of-a-posixct-object-without-changing-the-display. However, I followed the accepted response but I don't get the desired result.

dt is a string ("2017-07-07 15.46.00"). I need to change it to data-time format with CDT time zone ("2017-07-07 15:46:00 CDT"). I can do it by lubridate::ymd_hms and I get my desired result (lub.dt: "2017-07-07 15:46:00 CDT") but it is too slow for my dataset size. I converted dt using fasttime::fastPOSIXct which is very fast but the function assumes the input is in 'GMT'. So I used 'GMT' for the output as well to get the same date-time display (fast.dt: "2017-07-07 15:46:00 GMT"). Finally, I tried to change the time zone by as.POSIXct. I used the same tz (America/Chicago) for origin and the function but I get this result "2017-07-07 16:46:00 CDT" which is (time +1).

library(lubridate)
library(fasttime)
dt <- "2017-07-07 15.46.00"
lub.dt <- ymd_hms(dt, tz = 'America/Chicago')
fast.dt <- fastPOSIXct(dt, tz = 'GMT')
fast.dt.new.tz <- as.POSIXct(x = as.numeric(fast.dt), origin = as.POSIXct("1970-01-01", tz = 'America/Chicago'),tz = 'America/Chicago')

Can anyone guide me what I did wrong?

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
Yashar
  • 23
  • 3
  • Try just this: `as.POSIXct(dt,"%Y-%m-%d %H.%M.%S", tz = 'CST6CDT')`. The CST6CDT should provide the proper CST or CDT time zone. – Dave2e Aug 02 '17 at 20:51
  • Thanks for the suggestion. 'as.POSIXct' is faster than 'lubridate' functions but it's not applicable on my dataset. This [post](https://stackoverflow.com/questions/35247063/is-there-a-fast-parser-for-date) compares different parsing approaches. – Yashar Aug 02 '17 at 21:27

1 Answers1

0

This is muddled. Your problem is the insistence on the (very fine) fasttime package, and now trying to fudge the TZ adjustment.

I would recommend against. You could use anytime which is also pretty fast (compiled code, but tries different formats):

R> anytime::anytime("2017-07-07 15.46.00")
[1] "2017-07-07 15:46:00 CDT"
R>

It's advantage is that it does what you want here: interpret the string as local time, and set the local time (Chicago for me too).

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
  • Thanks Dirk for introducing this package. However, I just checked its performance. It seems it's slower than both 'fastPOSIXct' and 'as.POSIXct'. 'library(microbenchmark) dt <- "2017-07-07 15.46.00" test <- rep(dt, 10000) microbenchmark( test1 <- fastPOSIXct(test), test2 <- anytime(test), test3 <- as.POSIXct(test, format='%Y-%m-%d %H:%M:%S'), times=100)' which gives '776, 55940, 3776 ms' respectively. – Yashar Aug 02 '17 at 21:41
  • Sure. And more general. There are trade-offs. But it _answers your very question here_. – Dirk Eddelbuettel Aug 02 '17 at 21:43
  • Actually it doesn't answer the question. Using `anytime` is not practical on a big dataset. I appreciate if you can help with the last operation (changing the timezone). – Yashar Aug 03 '17 at 13:45
  • I beg to differ, but if it doesn't suit you luckily there is still the money-back gurantee with open source. I have another package that shifts timezone but given your attitude I am not exactly motivated in extending this. Good luck. – Dirk Eddelbuettel Aug 03 '17 at 14:04
  • I'm very open to try a new function/approach. But I talked with numbers, `anytime` did the same job about 72 (55940/776) times slower than `fastPOSIX`. I'm not biased to use a function but I usually compare the performance by numbers. – Yashar Aug 03 '17 at 14:30
  • Apples != oranges. `fastPOSIX` has a completely different scope ("as fast as possible, one format, only UTC input") where anytime is meant to convert _any_ sane format reasonably fast (using Boost C++ internally). But as I said, if fast enough + easy + correct is not good enough for you, you are more than welcome to craft your own solution. I am done here now. – Dirk Eddelbuettel Aug 03 '17 at 14:32