Paul Dicker

> The Unix code remains in dire need of a refactoring. I did a rewrite in #1457. As it turns out the caching logic was pretty much broken beyond the...

## Proposal We should remove the `None` case, and replace it with `InGap` and `Err`. ```rust pub enum LocalResult { Single(T), Ambiguous(T, T), /* first, last */ InGap(DateTime, T, T),...

The terms other libraries use to describe what happens during a transition are (https://peps.python.org/pep-0495/#terminology): - turning the clock backwards creates a *fold* in local time, during which the local time...

I updated the description of `InGap`. Maybe that helps.

> Can we implement a separate trait for these which we can use to "specialize" results for these cases? I remember reading that idea in one of the issues, but...

> Thanks for the link, that was what I was looking for. `Fold` and `Gap` are short expressive terms that precisely describe their use case. There is no mention of...

Sorry, I'm not saying things clear enough :smile:. 23:30:00+1:00 is the same instant in time as 00:30:00+2:00, and the same as 22:30:00 UTC. If local time jumps from 23:30:00+1:00 to...

> So `,T,T` would potentially return the same value twice/thrice? Nearly so. In the case of [`TimeZone::from_local_datetime`](https://docs.rs/chrono/latest/chrono/offset/trait.TimeZone.html#method.from_local_datetime) it could return `LocalResult::InGap(DateTime, DateTime, DateTime)`. The first value is a glorified `NaiveDate`...

> If there is a DST transition from 23:30 to 00:30, is 23:30 even defined? Just like 24:00, the upper bound is usually not included. In chrono at least we...

I am not sure what you are trying to come up with to be honest. To make sure: it is a design choice to have a custom `LocalResult` type. It...