Implement RFC 9581 date/time encodings

[bgamari]

Since serialise was written the IETF have standardized encodings for dates, times and durations via RFC 9581. We should ideally integrate support for these encodings in serialise.

[phadej]

Since serialise has written, there is RFC8949 (#279) specifying serialisation for times. Do you specifically need RFC9581 extended time support, or is https://www.rfc-editor.org/rfc/rfc8949.html#name-epoch-based-date-time enough to begin with?

The full support for RFC9581 would require writing specific types, so information like clock accuracy. Alternatively we could fail if non-representable information is provided (as spec requires, i.e. not supporting most of "extended" stuff). (We already have to fail (?) if we'd try to deserialise into UTCTime, but the timescale is TAI).

[phadej]

Wait, there is

--------------------------------------------------------------------------------
-- Time instances
--
-- CBOR has some special encodings for times/timestamps

-- | 'UTCTime' is encoded using the extended time format which is currently in
-- Internet Draft state,
-- https://tools.ietf.org/html/draft-bormann-cbor-time-tag-00.
--
-- @since 0.2.0.0
instance Serialise UTCTime where
    encode t =
        encodeTag 1000
        <> encodeMapLen 2
        <> encodeWord 1 <> encodeInt64 secs
        <> encodeInt (-12) <> encodeWord64 psecs

so now I'm completely confused. @bgamari can you clarify what should be done?

[phadej]

I understood that motivation for this issue is compatibility issues of serialise with other CBOR tools in other languages.

it seems that (if we fix the tag of extended time encoding), none of other libraries implement RFC9581, and I cannot even find any issues. For example, python's cbor2 don't understand the encoding, and just outputs the map:

% python3 -m cbor2.tool < hs.dat
{"CBORTag:1001": {"1": 1754663683, "-12": 181233107000}}

So if the motivation is indeed to increase compatibility of serialise, I suggest that we should encode UTCTime as the CBOR spec suggests, i.e. using tag 0 or 1, https://datatracker.ietf.org/doc/html/rfc8949#name-standard-date-time-string or https://datatracker.ietf.org/doc/html/rfc8949#name-epoch-based-date-time respectively.

We could provide explicit functions to encode UTCTime using extended date/time (RFC9581) format, but I'd argue that for time being it's simply a wrong default (i.e. shouldn't be the instance implementation).

[bgamari]

Indeed the concern is compatibility; in general if a standardized encoding exists then we should use it. I would be fine with using RFC8949's encoding by default.

[phadej]

In a chat with Ben we agreed to serialise UTCTime as epoch-based-date-time. I'll implement that shortly.