parse_date is succeptible to the 2038 bug

[zkamvar]

I originally thought this was because Linus hated the future, but I see that It was because of an integer overflow.

# Last known day to work
parsedate::parse_date("01/19/2038 03:14:07 GMT")
#> [1] "2038-01-19 03:14:07 UTC"
# One second later will throw NA
parsedate::parse_date("01/19/2038 03:14:08 GMT")
#> [1] NA
# Two seconds later and we begin again 
parsedate::parse_date("01/19/2038 03:14:09 GMT")
#> [1] "1901-12-13 20:45:53 UTC"

^{Created on 2019-06-27 by the reprex package (v0.3.0)}

[gaborcsardi]

Thanks! I'll see what I can do. The git data parser has its pros and cons....