From arunkumar.sriniv at gmail.com  Mon Apr  4 18:00:52 2016
From: arunkumar.sriniv at gmail.com (Arunkumar Srinivasan)
Date: Mon, 4 Apr 2016 18:00:52 +0200
Subject: [Rd] Understanding POSIXct creation on different OSes.
Message-ID: <CAJ=vYTENdukcF4XZpTkg=y1vFe2QJ5DNBKtCXBPBhey1auvw-A@mail.gmail.com>

Hello,

Following Dirk's post here: https://github.com/Rdatatable/data.table/issues/1619
we would like to clarify if this is the right behaviour, and if so,
the rationale behind it.

Here's the summary (thanks to Dirk and Joshua):

Sys.setenv("TZ"="America/Chicago")
dates = as.Date("2016-03-02") + (0:3)*7 # four Wednesdays
# [1] "2016-03-02" "2016-03-09" "2016-03-16" "2016-03-23"

# on OS X and Windows 10 -- expected result
as.POSIXct(as.POSIXlt(dates), tz = "America/Chicago")
# [1] "2016-03-02 CST" "2016-03-09 CST" "2016-03-16 CDT" "2016-03-23 CDT"

# On Linux (tested on Ubuntu 14.04) -- not as expected
as.POSIXct(as.POSIXlt(dates), tz = "America/Chicago")
# [1] "2016-03-02 00:00:00 CST" "2016-03-09 00:00:00 CST" "2016-03-16
01:00:00 CDT" "2016-03-23 01:00:00 CDT"

# 'isdst' attribute is identical on OS X / Windows / Ubuntu, as expected
# since dates don't have timezones, as pointed out by @JoshuaUlrich under
# issue #1619.
lt = as.POSIXlt(dates)
lt$isdst
# [1] 0 0 0 0

# However, as Dirk points out, setting isdst to -1 on Ubuntu returns
expected results
lt$isdst = -1
as.POSIXct(lt, tz = "America/Chicago")
# [1] "2016-03-02 CST" "2016-03-09 CST" "2016-03-16 CDT" "2016-03-23 CDT"

# Note that setting isdst to -1 on OS X / Windows has no effect, i.e.,
the result is always as expected.

As Dirk points out, from ?POSIXlt:
"Where possible the platform limits are detected, and outside the
limits we use our own C code. This uses the offset from GMT in
use either for 1902 (when there was no DST) or that predicted for
one of 2030 to 2037 (chosen so that the likely DST transition days
are Sundays), and uses the alternate (daylight-saving) time zone
only if ?isdst? is positive or (if ?-1?) if DST was predicted to
be in operation in the 2030s on that day."

It's not clear what this exactly means, and if it is related to the
behaviour shown above. It'd be nice to know if a) this behaviour of
non-identical result is as expected, and if so, b) can we rely on
setting 'isdst' to -1 returning the expected result always?

Thank you,
Arun.



[Rd] Understanding POSIXct creation on different OSes.
Arunkumar Srinivasan