Breaking change wish-list

[jhpratt]

Note: There is no breaking change current planned. This issue is to keep track of things that may happen when there is a breaking change at some undetermined point in the future. Items are in no particular order.

---

Potential changes

These are mostly things that I have thought about at some point, with varying levels of certainty.

• Eliminate large-dates feature flag. Support the ±999,999 range of years unconditionally, adding a modifier to the [year] component to solve the issue of ambiguity.
• Remove the serde-well-known feature flag, which is already deprecated in favor of using the relevant flags (serde, formatting, and/or parsing) directly.
• Simplify error handling. Anonymous enums would be wonderful but are not required. In particular, the large number of conversions should be cut down, as many of them exist when they can already be performed transitively. The amount of information exposed should be restricted to as little as necessary, as this has caused issues in the past.
• Remove anything deprecated. This is currently minimal.
• Make FormatItem opaque and require FormatItem::Literal to be valid UTF-8. Likewise for OwnedFormatItem.
• Remove Copy implementation for Parsed.
• Use ranged integers in public APIs. This would currently require adding countless new methods.
• Rename Duration to SignedDuration or something else.
• Make Duration::seconds generic over i64, f32, and f64. Similarly for saturaturating_seconds_* and checked_seconds_*. Alternatively, have a seconds_float method that is generic while keeping the integer case separate.
• Remove Duration::time_fn. This is a carry-over from time 0.1 and was presumably meant as a poor man's benchmarking tool. Instant is not meant to be used in that manner.
• Remove time::Instant in favor of an extension trait on std::time::Instant. This would reduce the number of trait implementations needed. The extension trait was added in v0.3.35, with time::Instant being deprecated at the same time.

[FeldrinH]

Regardless of the specific format chosen, a breaking change I would really like is for the time crate to adopt some standard datetime representation as the default or simply get rid of the default Serialize/Deserialize impls. I would vote for ISO 8601, which avoids the RFC 3339 restriction on negative years.

The current default Serialize impl is really frustrating because the format appears to be bespoke and is thus only meaningfully compatible with time itself.

[jhpratt]

Removing the defaults is almost certainly not going to happen. ISO 8601 is at least a possibility, though keeping the non-human-readable compatibility will almost certainly happen.

thus only meaningfully compatible with time itself.

That's pretty much the point, actually. It's meant for when someone wants to serialize it for storage/transmission and then deserialize it at the other end. It is not and was never intended to be general-purpose — that's what the attributes are for.

[FeldrinH]

I don't really mind the non-human readable variant, since as far as I know there is no widely used binary encoding standard for dates and times. But I think replacing the default human readable representation with a standardized one has only benefits: it avoids the work of maintaining an extra format and interop with other systems is easier out of the box.

[jhpratt]

For what it's worth, "maintaining" the extra format is essentially zero work, as it was a one-off thing that hasn't changed in the slightest. Changing it to a different format wouldn't be much work, and looking at the current implementation it's not even that different from ISO 8601.