Fix panic in TimeZone::from_local_datetime

[pitdicker]

Split out from #1048. Depends on #1069 for NaiveDateTime::checked_sub_offset, only the last commit is new.

The change is that TimeZone::from_local_datetime should check for overflow instead of blindly subtracting the offset. But you can't do so easily in LocalResult::map, so this adds a helper method.

Note that this PR only fixes the default implementation. But the implementations of TimeZone for Local don't use the default implementation, and are not fixed yet.

The last commit in #1017 (comment) refactors Local to pick up this fix. @djc do you want me to split out that commit and try to apply it to 0.4.x? Edit: Split it out to #1072.

[pitdicker]

It is a bit unfortunate that from_local_timezone is a provided method, that can be overridden by other implementers of TimeZone. On such a type from_local_timezone may still panic, like currently with Local.

I think it is better to implement the conversion in NaiveDateTime::and_local_timezone, and let the methods on TimeZone use that.

Then we can guarantee that NaiveDateTime::and_local_timezone never panics because of this issue, independent of the type implementing TimeZone. And by using and_local_timezone in Datetime::map_local, all Datetime::with_* methods inherit that guarantee.

[pitdicker]

I also found a place in format/parsed.rs that had a workaround because of this panic, which is no longer necessary.

[jtmoon79]

LGTM

[codecov]

Codecov Report

Merging #1071 (e50dd89) into 0.4.x (c836a1f) will increase coverage by 0.01%.
Report is 2 commits behind head on 0.4.x.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##            0.4.x    #1071      +/-   ##
==========================================
+ Coverage   91.21%   91.23%   +0.01%     
==========================================
  Files          38       38              
  Lines       17121    17157      +36     
==========================================
+ Hits        15617    15653      +36     
  Misses       1504     1504              

Files Changed	Coverage Δ
src/format/parsed.rs	96.91% <ø> (+0.10%)	⬆️
src/offset/mod.rs	56.00% <75.75%> (+2.31%)	⬆️
src/naive/datetime/tests.rs	98.82% <100.00%> (+0.04%)	⬆️

... and 2 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[pitdicker]

It is a bit unfortunate that from_local_timezone is a provided method, that can be overridden by other implementers of TimeZone. On such a type from_local_timezone may still panic, like currently with Local.

I think it is better to implement the conversion in NaiveDateTime::and_local_timezone, and let the methods on TimeZone use that.

Then we can guarantee that NaiveDateTime::and_local_timezone never panics because of this issue, independent of the type implementing TimeZone. And by using and_local_timezone in Datetime::map_local, all Datetime::with_* methods inherit that guarantee.

This was based on a wrong assumption.
Why would you ever want to do something different from simply subtracting the offset in TimeZone::from_local_timezone?
Answer: when implementing something like a Tai timezone, that should handle leap seconds differently.

So this is now back to a simple fix of the provided method TimeZone::from_local_timezone.

[pitdicker]

This no longer depends on other PRs.

[djc]

Since this has a single caller, let's just inline it?

[pitdicker]

With a separate function I could use ?, and convert to LocalResult::None in the caller. It seemed the cleanest solution at the time.

Found a nicer way to write it now.

[pitdicker]

Thank you for all your reviews!