2

I've been dealing with adjusting parsed time stamps for Daylight Savings Time and observed some odd behavior... namely, as.POSIXct and strptime do not produce consistent behavior during the roll-back hour.

More specifically "11/2/2014 1:45:15 AM" becomes "2014-11-02 01:45:15 PDT" and "11/2/2014 1:50:00 AM" becomes "2014-11-02 01:50:00 PST". I am not sure if this is some sort of bug, but it seems to me that should not be happening. In other words, there should be some consistent behavior in parsing time stamps during the hour in question.

The following block should reproduce the described behavior

test_series = c("11/1/2014 11:56:30 PM","11/2/2014 12:26:30 AM",
                "11/2/2014 12:41:30 AM","11/2/2014 12:42:30 AM",
                "11/2/2014 1:12:30 AM","11/2/2014 1:42:30 AM",
                "11/2/2014 1:44:15 AM","11/2/2014 1:45:15 AM",
                "11/2/2014 1:15:15 AM","11/2/2014 1:45:15 AM",
                "11/2/2014 1:50:00 AM","11/2/2014 1:51:00 AM",
                "11/2/2014 2:03:45 AM","11/2/2014 2:04:45 AM",
                "11/2/2014 2:23:30 AM","11/2/2014 2:24:30 AM")

format_str="%m/%d/%Y %I:%M:%S %p"
tz_str="US/Pacific"
as.POSIXct(test_series, format=format_str, tz=tz_str)
strptime(test_series, format=format_str, tz=tz_str)

Of course, one obvious work-around is to set the time zone parameter to UTC and then shift the time around. However, I would like to understand why the behavior is not consistent. In other words, I want to know why one part of the hour maps to daylight savings time and the other part maps to standard. More importantly, I would like to control that behavior.

Here is another test string array, with higher granularity time stamps...

second_test_series = c('11/1/2015 12:59:30 AM','11/1/2015 1:00:30 AM','11/1/2015 1:01:30 AM','11/1/2015 1:02:30 AM','11/1/2015 1:03:30 AM','11/1/2015 1:04:30 AM','11/1/2015 1:05:30 AM','11/1/2015 1:06:30 AM','11/1/2015 1:07:35 AM','11/1/2015 1:08:35 AM','11/1/2015 1:09:35 AM','11/1/2015 1:10:35 AM','11/1/2015 1:11:35 AM','11/1/2015 1:12:40 AM','11/1/2015 1:13:40 AM','11/1/2015 1:14:40 AM','11/1/2015 1:15:40 AM','11/1/2015 1:16:40 AM','11/1/2015 1:17:40 AM','11/1/2015 1:18:40 AM','11/1/2015 1:19:40 AM','11/1/2015 1:20:40 AM','11/1/2015 1:21:40 AM','11/1/2015 1:22:40 AM','11/1/2015 1:23:40 AM','11/1/2015 1:24:40 AM','11/1/2015 1:25:40 AM','11/1/2015 1:26:40 AM','11/1/2015 1:27:40 AM','11/1/2015 1:28:40 AM','11/1/2015 1:29:40 AM','11/1/2015 1:30:40 AM','11/1/2015 1:31:40 AM','11/1/2015 1:32:45 AM','11/1/2015 1:33:45 AM','11/1/2015 1:34:45 AM','11/1/2015 1:35:45 AM','11/1/2015 1:36:45 AM','11/1/2015 1:37:45 AM','11/1/2015 1:38:50 AM','11/1/2015 1:39:50 AM','11/1/2015 1:40:50 AM','11/1/2015 1:41:50 AM','11/1/2015 1:42:50 AM','11/1/2015 1:43:50 AM','11/1/2015 1:44:50 AM','11/1/2015 1:45:50 AM','11/1/2015 1:46:50 AM','11/1/2015 1:47:50 AM','11/1/2015 1:48:50 AM','11/1/2015 1:49:50 AM','11/1/2015 1:50:50 AM','11/1/2015 1:51:50 AM','11/1/2015 1:52:50 AM','11/1/2015 1:53:50 AM','11/1/2015 1:54:50 AM','11/1/2015 1:55:50 AM','11/1/2015 1:56:50 AM','11/1/2015 1:57:55 AM','11/1/2015 1:58:55 AM','11/1/2015 1:59:55 AM','11/1/2015 1:00:55 AM','11/1/2015 1:01:55 AM','11/1/2015 1:02:55 AM','11/1/2015 1:04:00 AM','11/1/2015 1:05:00 AM','11/1/2015 1:06:00 AM','11/1/2015 1:07:00 AM','11/1/2015 1:08:00 AM','11/1/2015 1:09:00 AM','11/1/2015 1:10:00 AM','11/1/2015 1:11:00 AM','11/1/2015 1:12:00 AM','11/1/2015 1:13:00 AM','11/1/2015 1:14:00 AM','11/1/2015 1:15:00 AM','11/1/2015 1:16:00 AM','11/1/2015 1:17:00 AM','11/1/2015 1:18:00 AM','11/1/2015 1:19:00 AM','11/1/2015 1:20:00 AM','11/1/2015 1:21:00 AM','11/1/2015 1:22:00 AM','11/1/2015 1:23:00 AM','11/1/2015 1:24:05 AM','11/1/2015 1:25:05 AM','11/1/2015 1:26:05 AM','11/1/2015 1:27:05 AM','11/1/2015 1:28:05 AM','11/1/2015 1:29:10 AM','11/1/2015 1:30:10 AM','11/1/2015 1:31:10 AM','11/1/2015 1:32:10 AM','11/1/2015 1:33:10 AM','11/1/2015 1:34:10 AM','11/1/2015 1:35:10 AM','11/1/2015 1:36:10 AM','11/1/2015 1:37:10 AM','11/1/2015 1:38:10 AM','11/1/2015 1:39:10 AM','11/1/2015 1:40:10 AM','11/1/2015 1:41:10 AM','11/1/2015 1:42:10 AM','11/1/2015 1:43:10 AM','11/1/2015 1:44:10 AM','11/1/2015 1:45:10 AM','11/1/2015 1:46:10 AM','11/1/2015 1:47:10 AM','11/1/2015 1:48:10 AM','11/1/2015 1:49:15 AM','11/1/2015 1:50:15 AM','11/1/2015 1:51:15 AM','11/1/2015 1:52:15 AM','11/1/2015 1:53:15 AM','11/1/2015 1:54:15 AM','11/1/2015 1:55:20 AM','11/1/2015 1:56:20 AM','11/1/2015 1:57:20 AM','11/1/2015 1:58:20 AM','11/1/2015 1:59:20 AM','11/1/2015 2:00:20 AM','11/1/2015 2:01:20 AM')

UPDATE: As pointed out by a comment, this may be an OS related issue. The above behavior was originally observed on a Windows machine, and I cannot reproduce the above behavior on a Linux machine.

Constantine
  • 479
  • 1
  • 9
  • 19
  • 2
    The documentation _does_ say that in the case of the Fall daylight savings time transition, results from within that hour are ambiguous and may be interpreted by the OS in either. (Which also highlights that since R is relying on your OS built-in datetime code, it can be hard to tell when a behavior is due to R, or your OS.) – joran Dec 09 '16 at 19:37
  • 1
    Is there a way to *force* an ambiguous time stamp to be treated as DST or standard time? – mpettis Dec 09 '16 at 20:28
  • Thanks @joran, I assumed this was an R issue. However, it seems that it may be a Windows issue. I checked on my machines at home, and it is ideed not an issue on Linux at least. I do not have access to a Mac. – Constantine Dec 10 '16 at 22:22

0 Answers0