I just wanted to add some additional problems from trying to replicate this.
`trunc` does indeed work as advertised here, as does calling
`round.POSIXt(Sys.Date())`
and `round(Sys.Date())`. These functions are definitely implemented.
However, I am also able to replicate Jiří’s error:
```
> round(Sys.Date())
[1] "2024-02-08"
> round(Sys.time(), 'years')
[1] "2024-01-01 EST"
> round(Sys.Date(), 'years')
Error in round.default(19761, "years") :
non-numeric argument to mathematical function
```
Specifying `units="years"` causes errors — either an error from named argument
(`unused argument units="years"`) or the above error when the argument is
unnamed.
The error they’re experiencing isn’t actually from `round.Date`, it’s from
trying
to call `round("years")`, which is done implicitly when `"years"` is provided
as an
unnamed second argument to `round()`.
I suspect that the original bug report is referencing this behavior. Yes, it is
correct
that `round.Date` does not accept a `units` parameter as implemented and as
specified in
the help file. However, it does feel a little odd that `round.POSIXt` does
accept a `units`
parameter, but `round.Date` does not. Adding that capability would be fairly
simple, unless
there are other reasons why it isn’t implemented. Just my quick thoughts.
-Aidan
-----------------------
Aidan Lakshman (he/him)
http://www.ahl27.com/
On 8 Feb 2024, at 9:36, Olivier Benz via R-devel wrote:
>> On 8 Feb 2024, at 15:15, Martin Maechler <maech...@stat.math.ethz.ch> wrote:
>>
>>>>>>> Jiří Moravec
>>>>>>> on Wed, 7 Feb 2024 10:23:15 +1300 writes:
>>
>>> This is my first time working with dates, so if the answer is "Duh, work
>>> with POSIXt", please ignore it.
>>
>>> Why is not `round.Date` and `trunc.Date` "implemented" for `Date`?
>>
>>> Is this because `Date` is (mostly) a virtual class setup for a better
>>> inheritance or is that something that is just missing? (like
>>> `sort.data.frame`). Would R core welcome a patch?
>>
>>> I decided to convert some dates to date using `as.Date` function, which
>>> converts to a plain `Date` class, because that felt natural.
>>
>>> But then when trying to round to closest year, I have realized that the
>>> `round` and `trunc` for `Date` do not behave as for `POSIXt`.
>>
>>> I would assume that these will have equivalent output:
>>
>>> Sys.time() |> round("years") # 2024-01-01 NZDT
>>
>>> Sys.Date() |> round("years") # Error in round.default(...): non-numeric
>>> argument to mathematical function
>>
>>
>>> Looking at the code (and reading the documentation more carefully) shows
>>> the issue, but this looks like an omission that should be patched.
>>
>>> -- Jirka
>>
>> You are wrong: They *are* implemented,
>> both even visible since they are in the 'base' package!
>>
>> ==> they have help pages you can read ....
>>
>> Here are examples:
>>
>>> trunc(Sys.Date())
>> [1] "2024-02-08"
>>> trunc(Sys.Date(), "month")
>> [1] "2024-02-01"
>>> trunc(Sys.Date(), "year")
>> [1] "2024-01-01"
>>>
>>
>
> Maybe he meant
>
> r$> Sys.time() |> round.POSIXt("years")
> [1] "2024-01-01 CET"
>
> r$> Sys.Date() |> round.POSIXt("years")
> [1] "2024-01-01 UTC"
>
> The only difference is the timezone
>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
