[Maybe breaking change] Fix day of year computation

[ChristopherRabotin]

The day of year computation was broken: first, it didn't work well when the time scale reference epoch was not J1900 (cf #272 ), and moreover, it started counting the days at zero, when it should have one (to meet the GPS standard and the Python behavior).

[ChristopherRabotin]

Prevent what clippy said was useless but actually required.

[ChristopherRabotin]

Behavior change introduced by this PR.

[ChristopherRabotin]

Now matches Python as per the comment.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (f37268b) 80.77% compared to head (401b9c9) 81.05%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #273      +/-   ##
==========================================
+ Coverage   80.77%   81.05%   +0.27%     
==========================================
  Files          16       16              
  Lines        3776     3784       +8     
==========================================
+ Hits         3050     3067      +17     
+ Misses        726      717       -9     

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

[ChristopherRabotin]

This should be tagged at 3.9.0 because of that behavior change.

[gwbres]

I cannot push contributions to this PR since I did not initiate it.
Though I did check that the test you wrote (for GPST + UTC) does pass in other timescales.
I may provide these additional tests in a separate PR.

[ChristopherRabotin]

Ok. If you paste the tests here, I can add them to the code base.

…

On Sun, Dec 31, 2023, 05:34 gwbres ***@***.***> wrote: I cannot push contributions to this PR since I did not initiate it. Though I did check that the test you wrote (for GPST + UTC) does pass in other timescales. I may provide these additional tests in a separate PR. — Reply to this email directly, view it on GitHub <#273 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEZV2ET5U5Y6JMQVC4H2FLYMFLU3AVCNFSM6AAAAABBHYGEMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSHEZTQMBXGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gwbres]

Ok,

here's a test that does pass

#[test]
fn regression_test_gh_272() {
    use core::str::FromStr;

    let epoch = Epoch::from_str("2021-12-21T00:00:00 GPST").unwrap();

    let (years, day_of_year) = epoch.year_days_of_year();

    assert!(dbg!(day_of_year) < DAYS_PER_YEAR);
    assert!(day_of_year > 0.0);
    assert_eq!(day_of_year, 355.0);

    assert_eq!(years, 2021);

    // Check that we start counting the days at one, in all timescales.
    for ts in ["TAI", "UTC", "GPST", "GST", "BDT"] {
        let epoch = Epoch::from_str(&format!("2021-12-31T00:00:00 {}", ts)).unwrap();
        let (years, day_of_year) = epoch.year_days_of_year();
        assert_eq!(years, 2021);
        assert_eq!(day_of_year, 365.0);

        let epoch = Epoch::from_str(&format!("2020-12-31T00:00:00 {}", ts)).unwrap();
        let (years, day_of_year) = epoch.year_days_of_year();
        assert_eq!(years, 2020);
        // 366 days in 2020, leap year.
        assert_eq!(day_of_year, 366.0);

        let epoch = Epoch::from_str(&format!("2021-01-01T00:00:00 {}", ts)).unwrap();
        let (years, day_of_year) = epoch.year_days_of_year();
        assert_eq!(years, 2021);
        assert_eq!(day_of_year, 1.0);
    }
}

[ChristopherRabotin]

I added those. The only difference is that I avoided the format!() instruction because it's only available with the std feature.

[ChristopherRabotin]

@gwbres Let me know if this looks good to merge and would fix your usecase.

[gwbres]

Hello, yes it alll looks fine to me