Under linux and windows,> as.Date("6666-06-06")[1] "6666-06-06"> as.Date("7777-07-07")[1] "1970-01-01">Feature? Bug? help(as.Date) does not mention this case. Bo.
Bo Peng wrote:> Under linux and windows, > > >>as.Date("6666-06-06") > > [1] "6666-06-06" > >>as.Date("7777-07-07") > > [1] "1970-01-01" > > > Feature? Bug? help(as.Date) does not mention this case.Well, bug, if you really want to call it a bug that you cannot represent the year 6666. ;-) I guess this is some overflow in do_POSIXlt2D that is not protected against misuse. Don't see the point right now, I have to admit. > as.Date("6970-12-31") [1] "6970-12-31" > as.Date("6971-01-01") [1] "1970-01-01" So we cannot represent more than 5000 years into the future, roughly speaking. *Guess* the problem is that we need more than 4 digits for +/- 5000 years (sum=10000). Uwe Ligges> Bo. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
> Well, bug, if you really want to call it a bug that you cannot represent > the year 6666. ;-)So I guess we need a warning message and a line in help(as.Date)? Bo
Bo Peng wrote:>>Well, bug, if you really want to call it a bug that you cannot represent >>the year 6666. ;-) > > > So I guess we need a warning message and a line in help(as.Date)?Even better a fix (than an *error* message), since the POSIX classes can handle the date and I do not (yet) see the reason why Date cannot. But I have no time to dig deeper (at least not this week). Uwe Ligges> Bo > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel