Why is CalDateTime not readonly struct?

[KyMback]

Why is CalDateTime not readonly struct? Currently this is sealed class which means that it will be always allocated in the heap => more allocations => more work for GC. Do you have any plans to rework that?

[axunonb]

Short answer:

We don’t plan to convert CalDateTime to a readonly struct.

Why it’s a sealed class today

• API stability: Changing class -> struct is a hard, breaking change for every consumer (binary and source). It would require a major version, wide refactoring across the codebase, and a migration plan.
• Size and .NET design guidelines: A struct should be small (ideally ≤16 bytes), immutable, and represent a single value. CalDateTime carries:
  • DateOnly (value)
  • nullable TimeOnly (value)
  • string? TzId (reference)
    That’s a relatively large payload for a value type, and it includes a reference. Passing/returning it by value would copy ~24–32 bytes frequently, which can cost more CPU than a Gen0 allocation of a small object.
• Semantics and nullability: Operators currently accept CalDateTime? and use reference checks in a few places. As a struct there’s no reference identity, null flows change (Nullable), and operators/equality would need to be redesigned. Many call sites rely on nullable CalDateTime today.
• Serialization and factory usage: The serializer/factory currently expects a reference type and uses the private parameterless ctor pattern. Flipping to a struct would ripple through serialization and reflection paths.
• Practical perf: Most hot paths in iCal (recurrence expansion, TZ conversions with NodaTime, parsing/formatting) dominate over object allocation costs. Gen0 allocations are cheap; copying larger value types and incidental boxing can easily offset wins without clear end‑to‑end evidence.

Refactoring effort and risk

• Touches every operator, equality, comparison, and any API that passes CalDateTime by reference or relies on null.
• Requires reworking serializers, ToString/formatting, and any code using ReferenceEquals/null checks.
• Needs thorough benchmarks across .NET 8/6 and netstandard2.0 targets and a full regression suite.
• Given the limited maintainer bandwidth, this isn’t something we can responsibly take on without clear, measured wins.

What you can do today

• Measure first (BenchmarkDotNet, dotnet-trace/dotnet-counters) to confirm CalDateTime allocations are the actual bottleneck.
• Reduce conversions: avoid repeated ToTimeZone hops; compute in UTC when possible; reuse Duration values.
• Reuse instances where feasible; pre-size collections to avoid growth copies; avoid boxing (e.g., storing as object).
• If you have a perf-critical path, consider an app-local value-type projection (DateOnly, TimeOnly?, string TzId) for internal computation and only convert to CalDateTime at boundaries.

Make a proposal

If you’re interested in driving a proposal, we’ll gladly review a benchmark-backed design that minimizes breaking changes and shows real-world gains.

[KyMback]

Oh, thank you so much for such a detailed answer.
In my case I have hundreds of occurrences and recurrence rules. And I need to link them with each other (e.g. find for event proper recurrence rule), I'm using calendar.GetOccurrences for that (e.g. create calendar with recurrence rule and try to calculate occurrence for event time period).

Mb you can advice some other approach?

[axunonb]

I need to link them with each other (e.g. find for event proper recurrence rule

Can't figure out what you're trying to achieve, sorry.