const REASONABLE_ZONED_LEN: usize = 72;Expand description
Defines the “maximum” possible length (in bytes) of an RFC 9557 zoned datetime.
In practice, the actual maximal string possible is I believe
-009999-03-14T17:30:00.999999999-04:23[America/Argentina/ComodRivadavia],
which is 72 bytes. Obviously, the length of the IANA tzdb identifier
matters and can be highly variable.
So why is this called “reasonable” and not “maximum”? Well, it’s the
IANA tzdb identifiers. They can be arbitrarily long. There also aren’t
any rules about how long they can be. So in theory, IANA could allocate
a new identifier longer than America/Argentina/ComodRivadavia. With
that said, they do generally try to keep them succinct.
Separately from what IANA does, Jiff itself doesn’t impose any restrictions
on the length of identifiers. Callers can pass in arbitrarily long
identifiers via TimeZone::tzif or by simply futzing with the names of
files in /usr/share/zoneinfo. It’s also possible to use an arbitrarily
long identifier via the “pieces” TimeZoneAnnotationName API. Since we
don’t impose any restrictions, we really do want to at least try to handle
arbitrarily long identifiers here.
Thus, we define a “reasonable” upper bound. When the RFC 9557 string we
want to serialize is known to be under this bound, then we’ll use a “fast”
path with a fixed size buffer on the stack (or perhaps even write directly
into the spare capacity of a caller providd String). But when it’s above
this bound, then we fall back to a slower path that uses a buffering
mechanism to permit arbitrarily long IANA tzdb identifiers.
For the most part, doing this dance doesn’t come with a runtime cost,
primarily because we choose to sacrifice code size a bit by duplicating
some functions. We could have our cake and eat it too if we enforce a
maximum length on IANA tzdb identifiers. Then we could set a true
MAX_ZONED_LEN and avoid the case where buffering is needed.