Leap Seconds for GPST are wrong

[AGTM19]

My code:

    let epoch = Epoch::from_str("2021-03-06 11:14:40.9960 GPST").unwrap();
    println!("{}", epoch.to_gregorian_str(TimeScale::GPST));  // Expected: 2021-03-06T11:14:40.996000000 GPST
    println!("{}", epoch.to_gregorian_str(TimeScale::UTC));   // Expected: 2021-03-06T11:14:22.996000000 UTC
    println!("{}", epoch);                                    // Expected: 2021-03-06T11:14:22.996000000 UTC
    println!("{:?}", epoch);                                  // Expected: 2021-03-06T11:14:40.996000000 GPST (?)
    println!("{}", epoch.to_isoformat());                     // Expected: Not sure. One of the above without TimeScale

    println!("");

    let epoch = Epoch::from_str("2021-03-06 11:14:40.9960 UTC").unwrap();
    println!("{}", epoch.to_gregorian_str(TimeScale::GPST));  // Expected: 2021-03-06T11:14:58.996000000 GPST
    println!("{}", epoch.to_gregorian_str(TimeScale::UTC));   // Expected: 2021-03-06T11:14:40.996000000 UTC
    println!("{}", epoch);                                    // Expected: 2021-03-06T11:14:40.996000000 UTC
    println!("{:?}", epoch);                                  // Expected: 2021-03-06T11:14:40.996000000 UTC (?)
    println!("{}", epoch.to_isoformat());                     // Expected: Not sure. One of the above without TimeScale
}

I expected to see 18 leap seconds between UTC and GPST but what I got, were 37 leap seconds. 37 leap seconds are required between TAI and UTC.

The output running in debug (cargo run):

2021-03-06T11:14:03.996000000 GPST  // Wrong leap seconds. is 37, should be 0
2021-03-06T11:14:03.996000000 UTC   // Wrong leap seconds. is 37, should be 18
2021-03-06T11:14:03.996000000 UTC   // Wrong leap seconds. is 37, should be 18
2021-03-06T11:14:40.996000000 GPST  // Correct.
1941-03-02T11:14:21.996000          // Wrong year. Correct leap seconds if UTC assumed

2021-03-06T11:14:40.996000000 GPST  // Wrong leap seconds. is 0, should be 18
2021-03-06T11:14:40.996000000 UTC   // Correct.
2021-03-06T11:14:40.996000000 UTC   // Correct.
2021-03-06T11:14:40.996000000 UTC   // Correct.
2021-03-06T11:14:40.996000          // Wrong if UTC assumed. Correct if GPST assumed

In Release it looks different but not significant better (cargo run --release)

1941-03-02T11:14:21.996000000 GPST  // Wrong year. Wrong leap seconds. is 18, should be 0
2021-03-06T11:14:03.996000000 UTC   // Wrong leap seconds. is 37, should be 18
2021-03-06T11:14:03.996000000 UTC   // Wrong leap seconds. is 37, should be 18
2021-03-06T11:14:40.996000000 GPST  // Correct.
1941-03-02T11:14:21.996000          // Wrong year. Correct leap seconds (if UTC assumed)

1941-03-02T11:14:58.996000000 GPST  // Wrong year. Correct leap seconds (if UTC assumed)
2021-03-06T11:14:40.996000000 UTC   // Correct.
2021-03-06T11:14:40.996000000 UTC   // Correct.
2021-03-06T11:14:40.996000000 UTC   // Correct.
2021-03-06T11:14:40.996000          // Correct if UTC assumed.

Can someone reproduce this? Maybe I do just a bad mistake or misunderstand the API?

Assuming, that it is a bug, I looked into the code, trying to find an easy fix but I assume that this requires the attention of someone with a more general understanding of the epoch.rs module.

Edit:
Using
rustc 1.76.0
hifitime = "3.9.0"

[ChristopherRabotin]

Hi there,

I will look into this tonight. From the report, it does look like a bug. I can't seem to reproduce it right now from Python, but it may be because it uses a different code path.

[ChristopherRabotin]

Sorry for the delay. So, there's definitely a bug because we don't use the correct duration in the proper time scale when printing, cf. https://github.com/nyx-space/hifitime/blob/master/src/epoch.rs#L2885 .

That said, even when fixing this, I get the following output for your use case:

1941-03-02T11:14:21.996000000 GPST
2021-03-06T11:14:03.996000000 UTC
2021-03-06T11:14:03.996000000 UTC
2021-03-06T11:14:40.996000000 GPST
1941-03-02T11:14:21.996000

1941-03-02T11:14:58.996000000 GPST
2021-03-06T11:14:40.996000000 UTC
2021-03-06T11:14:40.996000000 UTC
2021-03-06T11:14:40.996000000 UTC
2021-03-06T11:14:40.996000

I'm picking up work on #280 which I suspect will fix the issue by itself because we don't do unnecessary time scale changes anymore. It'll be released as part of version 4 of hifitime since it's a pretty significant change.

[AGTM19]

Thank you for considering this. Looking forward to version 4!

[ChristopherRabotin]

Hi there! Just to let you know that I've fixed this bug for version 4.0.0-alpha. I'm racing to get that published soon.