trunc/floor/ceil/round interface inconsistency for methods involving dates?

[Sacha0]

trunc methods typically conform to trunc([T,] x, [digits, [base]]) --- except where they involve Dates/DateTimes: trunc methods that accept a date type / value pair take the form trunc(x, T) rather than trunc(T, x). Should these non-conforming methods conform? Apologies if I missed a good reason for this inconsistency while searching, and please close if so. Best!

Edit: The same holds for at least some floor, ceil, and round methods involving dates.

[tkelman]

Good catch. @spurll any reason for having the arguments this way in #17037 ? Must've missed that in review.

[spurll]

I modelled the function signatures for floor, ceil, and round for dates on trunc, which already existed. But I think that this is not actually an issue, because trunc(T, x) truncates, converting the result to type T. For dates that doesn't make sense: trunc(dt, Minute) doesn't return a Minute value, it still returns a Date/DateTime.

For this reason, when we're looking at trunc(dt::TimeType, ::Type{Period}), the type in question is really more analogous to digits in trunc([T,] x, [digits, [base]]) rather than T. It's also worth considering that for the rounding functions it is permissible to pass in a Period value, not just a Period type (e.g., Dates.Minute(15)), making the analogy to digits even more apt.

So I think the existing signature is sensible for two reasons: (1) it reads the way one would say it (e.g., round(dt, Minute(15)) would be "round dt to fifteen minutes") and (2) I see the period to which we're rounding as more analogous to digits in the trunc example above, rather than T.

[simonbyrne]

The idea is that trunc(T,x) should be equivalent to convert(T,trunc(x)), which is not the case for dates, so I think the existing behaviour is fine.

[Sacha0]

Much thanks for the lucid explanation @spurll! Best!