[bug#74689] [PATCH] Add predicates for decoded times and time deltas

[Richard Lawrence]

Paul Eggert <eggert@cs.ucla.edu> writes:

> What's the use case for these proposed predicates? I'm finding it hard 
> to review the patch without knowing what it's for.

Well, one reason is just general completeness: it's always useful, for
any type, to be able to check that a value is of that type before
passing it to functions that expect that type, e.g. decoded-time-add.

More concretely, in the new implementation of iCalendar/RFC5545 I have
been working on (see Bug#74994), I decided to represent iCalendar times
and date-times as decoded times (with the idea that decoded-times are
the "native" Emacs way to represent these values). This in turn means I
need a way to verify that values are of this type before e.g. doing
calendar arithmetic with them, or serializing a decoded-time value back
out to a string. There are also many places where the iCalendar standard
allows both dates and date-times as values, and I need to dispatch based
on the type at runtime: e.g. to get the month, I need to use
`calendar-extract-month' with a plain date value, but
`decoded-time-month' with a date-time value. I need type predicates to
do such dispatching.

> Surely this should be in time-date.el rather than simple.el.

OK, makes sense -- I'll move it there.

> The implementation of decoded-time-p seems complicated and doesn't match 
> what decode-time produces. 

What seems complicated about it? (Just the use of cl-typep? That can
easily be removed.) What are the mismatches with what decode-time
produces?

> Wouldn't it be simpler to call
> (ignore-errors (equal val (decode-time (encode-time val))))?

I could certainly change it to that if it's preferable, though that
doesn't strike me personally as simpler: it's fewer lines of code, but
rests on implicit assumptions about the implementation details of
decode-time and encode-time. To me it seems simpler to explicitly encode
the constraints that decoded times are supposed to obey.

In any case, maybe the problem here is actually my original choice to
represent iCalendar date-times as decoded times. If decoded times aren't
right for that purpose, I could instead define a new type; but that
would mean I won't be able to re-use all the functions that already work
with decoded-times, unless I can adapt them to work with the new type,
and might end up writing a lot of boilerplate or duplicated code.

Hope that helps clarify things!