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
as.Date without "origin"
9 messages · Dan Dalthorp, Peter Dalgaard, Johannes Rauh +3 more
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
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
This is in R-devel, mind you, i.e., unreleased and quite possibly unfinished work. No released version of R does this. E.g.,
as.Date(0)
Error in as.Date.numeric(0) : 'origin' must be supplied
version
_ platform x86_64-apple-darwin21.6.0 arch x86_64 os darwin21.6.0 system x86_64, darwin21.6.0 status Patched major 4 minor 2.2 year 2022 month 11 day 02 svn rev 83236 language R version.string R version 4.2.2 Patched (2022-11-02 r83236) nickname Innocent and Trusting
On 2 Nov 2022, at 14:38 , Dan Dalthorp via R-devel <r-devel at r-project.org> wrote: 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
Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
Of course. But the broken as.Date in R-devel breaks one of my packages, so I'm getting threats of the package being removed from CRAN in a few days if the breakage is not resolved. DHD ------- Original Message -------
On Wednesday, November 2nd, 2022 at 8:30 AM, peter dalgaard <pdalgd at gmail.com> wrote:
This is in R-devel, mind you, i.e., unreleased and quite possibly unfinished work. No released version of R does this. E.g.,
as.Date(0)
Error in as.Date.numeric(0) : 'origin' must be supplied
version
_ platform x86_64-apple-darwin21.6.0 arch x86_64 os darwin21.6.0 system x86_64, darwin21.6.0 status Patched major 4 minor 2.2 year 2022 month 11 day 02 svn rev 83236 language R version.string R version 4.2.2 Patched (2022-11-02 r83236) nickname Innocent and Trusting
On 2 Nov 2022, at 14:38 , Dan Dalthorp via R-devel r-devel at r-project.org wrote: 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
-- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
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
?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
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
Dan, as.Date() and as.POSIXct() have been updated to allow replacement of the hidden functions .POSIXct() and .Date() which were the only way to correctly convert the numeric representation of the objects as Johannes explained. Given that this is a very common operation (especially with POSIXct) it makes sense to not rely on hidden functions and will allow us to possibly deprecate them. And as Peter pointed out, this is R-devel so manuals won't be necessarily updated until the full functionality is implemented and this is part of a larger overhaul of the date/time functions which has not been finished yet. Cheers, Simon
On Nov 3, 2022, at 2:38 AM, Dan Dalthorp via R-devel <r-devel at r-project.org> wrote: 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