?s 20:47 de 02/11/2022, Johannes Rauh escreveu:> Dear all,
>
> I would throw in my vote to have origin = "1970-01-01" as a
default in as.Date(). Why? Well, in fact, the "converse" function
as.numeric() does have an implicit default:
>
>> as.numeric(Sys.Date())
> [1] 19298
>
> In fact, as.numeric seems to not even have a method for class
"Date", and so as.numeric() does not even have an argument
"origin" or the like.
>
> In any case, when using Date objects, it may happen that the result is of
clas numeric. For example:
>
>> ifelse(TRUE, Sys.Date(), Sys.Date() + 1)
> [1] 19298
>
> So, in order to transform the result back to class "Date" using
as.Date(), I always need to remember the universal default origin 1970-01-01 and
I need to write it out explicitly.
>
> I find that rather inconvenient, and so having the default origin as a
default would make very much sense to me here.
>
> Of course, for that particular example, it would also help me if ifelse()
would properly handle Date vectors.
>
> Best
> Johannes
>
>> Gesendet: Mittwoch, 02. November 2022 um 14:38 Uhr
>> Von: "Dan Dalthorp via R-devel" <r-devel at
r-project.org>
>> An: "Spencer Graves" <spencer.graves at prodsyse.com>
>> Cc: "r-devel at r-project.org" <r-devel at
r-project.org>
>> Betreff: Re: [Rd] as.Date without "origin"
>>
>> I don't see a compelling rationale for changing the default
behavior as.Date to deviate from the wholly reasonable status quo of
"as.Date will accept numeric data (the number of days since an epoch), but
only if origin is supplied." That has been the expectation for a long, long
time.
>>
>> In any case, the manual should match the behavior.
>>
>> -DHD
>>
>>
>>
>>
>> ------- Original Message -------
>> On Wednesday, November 2nd, 2022 at 6:20 AM, Spencer Graves
<spencer.graves at prodsyse.com> wrote:
>>
>>
>>>
>>>
>>> I've felt that "as.Date" should default to origin
"1970-01-01", so I
>>> added a modification to Ecfun:
>>>
>>>
>>> Ecfun::as.Date1970(0)
>>>
>>>
>>> If R-devel chose to change the default on this, I would happily
>>> deprecate Ecfun::as.Date1970 in favor of base::as.Date ;-)
>>>
>>>
>>> I would therefore support changing the documentation to match the
new
>>> behavior.
>>>
>>>
>>> Spencer Graves
>>>
>>>
>>> On 11/2/22 7:30 AM, Dan Dalthorp via R-devel wrote:
>>>
>>>> The new (2022-10-11 r83083 ucrt) as.Date function returns a
date rather than an error when called without "origin" specified.
>>>>
>>>> # previous versions of R
>>>> as.Date(0)
>>>> # Error in as.Date.numeric(0) : 'origin' must be
supplied
>>>>
>>>> # new:
>>>> as.Date(0)
>>>> # [1] "1970-01-01"
>>>>
>>>> This is at odds with the help file, which gives:
>>>>
>>>> origin
>>>>
>>>> aDateobject, or something which can be coerced
byas.Date(origin, ...)to such an object.
>>>>
>>>> And:
>>>> as.Datewill accept numeric data (the number of days since an
epoch), butonlyiforiginis supplied.
>>>>
>>>> The behavior described in the help file and implemented in
previous versions seems more reasonable than returning a date with an arbitrary
"origin". In any case, in the r-devel there is a mismatch between the
function and its description.
>>>>
>>>> -Dan
>>>> [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
Hello,
ifelse does properly handle Date objects. From its documentation:
Usage
ifelse(test, yes, no)
[...]
Value
A vector of the same length and attributes (including dimensions and
"class") as test and data values from the values of yes or no.
In your example test = TRUE and yes = Sys.Date() so the return value is
class(ifelse(TRUE, Sys.Date(), Sys.Date() + 1))
# [1] "numeric"
class(ifelse(TRUE, Sys.Date(), Sys.Date() + 1L))
# [1] "numeric"
This is expected behavior.
I was expecting class "integer", not "numeric" but this too
is
documented in ?Dates section Details 2nd paragraph.
It is intended that the date should be an integer, but this is not
enforced in the internal representation. Fractional days will be ignored
when printing. It is possible to produce fractional days via the mean
method or by adding or subtracting (see Ops.Date).
Hope this helps,
Rui Barradas