Questions about Span range and arithmetic

[aquarhead]

for checked_mul we have an example where it errors if the years are too large, 30_000 seems well within i16 limit so I'm surprised to see it errors, I also found this test however I can't find a reference in Temporal spec that states a range like that, am I missing some documents?

The other question is looking at the arithmetic example https://docs.rs/jiff/latest/jiff/struct.Span.html#arithmetic I'm curious why can't we simply save the added span with 420 days? It feels unnecesarry to anchor the spans to a relative date until we actually need to use it to move a date/time (or comparison I guess)? The spec seems quite open on this and I can't seem to find any previous discussion on this, but kindly point me to places nvm I got some counter example

(also opened a PR to improve a comment that got me super confused on first look #535)

[BurntSushi]

The ranges of types (not just Span but also civil::Date and Timestamp) are indeed not the same as Temporal and this was intentional. It's a source of tension, but the fundamental issue is that Temporal's range is quite large and this in turn requires larger primitive representation. This is somewhat easier in the context of the JavaScript ecosystem because of its garbage collection and extreme sophistication for keeping common cases off the heap and putting less common cases on the heap. Rust can broadly do similarish things, but there's no real garbage collector that Jiff can realistically use.

That's a very vague answer, my apologies.

The range I chose for Jiff was based on dates: a civil::Date supports -9999-01-01 up to and including 9999-12-31. The ranges for Timestamp, Zoned, civil::DateTime and Span all follow from that. This propagates the smaller primitive representation that Jiff really needs. This is especially true for Span, which is already quite bulky.

What this comes down to is: why do you need to represent such a long span of time in calendar units specifically? You might be able to just return an error. That's the intent anyway. If you do really need to represent a span of time in calendar units of that size, then you likely have a very specialized and niche use case where Jiff might not be a good fit.