1

There have been questions about this earlier also here, here, here, here

Using all these info, below should have worked, but there seems some to be some translation loss.

a <- c(1433097000, 1433183400, 1433269800, 1433356200, 1433442600, 1433529000)
a
# [1] 1433097000 1433183400 1433269800 1433356200 1433442600 1433529000
b <- as.Date(as.POSIXct(a, origin='1970-01-01', tz='Asia/Kolkata'))
b <- as.numeric(as.POSIXct(b, tz='Asia/Kolkata', format="%Y-%m-%d", origin='1970-01-01'))
b
# [1] 1433030400 1433116800 1433203200 1433289600 1433376000 1433462400

==== Edit:

With tz='Asia/Kolkata', time in a is coming as 00:00:00

strftime(as.POSIXct(a, origin='1970-01-01', tz='Asia/Kolkata'), format="%Y-%m-%d %H:%M:%S")
[1] "2015-06-01 00:00:00" "2015-06-02 00:00:00" "2015-06-03 00:00:00" "2015-06-04 00:00:00" "2015-06-05 00:00:00"
[6] "2015-06-06 00:00:00"
Community
  • 1
  • 1
Mohit Verma
  • 2,019
  • 7
  • 25
  • 33
  • 2
    The difference between `a` and `b` is 66600 seconds, i.e (18*60*60) + (30*60). This is the difference between 00:00 (time in `b`) and 18:30 (time in `a`). –  Sep 01 '15 at 09:23
  • Didn't get you @Pascal. For tz='IST', time in a is also 00:00 and not 18:30. – Mohit Verma Sep 01 '15 at 09:27
  • Please compare `as.POSIXct(a, tz='IST', origin='1970-01-01')` and `as.POSIXct(b, tz='IST', origin='1970-01-01')`, after the conversion to the numeric. –  Sep 01 '15 at 09:29
  • 1
    `"IST" %in% OlsonNames()` return `FALSE`, is ther not a typo in the tz parameter ? (or do you use a specific version of the table ?) – Tensibai Sep 01 '15 at 09:38
  • Thanks @Tensibai. Problem still exists. Updated the issue above. – Mohit Verma Sep 01 '15 at 09:46
  • There is no loss of information if you work with dates only. By the way `'Asia/Kolkata'` is equivalent to `IST`. –  Sep 01 '15 at 09:49
  • @Pascal Yes, but in my version of R, it show a warning as unknown timezone. – Tensibai Sep 01 '15 at 09:54
  • @Tensibai I see. On mine, it is recognized. It is not related to your R version, but to your timezone file. –  Sep 01 '15 at 09:54
  • I guess you get `00:00:00` as time for `a` with `tz='Asia/Kolkata'` because it is the local time of your computer. On mine, which time zone is JST, I get `03:30:00` as time for `a`, because my time zone is 3h30min in advance. –  Sep 01 '15 at 12:54

1 Answers1

2

I can't reproduce exactly as 'IST' is an unknown timezone on my machine. (R 3.2.0)

This answer is just developing @Pascal comment as you seem not getting it.

But with your aand using GMT we get dates and time at 18:30:

> as.POSIXct(a, tz='GMT', origin='1970-01-01')
[1] "2015-05-31 18:30:00 GMT" "2015-06-01 18:30:00 GMT" "2015-06-02 18:30:00 GMT" "2015-06-03 18:30:00 GMT"
[5] "2015-06-04 18:30:00 GMT" "2015-06-05 18:30:00 GMT"

Next you take the date only and then reconvert to datetime (Sorry didn't get rid of my timzeone CEST there):

> as.POSIXct(b, tz='GMT', format="%Y-%m-%d", origin='1970-01-01')
[1] "2015-05-31 02:00:00 CEST" "2015-06-01 02:00:00 CEST" "2015-06-02 02:00:00 CEST"
[4] "2015-06-03 02:00:00 CEST" "2015-06-04 02:00:00 CEST" "2015-06-05 02:00:00 CEST"

When giving a date only to as.POSIXct() the function assume it's at 00:00:00 of this day.

That's why there's is a loss, you stripped the time information, so you get a difference between your start and end objects.

Update with the specific case of 'Asia/Kolkata' of Question:

> b
[1] "2015-05-31" "2015-06-01" "2015-06-02" "2015-06-03" "2015-06-04" "2015-06-05"

as.POSIXct ignore the tz parameter when given a Date object (didn't dig on the why) so the workaround is to wrap a call to as.POSIXlt which will make a correct object with original timezone UTC at midnight:

as.POSIXlt(b)
[1] "2015-05-31 UTC" "2015-06-01 UTC" "2015-06-02 UTC" "2015-06-03 UTC" "2015-06-04 UTC" "2015-06-05 UTC"

Wrapped in as.POSIXct with the timezone it gives:

> as.POSIXct(as.POSIXlt(b),tz='Asia/Kolkata')
[1] "2015-05-31 IST" "2015-06-01 IST" "2015-06-02 IST" "2015-06-03 IST" "2015-06-04 IST" "2015-06-05 IST"

But it just changed the time-zone of the object, it did not change the hour.

I've the feeling we're on a XY problem, where this conversion is part of something else (playing with dates at some point) and that is should be handled another way with POSIXct functions like difftime or other...

Tensibai
  • 15,557
  • 1
  • 37
  • 57
  • 1
    You explained better than I tried to do. Side note: on my machine, "IST" is recognized. –  Sep 01 '15 at 09:53
  • 1
    @Pascal I did write an answer as it sounded hard to showcase the underlying problem in comments :) – Tensibai Sep 01 '15 at 09:56
  • I updated the question @Tensibai. With tz='Asia/Kolkata', we do get 'a' time at 00:00:00 and this is converted to 'b'. Now, when 'b' is converted back time 00:00:00 is assumed ..so still not clear to me why there should by any loss ? – Mohit Verma Sep 01 '15 at 10:16
  • @MohitVerma Updated the answer, but I really feel it's a xy problem – Tensibai Sep 01 '15 at 10:39
  • Thanks @Tensibai. What's this xy problem ? – Mohit Verma Sep 01 '15 at 10:50
  • 2
    @MohitVerma Oh, when you're trying to fix a problem wich is just part of the real problem [XY problem on StackExchange](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) – Tensibai Sep 01 '15 at 10:51