Moritz Oberhauser

I agree with the arguments that wrapping `Result` is a bit cumbersome. If replacing `None` with `Err` proves to be usable, I'm all for that. Two principles look important to...

> 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...

> Making methods on `DateTime` or `DateTime` have a different return value from `DateTime` and `DateTime` seems strange, if that is even possible. Never heard of that either. If `LocalResult`...

> It seems just as useful and controversial as Option::unwrap() 😄. Makes sense :) > How about the example in the opening post? I want to know the number of...

> With this proposal we would encode the gap (with peseudo-code) as `InGap(2024-02-20 22:30:00 UTC, +1:00, +2:00)`. My head is spinning, but I think i got it now. The second...

> > Making methods on `DateTime` or `DateTime` have a different return value from `DateTime` and `DateTime` seems strange, if that is even possible. > > Never heard of that...

> I am not sure what you are trying to come up with to be honest. The proposal by djc was to "specialize" the return type for certain implementations. Once...

> How about `TzResolution` as a new name for `LocalResult`? Inspired by the `DateTimeResolution` name of a similar type in eos. Sounds good to me!

Sidenote about `LocalResult` as return type for `DateTime`: How about returning `Result` instead? This prevents `LocalResult::None` from masking the error cause. `LocalDatetime` would be the same as `LocalResult` sans the...

> ## Pleasant to use > > The deprecations of many potentially panicking methods in 0.4.23 have made chrono very unpleasant to use, with `unwrap()` all over the place. >...