In this case, since you're not interested in the time but only in the date you can use as.Date
:
> as.Date(strange_days,"%m/%d/%Y")
[1] "1984-02-01" "1984-03-01" "1984-04-01" "1984-05-01" "1984-06-01"
The error you're confronted to is (as you already noticed) most likely due to Daylight Saving Time: it so happens that DST in Russia in 1984 started specifically on the first of April (source).
That being said, on a Mac OSX 10.7.5 running with R 2.14.2 (yes a little outdated) this error is not reproducible:
> strange_days <- c("2/1/1984", "3/1/1984", "4/1/1984", "5/1/1984", "6/1/1984")
> Sys.setenv(TZ='Europe/Moscow')
> d <- strptime(strange_days, '%m/%d/%Y')
> d
[1] "1984-02-01 MSK" "1984-03-01 MSK" "1984-04-01 MSD" "1984-05-01 MSD" "1984-06-01 MSD"
> as.numeric(d)
[1] 444430800 446936400 449611200 452203200 454881600
This suggests that one of the changes made to strptime
between R version 2.14.2 and 3.1.0 modified this behaviour. I'm currently looking for it in the Changelogs but I have no definite evidences yet. Another possibility would be that it is platform-specific.
Additionally here is an excerpt from ?strptime
:
Remember that in most timezones some times do not occur and some occur twice because of transitions to/from summer time. strptime does not validate such times (it does not assume a specific timezone), but conversion by as.POSIXct) will do so. Conversion by strftime and formatting/printing uses OS facilities and may (and does on Windows) return nonsensical results for non-existent times at DST transitions.