concatenating double (integer) with a Date doesn't appear to be commutative:
c(.1, Sys.Date())
# [1] 0.1 18649
c(as.integer(.1), Sys.Date())
# [1] 0 18649
whereas
c(Sys.Date(), .1)
# Error in as.Date.numeric(e) : 'origin' must be supplied
c(Sys.Date(), as.integer(.1))
# Error in as.Date.numeric(e) : 'origin' must be supplied
The second case is unexpected, because ?c rather documents on hierarchical behavior than on this kind of non-commutative arrangement-behavior:
The output type is determined from the highest type of the components
in the hierarchy NULL < raw < logical < integer < double < complex <
character < list < expression. [...] factors are treated only via
their internal integer codes.
I couldn't find a documentation on what happens with Date objects using c, but I would expect Date objects, similarly to factors, to be coerced to integer, as it's seemingly happening in the first case shown above—However, even the first case behaves differently, and we don't get integers!
str(c(as.integer(.1), Sys.Date()))
# num [1:2] 0 18649 ## numeric instead of integer!
Regardless, the non-commutative hierarchy of the two cases shown above is very unexpected.
All the other guys work as documented:
c(.1, as.expression(.1));c(as.expression(.1), .1)
c(.1, as.list(.1));c(as.list(.1), .1)
c(.1, as.character(.1));c(as.character(.1), .1)
c(.1, as.complex(.1));c(as.complex(.1), .1)
c(TRUE, as.integer(.1));c(as.integer(.1), TRUE)
c(as.raw(.1), as.logical(.1));c(as.logical(.1), as.raw(.1))
c(NULL, as.logical(.1));c(as.logical(.1), NULL)
c(NULL, as.raw(.1));c(as.raw(.1), NULL)
as well as:
str(c(.1, as.factor(.1)));str(c(as.factor(.1), .1))
str(c(as.integer(.1), as.factor(.1)));str(c(as.factor(.1), as.integer(.1)))
Question
Is there any documentation that covers this behavior when concatenating Dates with numbers? What might be the intention for it? Should this perhaps be reported as a bug?
question from:
https://stackoverflow.com/questions/65851295/unexpected-and-inconsistent-behavior-concatenating-doubles-integers-with-date 
