Closed TimBMK closed 11 months ago
This is because week(1)
is internally a "7d 0H 0M 0S"
> weeks(1)
[1] "7d 0H 0M 0S"
> str(weeks(1))
Formal class 'Period' [package "lubridate"] with 6 slots
..@ .Data : num 0
..@ year : num 0
..@ month : num 0
..@ day : num 7
..@ hour : num 0
..@ minute: num 0
So you get a ceiling and flooring to the multiple of 7 days from the begining of the month. I agree that this is a bit confusing but I am afraid there is no solution for this given the current internal representation of the periods.
I am clarifying the documentation regarding exactly this point.
Thanks for the clarification! Yes, it makes sense that it starts from the first day of the month. It's a little confusing when you expect weeks(1) to behave like an equivalent of the "weeks" unit, especially considering the _weekstart argument that is silently getting ignored in this case.
In practice, I've used the weeks() unit specifically to avoid the fiddly month start dates, e.g. by replacing months(3) with weeks(12) to get more consistent timeframe slices over longer periods. So I'm a little surprised weeks() is tied to the monthly start date here, but that might just be me misunderstanding the exact nature of the weeks() period.
Anyways, thank you for this great package. It certainly makes life a lot easier when dealing with dates!
The
round_date()
-functions (likeceiling_date()
andfloor_date()
) documentation states that periods, such asweeks(1)
, can be provided asunit
. This is great for use in higher level functions, where an arbitrary time period may be chosen to floor or ceiling a date. However, the results betweenunit = "weeks"
andunit = weeks(1)
differ. Specifically,unit = weeks(1)
seems to set the week_start to Friday, and ignores theweek_start
argument. See reprex below.Am I missing something here or is this a bug?