Krikri::CryptoTimeSpec

_time.py's convert_relative_to_datetime pattern, with named groups (the shared RELATIVE_TIME_RE validator in ansible_arg_validation uses unnamed ones, so it can't hand the components over).

The wire form a resolved datetime takes in real's echoed invocation.module_args: Python's datetime.isoformat() of a UTC datetime - the fraction is omitted entirely when the microseconds are 0, and with_timezone (community.crypto's CRYPTOGRAPHY_TIMEZONE: cryptography >= 42 on the target) adds Python's own "+00:00" offset spelling.

The {type(v)} spelling real's "must be of type string" failure interpolates: the module args arrive as JSON, so the Python type the module would see is the JSON value's class.

The datetime a spec resolves to, in UTC. nil when the spec matches neither shape (the caller owns the error message: the wording differs between the relative and absolute failure paths).

Whether the real module would resolve its "now" as a timezone-aware UTC datetime: CRYPTOGRAPHY_TIMEZONE is cryptography >= 42.0.0 (the version that made datetime.utc* deprecated-aware), False when cryptography is absent or older. Probed through the interpreter the module would run under (python_lib_gate's fallback list; an ansible_python_interpreter pin is not consulted here - get_certificate's target_python precedent). Any probe failure means "not tz-aware", matching CRYPTOGRAPHY_TIMEZONE's False default.