Correctly order earliest / latest for Ambiguous times in local TimeZone

[AVee]

This swaps earliest / latest in Local Timezone handling as it seems to be consistently in the incorrect order, see issue #1625 . I think I changed all places where an instance of MappedLocalTime::Ambiguous is created in the unix part of offset/local. I haven't yet looked at Windows.

I've also added some tests to cover this, which should cover most cases.

[codecov]

Codecov Report

Attention: Patch coverage is 99.35897% with 2 lines in your changes missing coverage. Please review.

Project coverage is 91.77%. Comparing base (7974c60) to head (48d1c65).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/offset/local/tz_info/rule.rs	75.00%	1 Missing ⚠️
src/offset/local/tz_info/timezone.rs	99.67%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1626      +/-   ##
==========================================
+ Coverage   91.12%   91.77%   +0.65%     
==========================================
  Files          37       37              
  Lines       17137    17443     +306     
==========================================
+ Hits        15616    16009     +393     
+ Misses       1521     1434      -87     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[djc]

Thanks for working on this, the code changes look good and I appreciate the added test coverage.

[djc]

These big binary blobs are a pain to manage. What value does this test have over and above the test_dst_backward_posix_tz tests? Do these tests actually gain us any coverage?

[kartonrad]

Any news on this?

[kartonrad]

We are working around this issue with this snippet of code:

match /*...*/ {
   MappedLocalTime::Ambiguous(mut earliest, mut latest) => {
        // Bug in Chrono: https://github.com/chronotope/chrono/issues/1625
        if earliest > latest {
            std::mem::swap(&mut earliest, &mut latest);
        }
       // ...

But it'd still be wise to make this a semver breaking change for anyone who has come to rely on the old behaviour.

[djc]

Any news on this?

I asked a question which has not been answered. I'm not making any semver-compatible changes in the near future.