Bug 16852 - Inconsistent Date to POSIXt conversion between Windows, OS X and Linux
Summary: Inconsistent Date to POSIXt conversion between Windows, OS X and Linux
Status: UNCONFIRMED
Alias: None
Product: R
Classification: Unclassified
Component: Accuracy (show other bugs)
Version: R-devel (trunk)
Hardware: Other Linux
: P5 enhancement
Assignee: R-core
URL:
Depends on:
Blocks:
 
Reported: 2016-04-22 12:47 UTC by Dirk Eddelbuettel
Modified: 2016-07-20 19:22 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Eddelbuettel 2016-04-22 12:47:27 UTC
Consider the following code:

  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 Windows and OS X the following conversion works correctly:

  # 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"

BUT on Linux (tested on various releases of Ubuntu)

  # 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"

We note that the last two are incorrectly shifted when we would have expected 'midnight' and the shortened display as for the first two -- and all four on OS X and Windows.

This may be related on Linux:

  # 'isdst' attribute is identical on OS X / Windows / Ubuntu, as expected
  # since dates don't have timezones
  lt <- as.POSIXlt(dates)
  lt$isdst
  # [1] 0 0 0 0

Now -- if we set `isdst` results become correct:

  # However, 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"

So the question is:  should R set this for me?  We see in help(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."

Which I cannot quite square with the behaviour.

This bug report is a follow-up on the email that was roundly ignored at r-devel despite two resents.
Comment 1 Mikhail Titov 2016-07-20 19:22:58 UTC
This bug affects me as well. I started SO question http://stackoverflow.com/q/38488629/673826 and found this one later. I cross linked pages.