R devel - Feb 2024 - round.Date and trunc.Date not working / implemented

> On 8 Feb 2024, at 15:15, Martin Maechler <maechler at
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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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 <maechler at
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 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 14:36 de 08/02/2024, Olivier Benz via R-devel
escreveu:
>> On 8 Feb 2024, at 15:15, Martin Maechler <maechler at
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 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,

You are right that the timezones are different but Sys.date() returns an 
object of class "Date" so the method called is not that one.
Here an example with trunc.


Sys.Date() |> class()
Sys.Date() |> trunc("years")
Sys.Date() |> trunc.Date("years")
Sys.Date() |> trunc.POSIXt("years")


As for the OP, the problem is thhat the generic roun())) doesn't have 
unit argument. So I am  nnnot understanding why round.POSIXt works.


Sys.Date() |> round("years")
#> Error in round.default(structure(19761, class = "Date"),
"years"):
non-numeric argument to mathematical function
Sys.Date() |> round.Date("years")
#> Error in NextMethod(): generic function not specified

Sys.Date() |> round.POSIXt("years")
#> [1] "2024-01-01 UTC"
Sys.Date() |> round.POSIXt("months")
#> [1] "2024-02-01 UTC"
Sys.Date() |> round.POSIXt("days")
#> [1] "2024-02-08 UTC"


Hope this helps,

Rui Barradas



-- 
Este e-mail foi analisado pelo software antiv?rus AVG para verificar a presen?a
de v?rus.
www.avg.com