-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Epoch::from_time_of_week returns wrong time in GPST #209
Comments
Also, as a feature request it would be handy to have a version of |
Thanks for the bug report. This looks similar to an issue we had in the PR
that added GPST. I know we fixed it, but I forget how right now.
How urgently does this bug need fixing for you?
…On Sat, Mar 18, 2023, 03:44 Leith Bade ***@***.***> wrote:
Also, as a feature request it would be handy to have a version of
from_time_of_week and from_time_of_week that works on f64 seconds instead
of nanoseconds
—
Reply to this email directly, view it on GitHub
<#209 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABEZV2HHXI5MQOOCWVG6UODW4V7YPANCNFSM6AAAAAAV7J3MJA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
It's not urgent, I was able to work around it by just subtracting the 19 second offset to value I give to |
Possibly related to this bug, if you provide the same time in two different GNSS timescales you get the wrong values in UTC. For example if I use GPST and BDT then I get the same incorrect time in UTC for both. A test:
This prints currently:
The UTC time printed seems to be always 37 seconds off from the input time. 37 seconds I think is also the difference between UTC and TAI, so perhaps both times are being interpreted as TAI? |
Thanks for the report, that does look like there is a wrong interpretation of the leap seconds. @gwbres Any thoughts on this issue? |
Thank you @ljbade for the bug report ! If i remember correctly, 19 is the amount of leap seconds when GPST was initiated (1980 Jan 5th to 6th midnight). |
Yes GPS is 19 seconds offset from TAI, and BDT is 33 seconds. |
Hi @ljbade , I think that I've fixed the bug in #303 . Here is the test I'm about to add to the regression tests and the output I got. The first case matches exactly what you said it should be, and I'd like your confirmation that the second output is also correct. Thanks #[test]
fn regression_test_gh_209() {
let t = Epoch::from_time_of_week(1983, 0, TimeScale::GPST);
println!("{t}");
// Should print
assert_eq!(format!("{t}"), format!("2018-01-07T00:00:00 GPST"));
let t = Epoch::from_time_of_week(1982, 604800000000000 - 19000000000, TimeScale::GPST);
println!("{t}");
} Output:
|
Done in #305 . |
When using
Epoch::from_time_of_week
to initialiseEpoch
from a GPS week number and time of week, the resulting epoch has a 19 second offset. Below is a sample program that shows the bug:Currently this prints:
The text was updated successfully, but these errors were encountered: