Making decoded-times and calendar dates compatible?

[Richard Lawrence]

Hi everyone,

I've been drafting a sub-library to handle iCalendar recurrence rules
over the last week, and have run into an issue that I would like some
feedback here on: the representations used by make-decoded-time and
related functions are not compatible with those of calendar.el.
I'd like to know if there's any appetite for making these
representations compatible in Emacs, so that functions like e.g.
calendar-day-of-week, calendar-nth-named-day, calendar-date-equal, and
so on could also work with decoded times. 

The reason this would be nice: handling recurrence rules requires doing
a lot of calendar arithmetic. Decoded times have one important
arithmetic function (decoded-time-add) but many more useful arithmetic
functions, like the ones named above, are part of calendar.el. Most of
the iCalendar properties that accept date-time values also accept plain
calendar dates, so I've had to write a lot of boilerplate/wrapper code
to convert between the two types when necessary, and to do type-based
dispatch on values which can be of either type.

Both calendar.el and decoded-time functions represent date(-time) values
as lists. But the calendar assumes dates are in the format (MONTH DAY YEAR), 
whereas decoded times have the format (SEC MIN HOUR DAY MON YEAR DOW DST TZ);
the month, day and year are at different indices in these lists.
If we changed them to use a format like, say,
  (YEAR MONTH DAY)
and 
  (YEAR MONTH DAY DOW HOUR MINUTE SECOND DST TZ)
respectively, changing the relevant accessors, then calendar arithmetic
functions could also work effortlessly with [the date part of] decoded
times, which would really simplify working with both types of values
from other code (including mine, but I assume also in Org, Gnus, diary,
third-party packages, ...).

I see that there was a discussion a few years ago about changing the
representation of decoded-time values, though, and it seems that there
wasn't much appetite even for that because of the possibility of
breaking user code which makes assumptions about the underlying
representation; discussion starts here:

https://lists.gnu.org/archive/html/emacs-devel/2019-08/msg00129.html

So I expect there won't be much appetite for this proposal either, but I
thought I would ask, because (IMHO) the benefits of the change might be
worth it.

Best,
Richard