R devel - Apr 2016 - Understanding POSIXct creation on different OSes.

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.

Bumping this up to the front again ... because it exhibits a difference in
behaviour of R across OSs.  Such a 'feature' may not be desirable.

On 4 April 2016 at 18:00, Arunkumar Srinivasan wrote:
| 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?

Could someone from R Core please comment, or would you prefer us to file a
bug report?

Thanks!

Dirk



| Thank you,
| Arun.
| 
| ______________________________________________
| R-devel at r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

On 11 April 2016 at 14:48, Dirk Eddelbuettel wrote:
| 
| Bumping this up to the front again ... because it exhibits a difference in
| behaviour of R across OSs.  Such a 'feature' may not be desirable.

And bumping it a second time.  If nobody replies I will carry it over to
Bugzilla.

It is still a "misfeature" with behaviour which varies across OSs
which is
rarely the desired outcome.  I'd still love to hear some comments.

Dirk

| 
| On 4 April 2016 at 18:00, Arunkumar Srinivasan wrote:
| | 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?
| 
| Could someone from R Core please comment, or would you prefer us to file a
| bug report?
| 
| Thanks!
| 
| Dirk
| 
| 
| 
| | Thank you,
| | Arun.
| | 
| | ______________________________________________
| | R-devel at r-project.org mailing list
| | https://stat.ethz.ch/mailman/listinfo/r-devel
| -- 
| http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
| 
| ______________________________________________
| R-devel at r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org