From @pencer@gr@ve@ @end|ng |rom prod@y@e@com  Wed Nov  2 23:38:04 2022
From: @pencer@gr@ve@ @end|ng |rom prod@y@e@com (Spencer Graves)
Date: Wed, 2 Nov 2022 17:38:04 -0500
Subject: [Rd] as.Date without "origin"
In-Reply-To: <9022e3ef-90e7-be8d-546c-a72b14f73568@sapo.pt>
References: <EKNZOOr0Xk-P1uT_HZiKSmlTniaWJ9qxbkQAdiT-WTIadalBDTvhObEvUFCj_yZEXiO1_mImOaOMtS-gxB3Rc5rcCUyeUZY9KTpuq-Yd89U=@protonmail.com>
 <345b7101-f116-e6aa-b8cf-522f68ed5638@prodsyse.com>
 <UVIu3zmRKG3oM__PzasW3vvKTYxIrBpYeoHDaghpllF9-_HuAAPEmQbDweRrMj3_KrKDjbmOI5EySuBKOt_0vQsOJRLcmO7w20rqi5MSo6I=@protonmail.com>
 <trinity-944275fc-476b-4c4d-b8db-bbf3ef907154-1667422061742@3c-app-webde-bap25>
 <9022e3ef-90e7-be8d-546c-a72b14f73568@sapo.pt>
Message-ID: <5221d3c5-3f42-027a-a225-6288f6a9c788@prodsyse.com>



On 11/2/22 5:32 PM, Rui Barradas wrote:
> ?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).


I routinely use fractional days with class "Date".  I hope I can 
continue to do so.  Thanks, Spencer Graves
> 
> 
> Hope this helps,
> 
> Rui Barradas
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] as.Date without "origin"
Spencer Graves