dmonths and dyears incorrectly defined

[jeffreyoldham]

Adding dmonths and dyears to dates does not yield correct values because they are defined in terms of seconds. Furthermore, dmonths was added in 1.7.8 but not exported. To correct, durations must be reimplemented to account for irregular duration lengths.

1. Adding dmonths or dyears to a date yield the wrong values.
2. dmonths was not exported via NAMESPACE.

library(lubridate)
lubridate::dmonths
# Error: 'dmonths' is not an exported object from 'namespace:lubridate'

lubridate::ymd("1970-01-01") + lubridate::dyears ( 1 )
# wrong answer: [1] "1971-01-01 06:00:00 UTC"
# correct answer: [1] "1971-01-01 00:00:00 UTC"

The underlying problem is the duration of a month or a year depends on the particular month or year. 1972-02 has 29 days, while 1972-03 has 31. 1972 has 366 days, while 1973 has 365 days. Adding these durations to dates needs to reflect this. The duration object should be reimplemented to reflect this lack of regularity. (The absence of support for leap seconds also indicates the need for a fundamental reimplementation of durations.)

[vspinu]

You are right about dmonth not being exported.

Regarding your other problem, it's as expected. durations are fixed, and dmonth and dyear are average durations. This is documented.

What you need is a period.

> ymd("2020-01-01") + dyears(1)
[1] "2021-01-01"

[MokeEire]

Why is this closed? dmonths() is still not exported.

[vspinu]

it is in v1.7.9

lubridate::dmonths
function(x = 1) new("Duration", x * average_durations[["month"]])
<bytecode: 0x56471b490d78>
<environment: namespace:lubridate>