serdedotnet
[Suggestion] Support customizing DateTime/DateTimeOffset formats?
I'm working on a domain where for interoperability purposes the serialization format of DateTime/DateTimeOffset needs to be very strict. I got around this by making my own proxy, but it would have been pretty handy to be able to control that specific part of the handling.
I'll think about this, but my bias is against it. Basically, my design goal for the serde project is very high control and customizability and very low maintenance (because this is a personal project).
Right now you can create a proxy to customize this behavior -- one thing I'd be very interested in is making proxy creation easier.
That's totally reasonable - but it's feels odd in a way i can't quite pin down that the DateTimeSerialization I had to do to meet some transport/round-tripping constraints then gets applied to every serialization. Maybe it's my brain that needs to change. Here's some details to flesh out my thinking a bit:
I was working on an implementation of The Update Framework for dotnet called tuf-dotnet. Original, I know. This spec allows for the transmission of structured metadata envelopes that look like this:
record Signature(string algorithm, string hexString);
record Metadata<T>(T signed, Signature[] signatures);
There are 5 allowable shapes for T in this scheme. These metadata records are often (but not required to be) transferred as json files. For this purpose Serde worked wonderfully - I could use the existing Json serialization and deserialization patterns.
To validate one of these metadata, you canonicalize the signed value according to Canonical JSON rules and get its utf8 bytes, then using the various signature informations verify that when you hash those canonicalized bytes the relevant signatures match. The Canonical JSON subset is debated across TUF implementations but most folks have settled on JSON, but the following changes are made:
- only integral numbers are allowed
- objects must have keys ordered by utf8 value
To do this I implemented a separate Serializer for Canonical Json since I can't use Serde's Json serializer system directly to handle these constraints. It took a while because of subtle .NET datetime serialization/conversion issues in this process - I eventually needed to create a Proxy as you mentioned above to get consistent serialization, but as a result that Proxy is used in every Serializer I used - when I really only needed the precise control for Canonical JSON serialization.