Wanted: More control over how dates are serialized and what date types are used

Product

Strawberry Shake

Is your feature request related to a problem?

I'm a big fan of Strawberry Shake, but I've run into an issue with a GQL API we're using. This API relies on UTC for all datetimes internally. However, when we parse these dates into DateTimeOffset, they end up with the local offset because the GQL API doesn't include an offset in its dates (for example, 2024-05-31T12:00:01). This causes confusion when we round trip the dates, as the GQL API correctly parses the offset on our dates.

To work around this, we're currently adding custom code for each DateTimeOffset field to discard the offset, which is a bit of a hassle.

The solution you'd like

After checking the source code, specifically DateTimeSerializer.cs, I think it would be helpful to have an extension that lets us have more control over how the parsing works. It would be great if we could specify things like DateTimeStyles and CultureInfo for more flexibility and compatibility.

Additionally, there might be cases where creating our own datetime types could help us deal with issues caused by troublesome APIs.

Start with Strawberry Shake's DateTimeSerializer.cs and trace how API dates are parsed into DateTimeOffset values. Determine the supported scope for configurable DateTimeStyles, CultureInfo, and custom datetime types; the work is done when the requested serialization controls and their behavior are clearly defined and covered.