Deserialize iso8601 to OffsetDateTime with offset being optional

[ogarcia]

This is a question / proposal that may be useful for those who come from using chrono's NaiveDateTime where they have stored dates in iso8601 format but without timezone information.

For example, I have this: 2023-05-26T10:43:49.045733037

This does not deserialize, it gives an error of the type the 'Parsed' struct did not include enough information to construct the type because it lacks at least one Z or timezone information.

Perhaps it would be interesting that if the system encounters such a string it assumes that the timezone is UTC (the same as if it had the Z) and deserializes it. This would make it much easier for people migrating from chrono and I don't think it would be something that would cause problems. What do you think?

On the other hand, can you think of a simple way to currently deserialize such strings in OffsetDateTime right now?

[ogarcia]

Side note: The assumption that the timezone is UTC is for the sake of simplicity. The standard actually accepts that this field (the timezone) does not exist and indicates that in that case the date should be taken as local.

Here is more information.

[jhpratt]

The error is correct, as an explicit UTC offset must be provided. NaiveDateTime in chrono is equivalent to PrimitiveDateTime in time. UTC is not assumed, as a PrimitiveDateTime does not have a concept of UTC offsets. OffsetDateTime does, but does not have a default offset. While the specification does seem to indicate (it's not 100% clear) that it should fall back to the local offset, this is highly error prone in practice, not to mention the fact that it would fail in multi-threaded environments on some systems.

[ogarcia]

This raises another question for me. I see that using (for example) assume_utc you can go from a PrimitiveDateTime to an OffsetDateTime, but I don't see how you can do the conversion the other way around (at least not directly).

Wouldn't you find it interesting that OffsetDateTime has a to_primitive function (for example) where you simply remove the UtcOffset. Or better yet, a pair of to_primitive_utc and to_primitive_local functions, the first one transforming the date to a PrimitiveDateTime in UTC (calculating the offset) and the second one simply removing the UtcOffset and storing the local date in a PrimitiveDateTime.

[jhpratt]

You can search the issues for this repository, as that has been requested a number of times. I've explained my reasoning in those other issues.

[RReverser]

Came across this discussion as had the same issue. The reasoning in general makes sense to me, but if the goal is strictness regarding the input, then why, on the other hand, does PrimitiveDateTime accepts times with explicit timezone, but then quietly ignores them? It seems asymmetrical to what OffsetDateTime is doing, always requiring a timezone.