Support serialization of datetime.timedelta

[inklesspen]

In my code I use datetime.timedelta to represent a Linux kernel timeval struct. However, timedeltas are not serializable currently.

Of course, I could implement my own timedelta Struct, or use the existing hooks to add support for serializing this type. But it would be nice if msgspec supported this.

[jcrist]

Thanks for opening this issue. This is in-scope for msgspec, but isn't something we're going to accomplish in the near future as it's blocked by some deeper changes required.

Other supported datetime types (datetime, date, time) all have pretty universally recognized serialized representations. Almost all libraries support RFC3339 for encoding/decoding these types. This isn't true for timedelta. I've seen:

• Seconds since the epoch as a float
• Milliseconds since the epoch, as a float
• A custom human-readable string with units as go's Duration does.
• ISO8601 durations, which while standardized aren't supported by python's stdlib

Currently msgspec's extension mechanism only works for adding support for new types, there's no way to override how a builtin type is encoded/decoded. This is due to the single-callable nature of enc_hook/dec_hook. Before our 1.0 release I want to move these to a more granular extension mechanism, so we could know what types the user has overridden, and provide builtin support for common ones if no override is registered. I wouldn't expect this to happen for a couple months though.

datetime.timedelta is a rare case of a Python type that has a C-API (so we have a large opportunity to speedup encoding/decoding performance) but also no universally agreed upon serialization format. Most types where users may disagree on serialization format won't be made faster by baking them into msgspec directly - the extension mechanism will be just as performant as anything builtin.

Anyway, for now I recommend using the existing enc_hook/dec_hook mechanisms to support timedelta types. I'll leave this open as a reminder that we eventually want to have a default encoding for these, but wouldn't expect this to be resolved in the near future.